A programmer’s mind explained (to project managers)

Earlier last week I was trying to refactor around two thousands lines of code, optimistically being convinced that the component could offer the exact same functionality in less than two hundred lines. My refactoring was an intuitive step-by-step process that involved creativity and a lot of concentration. Happily working on my code I slowly got into the zone, a happy state that all developers will recognize, where your mind flows freely through all possible little parts of all possible solutions and where you come up with better and cleaner code.

After a while I had made some nice progress, having removed about half of the code, and replaced it with a nice new fluent API. I turned around to tell the other developers on my team. Much to my surprise, there was nobody there. They had all gone out for lunch. And although afterwards they told me they had warned me, I hadn’t noticed. When in the zone, the outside world just doesn’t exist anymore.

The zone

For a developer the zone is a valuable state of mind. The code you write when in the zone is usually cleaner and of higher quality. Having written code for the past thirty years, I reckon that this state of mind is independent of paradigm, programming language, platform or architecture. You might say that when developers are in the zone, they offer the best value for money in the projects or organizations they work for. Taking this into account, you might also suggest that it is in the best interest of any manager or project manager to make sure that their developers can get in the zone often enough.

In my case, I can say I’m quite able to work in crowded or noisy environments. Heck, I’ve started writing this post while sitting in the arrivals hall at Schiphol Airport, waiting for my train to arrive. However, not everybody can work in such an environment. Most developers prefer a more relaxing and supporting environment to be able to get into the zone.

Writing code is not linear

There’s another observation I’ve made over the years when it comes to writing code. Writing code is not a linear process. Writing code requires a lot of thought. Combining many little pieces of code into a solution usually does not happen while typing away on the keyboard. It takes place in your head. You start with an idea, a little snippet of code, and start thinking about the next snippet, the consequences of adding that snippet, and how to move forward from that one.

As is mentioned on the c2.com wiki: Coding is a mental activity that eventually becomes transcribed into a particular language, in a particular file, in a particular machine. It’s the word eventually that I find the most relevant one in this quote. Programming is not an act of knowing how to type fast, or even knowing the exact syntax and all the features of the programming language at hand. Programming takes place in your mind.

The issue here is that this thinking process is far from linear. Your mind goes of in many different directions, trying to combine all sorts of patterns and techniques, until you find what you are looking for. Sometimes it works, sometimes it doesn’t. In that case you trace back, and start over again, adding new patterns and pieces, ending up in a different solution. And often all without even typing a single line of code.

In this aspect writing code is very similar to playing chess, where you analyze your next move by considering your opponents possible next moves, and your own responses to that move, until you’ve created a tree of possible moves, and pick the move that will give you the best result in the end.

From experience, this thinking process does not have to take place sitting at your desk. Sometimes I wonder around the room, or find my next move while in a meeting about a very different subject. I’ve witnessed developers staring out of the window for a while, and all of the sudden pace back to their machine and type away. I’ve figured out solutions while on the train, in airplanes, and in the car driving home.

Eighty lines a day

As a project manager, if you live with the idea that if a developer writes eighty lines of code per day, he or she will have written ten per hour, you should re-evaluate your ideas on programming. Now although measuring the amount of written code on daily basis seems a bit far-sought, many managers still think programmers will deliver more or less the same amount of functionality every two to four weeks. Even in the longer run, this idea doesn’t hold. I’ve never seen a team delivering the same amount of (whatever type of) points iteration after iteration.

In many projects I have witnessed a huge mismatch between the project manager and the developers when it comes to how writing code works, too often resulting in mistrust. In both directions. I guess this post is my attempt to clarify to managers and project managers how a programmer’s mind works in order to take away some of their frustration.

So, dear project managers, please mind the following:

• Programmers do their best work while in the zone. Allow your programmers to get into the zone. Don’t interrupt them continuously with meetings. I do believe in collaborating in multi-disciplinary teams, joint design sessions and stand-up meetings. But I also strongly recommend not to overload teams with meetings, in order to allow the developers to write code. You could for instance reserve a block in the morning for possible meetings, leaving the afternoon for writing code.

• Writing code is a not-linear production process. Don’t count on getting the same amount of work being done every day, every week or even every iteration. Don’t be surprised if a developers sometimes doesn’t even write a single line of code on one day, and seems to spit out line after line the very next day. Writing code is largely a creative process, not a production process.

• Writing code does not always take place at a desk. Preferably create an environment where there’s plenty of space to stroll, and room to think. A strict office setting is not always very stimulating coding environment. So consider getting some old couches from eBay, putting a ping-pong table in the hallway, and supply the teams with sufficient whiteboards and writing equipment.

• Writing code is not a nine-to-five job. Unfortunately most programmers are rather passionate about what they do. New ideas can surface 24 hours per day, while in the shower, on the train, or at lunch. Quite often I find a solution to something I was working on the whole day while I’m in my car driving home. Wouldn’t it be great if I could immediately switch on my laptop when I get home and start typing?

Dear project managers, I do realize programmers can make your life really difficult at times, especially when you have to procrastinate to the client. We don’t mean to. It’s just that what we do is very different from what most people think we do. Hopefully this short post can bridge the gap a little bit.

It is not like in the movies

And in case you’re wondering, I didn’t manage to bring back the two-thousand lines to two-hundred. I ended up with around five-hundred. So maybe one last reminder. Recently I saw the movie Unthinkable where FBI spends ninety minutes tracing a nuclear bomb. Of course, in the final scene they find it, agents open up a laptop, fire up Microsoft Excel or Word (not kidding), and start typing arbitrary characters. Needless to say, the agents dismantle the bomb two seconds before it explodes. This is not how programming works. Programming is not what it looks like in the movies.