There’s already a good amount of discussion out there about the need to take breaks to give your body – eyes, wrists, back, etc. – a rest, but not much about how to properly take a break without it messing with your flow.

A lot of programmers seem to be in touch with the idea of flow – you know, that period of time where you’re just on. I’m touching on the idea of getting in and out of flow successfully and repeatedly over a period of time.

Obviously, there are physical limits to how long you can do work for. But if you don’t record your thought process while you’re still in the flow, then none of that work matters, because you’ll never be able to return to it. The trick is to strike the right balance between work and meta-work, writing down just enough so that you can pick it up again later, but not so much that you’re not accomplishing anything of value.

With such a brain-intensive task as programming, it’s hard to tell whether or not taking a break helps you solve problems. I think of each of my breaks as a kind of context switch. The key is to know how long it takes for the context to dissipate. If you take a bathroom break or chat with your buddy for a bit, you can probably get re-familiarized with where you left off in a relatively short time period – maybe 10 minutes or so. After a two-week break, it could take a whole day. After a year, you’d probably feel like starting from scratch.

The moment you step away from a problem, the clock starts ticking. Eventually, you’ll forget what you were thinking at the time. That is, unless you plan ahead.

In order to truly benefit from a break, you need to finish things quickly, or at least leave them in a proper state of done, similar to the agile concept of having something releasable at the end of every cycle. But even if you don’t do the whole agile thing, the idea is still applicable to anything you code.

All you really have to do is record the context in which you leave off, so that it’s easy to pick the work up again. When a computer is happily plugging away on some process and gets interrupted, it takes everything it was working on – the “context” – and stores it somewhere in RAM, so it can use all those resources to work on whatever interrupted it. When it’s done, it grabs everything from RAM and puts it right back where it came from and then continues working on the original process.

This is easy for a computer because it doesn’t need to remember what it was going to work on next; it just gets told what to do by some predefined instruction code. For you, it’s a little different. When you’re in the zone, the direction in which you’re going is a bit fuzzy. You get a few ideas all at once but can only work on one at a time. That’s why you need to write out not only what you’re working on, but also your line of thought. Ultimately, this is why commenting and documentation matters – because you won’t always remember what you were thinking at the time.

Once you start thinking about storing the context when you put a task on hold, you’ll realize how costly it actually is to take a break. I’m not saying that you shouldn’t take breaks. Breaks are obviously important. The point is not to do so much in one sitting that you don’t have the energy to store the context before you take a break.

A brief example: the other day, I was working on Off The Clock before heading off to a brunch. I was only at my desk for about an hour before I had to leave, but I was definitely in the zone. I was able to get up to speed in about 20 minutes by referring to the notes I’d left myself a couple weeks earlier (I had written down what I needed to work on next along with a few possible implementation strategies, of which I followed exactly none).

Anyway, when I was done, I just kept all the windows open but took no additional notes. When I got back about 4 hours later, I just looked at what was on each window, and that was enough for me to get back into it within about 10 minutes. If I left it for two weeks, just having the windows open wouldn’t have been enough for me. I likely would have had to start from scratch again.

How much you need to write down is something I think you only learn through experience and practice, but, in general, the longer you leave a task, the more detail you’ll need to write down.

It’s really, really easy to be lazy. If you’re primed to be lazy – and I think most programmers are – then all you need is a little push in the right direction. Or the wrong direction. If you can find any excuse to take the easy way out, you probably will.

What they found, in short, is that the worst team member is the best predictor of how any team performs. It doesn’t seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.

The trick must be to find ways to neutralize those excuses, perhaps by having an awesome team, or an awesome leader. If you take every excuse to get things out of your way, you’re probably not getting anything out of your way.

If you want to do great work, focus on one thing at a time. Finish it and move on to the next thing. It means some things aren’t going to get done as fast as some people may want. It means some people aren’t going to get your full attention for a while. But doing a bunch of crappy work, or making a bunch of poorly considered decisions just to get through the pile isn’t worth it.

