The psychology of programming

This week I thought I'd describe to you some of the things that go on inside a programmer's head. With this knowledge you may be able to optimise your development environment and processes so as to make your programmers more effective.

This week I thought I’d describe to you some of the things that go on inside a programmer's head. With this knowledge you may be able to optimise your development environment and processes so as to make your programmers more effective.

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. Some have even claimed that programmers are borderline autistics which, if such a thing were possible, may well be correct.

The first thing to recognise is that writing code is an act of creativity. It isn’t science and it isn’t engineering, although when we’re able to we happily use both to help us out. 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.

Creative people often enter a state of flow when creating something new. 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.

Flow takes time to achieve, and it is fragile. If programmers are interrupted during flow it can take a large amount of time for them 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 s/he may never reach this state. Without this state our creativity is crippled.

The odd thing about flow is that 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.

This means that when a programmer is assigned a task they should be allowed to complete it without out-of-context interruptions. Ensure that any meetings to which you invite the programmer are absolutely necessary. Don’t interleave any support tasks with development tasks. Ensure that the people around a programmer are working on the same problem, and if that isn’t possible you should lock the programmer in their own room.

Another aspect of creativity is time. 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.

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, their 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.

He also mentions that one famous computer researcher who made a lot of discoveries in the computer field said that his firm lost several million dollars because they did not install a $14,000 shower in his office, since all his good ideas come when he's showering. "When he moved to a new firm that had a shower, his ideas kept coming out."

Now 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, each of them 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 2pm every day, then provide the facilities; it only takes a couch in the coffee room or in the breakout area (you do have a breakout area, don’t you?).

Or, how about this one: rather than provide a nice coordinated look for your offices, providing identical chairs and desks for all programmers, why not give each programmer a budget with which they can buy their own chair and desk. You lose that Martha Stewart look for your offices, and gain an environment in which your programmers feel comfortable and can be creative.

You may argue that to do so would lose you the benefits of a bulk purchase discount but, if you do, then you’ve missed the whole point of this column. Start again at the top, and pay attention this time.

You may say, "But think of the expense!". I don’t give a fig if this costs you more; 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.

Dollery is a Wellington IT consultant. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!

Error: Please check your email address.

Tags XP Trek

More about Creative

Show Comments

Market Place

[]