Much has been written and said about programming in “the zone”. Most articles give you tips on how to get in the zone and keep there. I haven’t found any article though that challenges the usefulness of ‘being in the zone’ (If I have missed some, please let me know).

What is the zone?

The zone is usually described as a state-of-mind where one feels productive and hyper-focused. These are certainly good traits to have when you are programming. However, the zone also comes with tunnel-vision and a sense of being infallible. These are not good traits to have.

Being in the zone is also often described as a pleasurable feeling.

Furthermore, the zone is also related to left-side hemisphere vs right-side hemisphere of the brain thinking. (note that these are not referring to the actual location of where brain activity is measured, but just placeholders to indicate a certain type of brain activity). Generally speaking, the left side of the brain tends to control many aspects of language and logic, while the right side tends to handle spatial information, visual comprehension and creativity. With that in mind, do we really want to be in a state-of–mind where logic is less prominent and we have a tendency to be more creative? While creativity is a good trait to have when programming, it depends a lot on what type of creativity.

Negative effects

I have found personally that being in the zone is counter-productive. When I’m in the zone, I do feel very productive, write more code and find complex solutions. When I look at the same code afterwards though, I often find that it’s overly complex. My ‘creative’ solutions are not always as clear as they should be. Because of the tunnel vision you get when programming in the zone, you can loose the big picture. Code that I write in the zone comes out faster, but I need to go back to it more often. Even if it doesn’t need any changes, it’s harder to read and in the end causes more loss of time than something that took a bit longer to write but is more readable and understandable.

One of my favorite quotes about programming is by Brian W. Kernighan:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it

This certainly applies to code written in the zone. When I’m in the zone I’m more focused, so the code I write is the most clever code I can write. By the above definition then, I will not be smart enough to debug it unless I’m in the zone again, and thus, you’re abilities as a developer become dependant of being in the zone. I don’t think that’s a good idea.

Interruptions

The role of software developers has changed significantly over the past 10 or 20 years. While 20 years ago, the stereotype of a developer’s was a geek in a dark room in front of a bright screen, cranking out code, today, developers are part of an organization, a team and a development process, where interaction with customers and colleagues is often as important, if not more important, as cranking out code.

Something developers often complain about is interruptions. It’s true that an interruption gets you out of the zone, and being pulled out of focused state can really be annoying. But a developer’s job is not just about cranking out code, it’s about supporting your business, coding is just a part of that. If someone needs help, should they really wait until you ‘feel like answering them’? It’s part of the job, so we should help people out when needed. After all, we expect that treatment from other colleagues, don’t we?

Obviously there’s a limit to the amount of interruptions you can handle without losing productivity, but I don’t think an interruption should get anyone upset.

Using it correctly

As with most ‘tools’ we have available, saying that a tool is great or bad at everything is usually short-sighted. While I’m certainly opposed to thinking that being in the zone all the time is optimal, I also think it can be used effectively, given the correct circumstances.

When you’re learning a new tool or paradigm, it can be very beneficial to be in the zone, as you will be hyper-focused and can absorb much more information in a shorter time span. Coding kata’s are a perfect example where being in the zone can be very beneficial. A kata is a very focused exercise where you don’t need to keep the big picture in mind (there is none) and it often requires some creativity to solve the puzzle. These puzzles are excellent to train your mind.

Essentially, the zone CAN be used for a very tightly scoped and particularly hard problem, but I avoid it as a general state to develop software.

Conclusion

While many will certainly disagree with me (that’s perfectly fine), I would like to invite you to take a step back and think about whether you see being in the zone beneficial because it improves your productivity or whether you just enjoy the feeling of being in the zone.

I tend to steer away from being in the zone. When I feel myself getting into that state, I usually get up for a few minutes and do something else. I only allow this to happen whenever I want to practice some skills, because then there’s no downside of being in the zone. In the end, I think awareness of what the zone is, realizing when you’re in the zone and the ability to use it effectively is a valuable skill. What do you think? Sound of in the comments!