Most programmers know what is “The Zone”. It is a very focused state of mind where you feel that there are no problems that you cannot solve. You know, the state where your surroundings disappear and you feel almost omnipotent. You are very productive, take great leaps and progress fast.

I posit that this is a dangerous for a couple of reasons.

Too tight focus

In my experience it is very hard to make corrective actions while in the zone. The Zone has the same effect as speeding, your sight narrows and with high enough speed you can see only forward. How do you verify that you are solving the correct problem? Are you really going to the right direction? Are you sure? When in “The Zone” do you ever stop and wonder “Is this the right thing to do?”. Do you ever question the task at hand? Is this really the most valuable feature? Could there be something that would provide even more value?

The Zone is a state of extreme focus and motivation. The problem is that your focus is very likely too sharp. This leads to blindness to your own errors and makes it really hard to change direction. This leads to false productivity as the risk of rework grows very fast. With great speeds even the slightest mistake become huge almost intantly. Think about a steering error while driving over 200km/h.

Susceptible for interruptions

“The Zone” is fragile. Even the slightest disruption, an email, innocent short question from a colleague, can drop you out of it. Getting back is difficult so your productivity is going up and down very frequently. This can be really frustrating and a real motivation killer in the long run, especially when you consider the nature of software development which emphasizes team work and continuous communication.

You may have your own private room you can hide in but is it smart to shut out others? If everyone is locked up in their rooms what does it do to your team spirit? Privacy is ok and should be respected but isolation is not. With people spread out in their rooms how can you ensure that you are all pulling the same rope and in the same direction? Which leads us to the next pitfall.

Silos

Everything that is done alone encourages silos. It is always harder to spread knowledge afterwards. Spend too long on one task and you become the sole source of information. In other words a single point of failure.

Isolating yourself to ensure uninterrupted “zone” prevents you from learning from others, gaining information from others and spreading your knowledge to others. Silos prevent sharing the code and the code wants to be shared. In other words you have too long feedback loops.

Too long feedback loops

While in “The Zone” you are alone. Very alone. How can you be sure that you are doing the smartest possible thing? Is it the right thing to do? You practice TDD so technically you are on the right path but logically? Have you been derailed from your original goal? When is your next code review? Can you afford to wait that long? Are you sure that your domain knowledge is deep enough? While you worked in the zone and progressed did it actually move you forward in the right direction?

What if you had understood something incorrectly? Depending on the size of your task this can mean all you have delivered was waste (excluding your own learning). Did you write too much code? Did you try to anticipate the future?

The antidote

You can overcome some of the issues of the zone by ensuring frequent communication with the business and making sure that all tasks are small enough in order to shorten the feedback loop. This still leaves you in a more fragile state than we would want.

But there exists a very effective practice that renders the negative aspects of the zone very close to non-existent.

Pair programming.

Pairing

In psychology terms “The Zone” sounds like flow. Flow is described as a state of focus, motivation and productivity. I want to make a semantic difference between these two states and add negative connotation to “The Zone” and positive connotation to “The Flow”.

Pairing gets you into a flow fast and it is easy to stay in the flow!

Pairing gives you enough focus but it isn’t too tight. It’s like having someone to read the map to you while driving to an unknown location for the first time. And it beats the GPS and other map utilities hands down. You always have someone there to question your train of thoughts, helping you to take the right exit or turn and to stop when it is time to stop.

While pairing interruptions don’t cost even nearly as much as they while in the zone. The pair can very quickly regroup and maintain their momentum. You can momentarily split up and continue after the interruption has been dealt with.

You can’t hide information while pairing and you can’t become a silo. You will learn, teach and gain information while pairing.

Pairing while programming gives you a feedback loop of seconds. Your thoughts are evaluated as soon as you articulate them. And articulating your problems is the best way to solve them.

Don’t keep zoning, start pairing

Post filed under Pair programming, Software Craftsmanship.

3 Comments

  1. Um. Not quite in agreement here. I can program days or weeks in the Zone and get tons done. It’s the most enjoyable and also actually the most productive way.

    Naturally there are pitfalls. You need to make sure that you don’t get too deep into the details so that you can remember what The Goal is. You always need a goal, or a sprint goal, or whatever. The Goal is oft something that’s not to make a perfect program or a program w/a lot of features (less is surely more). The Goal is oft to make Good Enough things that fulfill given business needs as simply as possible, as fast as possible.

    And certainly you need to communicate w/your peers! Of course! But the interruptions are not helping when you need to concentrate to actually Get Things Done.

    Pairing is best when you have people who either have different information about the problem or when one of the paired people is senior to the other person.

    Pairing doesn’t seem to work that well w/two gurus who know about the same amount about the problem domain – when actually programming. It’s important to talk and design and make high-level decision together, but when it’s about the nuts and bolts, experienced programmers just fly through the problems when they’re in the Zone.

    Also, experience helps you in not losing focus. I know what you talked about when you mentioned solving the wrong problem. This has happened to me in the past. Nowadays, it’s very rare and it’s clearly offset by the productivity that I reach in the Zone.

    Also, when my peers tell me about something, I tend to forget it fast. When I figure out the solution myself, I will remember it. The downside of receiving information from peers is that you’ll forget it way faster and you have to ask again and again. This is because rote learning is nothing compared to going through the intricacies of solving the problem yourself. You usually cannot understand in great detail what you haven’t created. Being told “It’s X” can get you past the problem once, but you won’t understand why nor remember that it was “X”.

    The interruptions at work cause a lot of stress. So it’s better to protect your Zone when you need to get things done. That’s the time to disconnect from the world around you, like now while I’m writing this. Peer programming is like peer writing. No thanks. It’s better to agree upon what to write on the high level and then have people write what they need to write and then review. That is, if you want to Get Things Done.

    Oft, too, the level of Good Enough isn’t really that high. You need to build certain parts of a system w/great care, but there’s a lot of code that’s perfect if it’s simple and written fast.

    So, while we surely agree on many things, we disagree on others. I am sure that you’ve found your way to be successful for you, but that is true for me likewise. Also remember that people are different.

    Communicate, keep The Goal in mind as well as What Is Good Enough, agree about the high level w/your peers and immerse yourself in the Zone.

    Long live the Zone! :-)

  2. I talked this over w/a friend in Skype. We came to the conclusion that the problem domain really is critical to whether you should choose one approach or the other.

  3. I did not say that you can’t get things done while zoning. I stated that it is dangerous and can be ruinous to your productivity. Let’s start with the issues you mentioned :)

    1) Goals

    When do you know you are done done? Do you ever go too far, ie. write code for the future? Do you ever derail in your efforts? If you can zone and stop effectively at the ‘Good Enough’ marker, awesome, many are not so self-disciplined.

    2) Communication

    Being alone is not communication. Trying to tell what you did after the fact is difficult as you said yourself. All this becomes unnecessary if you practice pair programming.

    3) Pairing /w Gurus

    Guru’s are just the ones who have to pair! Imagine what they could achieve! Be it with a junior or another guru, the outcome in the long run will be much bigger than the sum of the parts.

    Pairing also means “doing it together” so you will learn by doing. Two minds just work better. Less mistakes and less rework!

    4) Stress

    Dropping off the zone does cause stress. With pairing its a non-issue! Pairprogrammins is much much more tolerant for disruptions. It’s also easier to get back to the pairing flow than it is getting back to the zone. Get rid og your stress, start pair!

    I’m not saying that the zone is inherently bad. In my opinion it does not work in a highly interactive team work at all. And most software projects nowadays are team work. With a distributed team or project (like OSS) the zone can be much more productive than pairing, but distributed teams make pairing hard ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>