Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In this book review: http://books.slashdot.org/story/11/06/13/1251216/Book-Review-The-Clean-Coder?utm_source=slashdot&utm_medium=twitter

Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of "the zone" when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.

they talk about how 'being in the zone' - can actually be detrimental to the project. How do you convince your team members that this is the case?

share|improve this question

closed as primarily opinion-based by MichaelT, durron597, Ixrec, jwenting, Robert Harvey May 11 at 0:29

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Without reading the book, I'm not sure I could agree with that assertion. The sentences following that on in the review talk more about trying to code without direction, so you end up wasting more time just trying to get something working. Maybe that's just me, but perhaps if you gave some of the examples from the book and not the review, you'd have better luck. –  Tyanna Jun 26 '11 at 23:01
Doesn't all this depend on your definition of 'zone'? I've always felt that this is just a period of outstandingly smooth programming/development - for me, this includes the usual failing-test/code/pass/refactor/pass cycle, so it shouldn't be the problem that the book makes it out to be –  HorusKol Jun 26 '11 at 23:26
@HorusKol -- pretty sure it's synonymous with flow: en.wikipedia.org/wiki/Flow_(psychology) –  Rei Miyasaka Jun 26 '11 at 23:40
The author is describing "tunnel vision" and not "the zone," or "Flow" like Rei linked to which is an understandable mistake for an amateur psychologist. I agree with all comments that think the project lacks design/direction and that focusing on a straw man like Zone is simply hiding the core problem. –  Patrick Hughes Jun 26 '11 at 23:58
@Patrick: That's probably the best answer so far. You should submit it as an answer and get rep for it. –  Mason Wheeler Jun 27 '11 at 2:26

4 Answers 4

up vote 0 down vote accepted

The message being communicated: be adaptable at where you focus your attention.

While the core message is quite simple, communicating it effectively is very tricky. Programming requires such high attention to detail. We've all experienced misplacing a bracket and then kicking ourselves for hours while figuring out why the program won't work. It is very easy to dive into the minute details of a task. While doing so, it is easy to lose sense of why we this needs to be done.

share|improve this answer
Quite succinct - but on the money. Perspective is important. –  hawkeye Jun 28 '11 at 10:00

To force people to stay out of "the zone" (also known as "flow") is codswallop.

When in the zone, is when a proprammer (or surgeon, or car mechanic) is at their most productive - time passes in the blink of an eye, brilliant solutions appear, complex code with numerous pieces that interact can be created - and it all just flows out automatically.

If not in the zone, this is just not possible (or if possible it takes a vast amount more time, and more documentation).

Over the years, pretty much every case I have ever had of silly defects - things being incomplete - stuff done in one place but not another - can be attributed to being disturbed (that is, pulled out of the zone) when in the middle something.

Forcing people not work in the zone is the same as asking them to work with a dual screen PC, where 1 screen has CNN TV on it and the other is used for coding.

Similarly, how would you like your friendly neighbourhood heart surgeon to be out of the zone when operating? For him to be not concentrating... or only part there.

Sorry... I find this suggestion to be utterly ridiculous. If followed, you will have an organisation that in the long term produces sub-standard work, with low productivity, low morale, high cost, and with high defect rates.

Read Peopleware by De Marco.

share|improve this answer
I've read Peopleware. I think the question points to the conflation between tunnel vision and 'the zone' in programming culture. –  hawkeye Jun 28 '11 at 9:59
Tunnel vision has nothing to do with being in the zone. Tunnel vision is not being able (or wanting) to look beyond the immediate task or goals. Thats not the same as being in the zone at all. –  quickly_now Jun 28 '11 at 11:25

Well, I'm certainly not convinced myself. Not consciously looking at the bigger picture is obviously a problem, but being zoned-in and occasionally taking a step back aren't mutually exclusive by any stretch.

I don't think many people can be focused on a single task for more than a few hours anyway, so it seems a bit of preaching-to-the-choir to say that you need to take breaks during work. Not to say that there aren't people that can -- but they're a minority.

I'm going to go out on a limb and say that it actually sounds more like they're not giving you much attention when they're not focused, and they're just pretending to be completely focused the whole time.

share|improve this answer

Though I don't agree 100% with the author, I can see what he's driving at. Who hasn't burned through 12 hours without noticing the time, only to wake up the next day and find your brilliant work doesn't exactly mesh with the rest of the project? The Zone, Flow, or whatever you want to call it is a delicate dance between the right and left hemispheres of your brain, with the right slightly dominating. The right enhances your artistic expression, has little ego, has great intuition, and no concept of time (hence losing track of time). The left's analytical and planning skills are there, but in a reduced capacity so you can "feel" what's best and possibly discover a novel solution that your executive left brain would dismiss (our left brains are very critical).

In a fantasy world where we're always in the zone, it would be hard to make long term plans and communicate with our coworkers (our left brain is better with language). Fortunately, the zone-only world doesn't exist. After a night in the zone, we can stop, evaluate, and refactor if necessary. If we're lucky, our right brain will have left us a somewhat random but exquisite solution to a problem.

Maybe what the author meant to say is that we shouldn't treat the Zone as a panacea. Every project and team needs both analytic reasoning and intuition. The best approach is probably plan, flow, plan, flow, plan, flow...

share|improve this answer
That's quite reasonable. Most people can only stay in the zone for a few hours (quotes range...2 to perhaps 5 varying by person). That means normal people have time during the day to be in and out of the zone. The out time is for planning, discussion, analysis - all the hard stuff that allows the being in the zone to be productive. –  quickly_now Jun 27 '11 at 5:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.