Just like in investing, your overall result is the sum of many small decisions. Each decision may seem to matter very little, but overall, every decision actually matters quite a lot. Success comes from making the best possible choice at every decision-making opportunity.

There’s really no such thing as a big decision. Any seemingly big decision can be broken down into a set of smaller decisions, and each of those broken down into even smaller decisions. So, it doesn’t make much sense to focus on trying to make big decisions well when you have the opportunity to make small decisions well.

You get a positive result overall when you focus on making the right choice at every turn. However, this also means that there’s a lot of opportunity to get lazy.

At every single moment, you have the choice to be disciplined or be lazy. If you have any semblance of the results of your decisions, then bad choices have the effect of discouraging strong, disciplined action in the future. Poker players call it tilt, but it applies in any situation requiring continued discipline: sports, investing, and software development. Jeff Atwood put it nicely:

All the code we write is broken. Your code. My code. Everyone’s code. Software development isn’t a science; it’s a process of continual refinement.

Think about it. For every line of code you write, you have the opportunity to make it highly readable, as well as relevant and testable. High quality software is the result of a continued focus on high quality code. But every line of code also carries the temptation to just get the work done quickly, whether that temptation is the result of the aforementioned bad apple, business pressures, or code that already sucks.

What you should take out of this is that it’s never too late to start making good decisions. Every choice has to be made anyway; it’s up to you whether to make it a good one.

I was first exposed to this concept when I developed my project planning tool. It came about as an extension to a project we were working on. I was unhappy with the existing process, and went about fixing it, as I generally don’t like to leave broken things unfixed. It’s why I automated the planning process for that project, and it’s why I developed a tool to show my phone usage statistics.

If you develop software, there are undoubtedly some weak points in your process. On a development team, the first thing rookie developers will probably complain about is a lack of clear documentation (don’t worry; the current developers have plenty of it locked up in their heads). Good rookie developers will stay strong and document whatever they work on, improve documentation for existing code, and create documentation where documentation doesn’t exist. The weaker ones will succumb to laziness.

Organizational changes have to be made incrementally. Otherwise, the culture shock will cripple the process entirely (or so we’re led to believe by management types). People are part of the process, so you have to take them into account. Most of them don’t like change. But they probably won’t complain if they don’t really notice it. Just like nobody can see how fast the polar ice caps are melting.

Organizational changes come about when people exposed to the process notice its flaws. If that’s you – and you choose to be smart about it – then you’ve just found yourself a great new idea. And that’s exactly how Gmail started:

Gmail was a project started by Google developer Paul Buchheit several years before it was announced to the public. Initially the software was available only internally as an email client for Google employees.

If you get into the habit of actually trying to fix the problems you find, then you’re going to be getting a lot of ideas. A few of those ideas will be great. And a few of those great ideas will make a lot of money.

The point here is that making great new things is more of a habit than it is a one-time deal. Professional poker players know that the results of one hand don’t make or break a career. It’s the net effect of hundreds of thousands of small decisions added up over time.

If you think you might be a smart person, realize that your value comes not from having ideas, but from your drive to implement those ideas.

There is a brief period of time between a project’s infancy and its maturity where documentation is, at best, scarce. For some projects, it lasts for a couple months; for others, until the first official release; and for others still, approximately eternity. But if all you proponents of proper programming practices truly believe that the documentation doesn’t exist… well, you’re wrong. It does exist. And you already have a lot of it.

The early stages of a project need not be maintainable, especially when it’s possible that the project will get scrapped. So it’s okay to neglect the kind of  ocumentation to which you’re already accustomed: comments, design documents, change history, etc. It’s the kind that takes time, effort, and money; you know, those really scarce resources. For long-term projects, it’s usually worth that investment since such documentation lasts longer. But the mere existence of long-lasting documentation implies that there is also short-term documentation.

We never think about it because there’s really no need to. It’s natural, has no added costs, and is abundantly available in code written by humans. What is it? It’s you, the developer.

