The Five Zones of Programmers
The Five Zones of Programmers
Of all the zones, this one is the most common. A programmer that is constantly interrupted will always be in Zone 0. When you read articles online about the cost of context switching for developers they are talking about being in Zone 0. Every switch brings a developer back to zero.
Have you ever been in a meeting with programmers? They seem to be in a constant state of motion … typing on the laptop, texting on the phone, operating the phone, taking notes, and fidgeting. Want to know why? They have left the meeting behind, it is going too slow or is designed for another audience. The developers are merely sitting there to get points for required attendance. Would you like to know what they are texting on the phone? Usually jokes at the expense of the presenter. You can easily identify this behavior by sideways glances amongst developers and the sounds of giggles and laughter in the meeting. What are they doing on the laptop? Trouble tickets, often reclassifying trouble tickets to be fixable is a complete Zone 0 activity anyway so your programmer is optimizing. Want to know what website they are surfing? Indeed.com, most programmers look for jobs during meetings.
The existence of Zone 0 is the biggest leap of faith for non-technical users. In conversations with them they will adamantly deny it from “personal experience”. Often these individuals are tied to a dysfunctional development team and replacing all of the developers somehow didn’t help.
S (The COO of a Dev. Company in WPB who I did not get permission to directly quote) related to me his revelation one day. His development teams just were not being productive. Intuitively he knew that they should be working harder. Without knowing what else to do he moved his office to the development floor to directly supervise. All day he would see project managers leaving the solitude of their office, approach developers, ask a question, and then return to the sanctity of their own private office. “Then it hit me”, he said, “The developers are being constantly interrupted. I put a stop to interruptions by mandating all questions be queued instead. Productivity exploded!”
What S had noticed was the performance benefit of removing the roadblock preventing developers from getting from unproductive Zone 0 to productive Zone 1.
The first level of true productivity, in the graphic I mentioned coffee but it could be any environmental change really. You see, in this zone, most of the programmers mental capacity is focused on writing code. The full cup of coffee retrieved at eight may still be full by eleven. I could not count the times that I have finally reached for that satisfying sip of warm coffee after the last unit test completed only to be completely horrified to find it cold.
This level isn’t totally oblivious. Often you will get responses via instant messaging and you may even see a programmer surfing the Internet. A good way to follow-up to see if the programmer is in Zone 1 or Zone 0 is to come back after the programmer starts coding again and ask what website they were on. If the programmer is in Zone 1 they will not remember. It is actually a really cool party trick.
I have a good friend who is a programmer and he has a particular peculiarity. If you watch a movie with him he cannot recollect the name of the movie after it has finished. He Zone 1’s during the entire feature. The real fun part is that he can remember nearly every single detail and nuance about the movie just not the name.
When you read the literature and the research proclaiming how a particular development methodology increased productivity by 10,000% you are reading about the removal of Zone 0 from the development process. When a development team (not just one or two members on the team) have all reached Zone 1 outsourcing is no longer cost effective.
A special note about this zone: it is a team effort. Zone 1, individually, occurs randomly based on the particular task, skill of the developer, and phase of the moon. However, if environmental factors are controlled Zone 1 becomes more and more prevalent. Some environmental factors to consider:
- Interruptions: Sales people taking conference calls adjacent to developers
- Interruptions: Non development personal asking questions
- Interruptions: Non-essential meetings.
- Task Specificity: Poorly designed tasks with no clear definition of done
- Task Specificity: Trouble tickets that are not properly documented
- Task Specificity: No work available (or the developer is discouraged from asking)
- Project Debt: Build takes more than 30 seconds
- Project Debt: Development machine too slow
- Project Debt: Poorly designed tools
- Social Debt: Rumors affecting job security
- Social Debt: Major events, parties, games, holidays
- Social Debt: Isolation from the company
These twelve items are by no means all-inclusive but give you a general feel for what needs to be addressed when looking to make Zone 1 a consistent feature of your development teams.
We are reaching rarified air here. Executives willing to believe in Zone 1 are hesitant to acknowledge the existence of Zone 2 and to be honest I understand why. I have been doing this for a long time and I cannot indentify a clear and consistent pattern to get developers into Zone 2. Scientific method is based on repeatability so I cannot cry foul when Zones past Zone 1 are challenged. If I were to speculate why it is so hard to replicate Zone 2 (and higher) I would guess that it is Biological Necessity.
Biological Necessity refers to the needs of the body. We are talking about bathroom breaks, snack breaks, eating, sleeping, and general motion. The longer an individual sits in front of a computer the bigger the biological need. Hunger is what keeps most developers in Zone 1. One way to indentify if a developer is in Zone 2 is if he brought his lunch and it still sits unconsumed by the midpoint of the day. Another indicator is zombieism.
When a programmer completes a 6 hour task straight through in Zone 2 they may dump to Zone 0. During this time they can act like zombies. Have you ever seen a programmer standing in the corner of a hallway at 2PM with a lost look? This is why. A good manager will corral a programmer after a Zone 2 session and help wind them down. Board games are good for this or maybe even a walk … outside. After the wind down I like to send a developer home from a Zone 2 session. The reward is well deserved and it may trigger more occurrences.
With the rarity of Zone 2 finding triggers is difficult but there are a few things you can do to help.
Passion is the biggest key. No matter the level of training or experience a passionate developer is more likely to slip into Zone 2 than a non-passionate one. Don’t believe me on the passion level? Call up a professor of Computer Science at a University with a strong CS program and ask. If the developer is passionate about coding and the work then Zone 2 is possible. Don’t know how to develop passion in a programmer then this article is not going to help. You are probably stuck in Zone 0. Don’t worry, I hope to address passion in a future article in this series.
Next is a clear definition and scope of sufficient sized work. What this means is that there has to be sufficient work capable of sustaining a six hour workflow without a request for clarification or a lack of work. This is where great product owners really show their worth in Scrum. The better defined and better understood a work item (user story, backlog item, whatever) the easier it is for a developer to make a sustained effort.
Finally, a reduction in lag and I do not mean network latency. Generally speaking, when we refer to interruptions we are talking about talking to individuals or performing some action outside of the development window. When looking for a Zone 2 lag is measured in seconds. One big item that has been overlooked in the industry lately is documentation. When a developer doesn’t understand something she looks it up. If the documentation doesn’t make sense a context switch may occur and a subsequent reduction in zone. All too often API documentation these days is so poor as to be worthless. Worse, “great” documentation is labeled great because an executive understands it. Think about that for a second. Why would an executive need to understand documentation, wrong audience.
Another source of lag is build time. If the project or solution takes too long to compile or step into then it will increase the rarity of Zone 2 occurrences.
If you see your team repeatedly diving into Zone 2 then you are doing something very right and it is likely the performance of your group is off the chart compared to other teams. If this is you then copy what you are doing and make sure you don’t lose it. In fact, if you have more than 4 developers working together, cohesively on a team and Zone 2 happens all the time then you need to do everything you can to keep the team together. This is one of the few instances where it makes a lot of sense to sacrifice long-term business viability (to an extent, be reasonable will you) to keep a team together.
Have you ever been yelled at by a programmer? I don’t mean a bro-grammer but a meek, mild-mannered programmer. The closer to Zone 3 a programmer gets the more violent they will act when disturbed. I glazed over this in Zone 1 and Zone 2 because it usually isn’t a large issue in those Zones. The violent reactions are where the phrase: “We want developers with good people skills over good technical skills” originated.
Mumbling may be common at all levels but in Zone 3 loud conversations may be possible. The developer may perform odd looking behaviors and mannerisms and is generally completely oblivious to her surroundings. If you are a complete sociopath it is actually kind of fun to sneak up on developers and scare them when they are in Zone 3 just make sure there is nothing heavy within reach as you will be struck if you can’t jump out of the way fast enough. Though, to be fair, many developers who are broken out of Zone 3 don’t resort to battery but merely profane verbal assaults.
You have never seen this? Well, let me tell you a little secret: you are in the business world. Developers that work in “Enterprise” environments quickly learn that this behavior is not tolerable at all. It is perfectly acceptable for the state of Zen of a developer to be abused but lashing out is subject to termination. Thus experienced developers in enterprise environments routinely avoid Zone 3.
How does a developer avoid Zone 3? One method is scheduled breaks. Many developers will take several walks throughout the day to clear their head and revert to Zone 0. This routine is developed as a defense mechanism to prevent Zone 3.
Back in my college days I experienced a Zone 3 that was very memorable. Somehow I managed to wind up inside an elevator. I don’t remember how long I was in the elevator but I do remember being jostled out of my mental state by the curious onlooker who finally entered and asked what floor I needed.
Because of biological necessity Zone 3 requires more than just raw passion. This Zone requires mentally challenging work that stimulates the brain more than other needs. Hard scientific challenges can stimulate this Zone. Really, it is so rare that instead of trying to encourage it you should really just be aware of it and if you recognize it take actions to protect the individual in this Zone.
You will not see Zone 3 in Scrum and that is OK. Scrum is about sustainable development and there is nothing sustainable about Zone 3. If you see it in an Enterprise environment then you have just witnessed a double rainbow.
This is the subject of legends. Have you ever read the Celestine Prophecy? If so then you understand. If not then I don’t want to spoil the book for you.
Sometimes a developer will transcend all that is rational and enter a hyper productive state. This hyper productive state has no natural end and will, oddly enough, appear as if the developer has completely disappeared. I don’t mean to suggest that the person has physically disembodied merely that you can no longer find them yet a truly staggering amount of work is being performed.
I have no concept or understanding about how to reproduce a Zone 4 event. I can only say for certain that it exists and that it somehow transcends natural exhaustion. A developer in this Zone may seem to be in a fugue state of consciousness and will likely eat (sleep not so much) and perform other activities. There is no action you can do externally to bring a developer out of Zone 4. For a developer this zone is the everything, complete transcendence. If you have met a programmer and they trust you ask if them what it was like. Most will admit to have never been there but you may find a few that have claimed the total Zen that exists within the software development world. Have you seen Star Trek: Generations? This is the Nexus.
Other than the sheer novelty of having witnessed this event (should you ever be able to find your programmer) it is not something you want to happen. Zone 4 events are often followed by weeks of zero work (you are still net positive), ill-health effects, and possibly a multi-month sabbatical. Can you really fire a developer that did a year of work in a week and then took 13 months off? I don’t know but it would torpedo the morale of the team.
You may find a lot of bickering over the exact identification of the Zones. Are Zone 2 and 3 separate or merely the same? There will be a lot of non-technical individuals who actively deny anything but command and control and Zone 0. I cannot hope to silence the naysayers so if you don’t agree treat this as a work of fiction and carry about your merry way but if you are intrigued then give it some serious thought. You may have just opened your team up to a world of productivity gains that you have never imagined before.