Psychology of Programmers by Dollery B

It has often been said that programmers are introverts. I find that this isn’t true, in the majority of cases, but programmers usually do have a longer attention span and a greater ability to concentrate than the majority of the population, and these two things can cause the appearance of introversion.

A programmer’s ability to focus on a single task for long periods to the exclusion of all else has led some people to comment on similar behavior in autistics (Asperger’s Disorder), and to wonder whether most programmers are mildly autistic. I would be surprised if most programmers were autistic—our concentration is too easily broken.

Writing code is an act of creativity. It isn’t science and it isn’t engineering, although programmers are happy to apply science and engineering to the creative process, when possible. Therefore, to be a programmer one has to be highly creative.

This is one of the reasons programmers are happier working on new projects rather than maintenance projects. It isn’t just that they don’t want to get buried in the filth of the past (although that’s part of it); maintenance doesn’t offer them the opportunity to create.

When creative people work on making something new, they often enter a mental state where things just flow. This is a highly desirable state, both for the programmer herself and for the organization that profits by her labors.

Professor Mihaly Csikszentmihalyi of Chicago University, formerly the chair of the psychology department, has studied hundreds of exceptional individuals, from IT entrepreneurs to Nobel Prize winners, researching creativity. He has written many books and papers on the subjects of flow and creativity.

Csikszentmihalyi says: “For original ideas to come about, you have to let them percolate under the level of consciousness, in a place where we have no way to make them obey our own desires or our own direction. So they find their way, [through] random combinations that are driven by forces we don’t know about. It’s through this recombination that something new may come up—not when we try to push them directly.”

Flow takes time to achieve, and it is fragile. If a programmer’s flow is interrupted it can take a large amount of time for her to regain the state, sometimes up to an hour. That’s an hour of lost productivity to your team. If a programmer is interrupted many times during the day she may never reach this state. Without this state, creativity is crippled.

Flow is fragile but, thankfully, it isn’t as fragile as it first seems. Flow can only be broken if an interruption requires a programmer to mentally change contexts. This means that you can tap a programmer on the shoulder and ask them what they’re doing, or even suggest a line of reasoning to them, and everything will be fine. But if you ask them where their timesheet is, you’ve broken it. I’ve heard this time and again from experienced pair-programmers, and they should know:

Pair programming would be impossible if flow were any more fragile than it is. Flow is a context-dependent state in which you can mentally maneuver to perform different tasks, as long as they’re all within context. Drop out of the context, and it takes a while to restore it.

Making Flow ... uh, Flow

So how can you maximize the power of this mystical flow for your development team? The formula is fairly simple: provide adequate insulation for flow to occur, both mentally and in terms of time, and be flexible to the vagaries of individual work preferences.

Provide Adequate Mental Insulation

When a programmer is assigned a creative task of any scope, they should be allowed to complete it without out-of-context interruptions. Ensure that any meetings to which you (or anyone else) invite the programmer are absolutely necessary. Don’t interleave any support tasks with development tasks. Do your best to arrange it so that the other people who work in the vicinity of a programmer are working on the same problem; if that isn’t possible, you should isolate the programmer in his or her own room.

Provide Adequate Time to Recharge Creative Energy

If you want your programmers to repeat the mistakes of the past, fine, just drive them like dogs and give them no time to relax. If you want them to create innovative solutions, then let them have a rest.

Accommodate Reasonable Special Requests

In his research, Csikszentmihalyi cites the case of a famous computer researcher who made a lot of discoveries in the computer field who said that all his best ideas came to him in the shower. He said that he believed his firm lost several million dollars during his employment because it did not install a $14,000 shower in his office. “When he moved to a new firm that had a shower,” wrote Csikszentmihalyi, “his ideas kept coming out.”

I’m not proposing that you provide new showers for your programmers (not all of them, anyway), but you should stop treating them as pluggable units, each with similar capabilities. They’re individuals, different from the others in many ways, each with their own rhythms and preferences. Most of them will know what it takes for them to get into their flow—and that’s what you need to cultivate.

If a programmer tells you that they need a 15-minute nap at 2 p.m. every day, then provide the facilities; it only takes a couch in the coffee room or the breakout area (you do have a breakout area, don’t you?).

Or, how about this one: rather than provide identical chairs and desks for the whole team, why not give each programmer a budget with which they can buy their own chair and desk? You’ll lose the Martha Stewart look for your offices, but you’ll gain an environment in which your programmers feel comfortable, which will inspire their creativity.

I know what you’ll argue: Think of the expense! If that was the first thought in your head, then you’ve missed the whole point of this column. Start again at the top, and pay attention this time.

When you hire graphic designers to create the eye-candy on your Web site you probably give them the proper tools, environment, and flexibility to encourage creativity. You tolerate their character whims and buy them strange transparent computers. If you aren’t thinking about the needs of your programmers in the same light, then you probably aren’t getting nearly as much of your programmers as you could be.

Our job is to enhance people’s talents, and hire enough diversity to cover the flaws. You should be trying to bring out the best in all the people you manage or collaborate with—if you can’t bring out the best in people then how can you bring out the best in your projects?

I don’t care if this costs you more money; the potential benefits are huge. If you continue to view the world as a risk/value proposition then you’ll continue to produce mediocre results. Your software is produced by humans; learning something about their psychology is a good idea.