The community amongst developers is incredibly strong. They will support each other and answer each others’ questions. Still, the single best person to ask about code is the developer that actually wrote the code. He is the documentation, especially in those painfully long early stages where it’s impossible to find another source of information. Anything that you would want to get from documentation, you’ll be able to get from the developer. In fact, this kind of short-term documentation is better than any long-term alternative. Unfortunately, it expires quite quickly, and when it does, we need to push for long-term alternatives.

We naturally assume that the only reason to ever make permanent documentation is when the original developer is about to leave the company. But that’s too late. By the time the developer leaves, if he ever leaves, it’s hard to even consider him to be the developer anymore. The information gets relegated to the back of his head, locked in a vault along with other deep and dark secrets that will never see the light of day. He’ll look at his code as if it’s not his own, wondering what the hell he was ever thinking.

So when is this short-term documentation no longer good enough? Well, eventually, the code grows so large and complex that the developer can no longer explain it. That’s one good time to add long-term documentation. Another is a more specific case of the above argument: instead of adding long-term documentation when a developer leaves the company, the developer should focus on adding it when he leaves the code long enough to forget it. Of course, developers should be doing that for their own benefit anyway.

Remember that implementing this idea requires concrete action plans. Focus on how you will ensure that these notes get added. It’s difficult to get this idea off the ground at a young company, but once the procedures are in place, it will be hard to ever imagine living without them.

A boss of mine once told me, “Sometimes getting something done quickly takes precedence over doing it right”. I’d argue that “quick” and “right” are the same thing in this context; it’s simply a pitting of the long-term against the short-term. Consider the time it actually takes to get things truly done. Well, yeah, I could push out a quick and dirty solution in a few minutes, but I can almost guarantee that it will bite me back when I least suspect it. And I’ll stand up dazed and confused, not knowing where the problems came from. What I will finally come to realize is that the project wasn’t actually finished; it was merely in an unstructured beta test.

Over our careers, we’ll churn out a lot of short-term projects that end up getting scrapped as fast as they started. It’s inevitable. There is little incentive to spending time improving maintainability for something that will not likely be maintained. But how do we handle that rarer project that does end up with a long and bountiful life? The way it stands, we’ll just wait until it gets sick and let it subsist on some expensive life support machine. But if you intend to live a long life, as countless health and financial experts have shown, you better start planning early.

For this reason, “prototypes” should be identified as such, so that they can be treated appropriately. One of the reasons that prototyping is a favoured method of production is that it allows for a quick implementation, for the purpose of gauging the product’s value. Still, the method gets a lot of flak due to the more common use of the prototype: as a full-fledged product. The result is that many prototypes end up on the market claiming to be the brainchild of a solid process, when it is no more than the bastard son of a cheap and dirty production line.

One of the reasons that many developers prefer to code with no design is that it really helps to get the code on the page and understand how the concept might work. Essentially, code devoid of design is just a prototype. And that prototype can be used to form a good design. The design really is in the details.

Given the unfortunate – but realistic – assumption that most code is poorly documented, we can hypothesize that the developer mentality is prototype-oriented. Whether this is an inherent trait or inherited from management is a moot point, and ultimately a job for the social psychologists. What matters is how this affects our ability to enforce standards and good documentation. It all comes down to making a distinction between prototype and product.

For those prototypes that inevitably become products, there must be an identifiable point in its life where this classification changes. How can you identify it? Picture yourself with the satisfying job of rejecting prototypes all day long. You’re a “no” man. All you do is scrap prototypes. But the exact moment you’re forced to say “yes” to a prototype is the moment it becomes a product.

Most of us are geared to continually say “yes” to a prototype, and then say “no” when we finally receive some metric that conclusively proves its poor performance. But the point where you would scrap the prototype can be the same point where it becomes a product. And if you’re really good – if you’re really a visionary – you can spot these tendencies even before the results come in.

In any case, the exact moment where you choose acceptance over rejection is where you must focus on maintainability. If you don’t plan on building a design from what you know and then starting from scratch, then you absolutely must make an active shift from the prototype mentality, where documentation, conventions, and standards don’t matter, to the product mentality, where these things lead to a maintainable and manageable software solution.