It has often been said that programmers are introverts. I
find that this isnt 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 programmers 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 (Aspergers Disorder), and to wonder whether most
programmers are mildly autistic. I would be surprised if most programmers were
autisticour concentration is too easily broken.
Writing code is an act of creativity. It isnt science and
it isnt 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 isnt just that they dont
want to get buried in the filth of the past (although thats part of it);
maintenance doesnt 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
dont know about. Its through this recombination that something new may come
upnot when we try to push them directly.
Flow takes time to achieve, and it is fragile. If a
programmers flow is interrupted it can take a large amount of time for her to
regain the state, sometimes up to an hour. Thats 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 isnt 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 theyre doing, or even suggest a line of reasoning
to them, and everything will be fine. But if you ask them where their timesheet
is, youve broken it. Ive 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 theyre 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. Dont 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 isnt
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.
Im 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. Theyre 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 flowand thats 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, dont 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? Youll lose the Martha Stewart look for
your offices, but youll gain an environment in which your programmers feel
comfortable, which will inspire their creativity.
I know what youll argue: Think of the expense! If that was
the first thought in your head, then youve 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 arent thinking about the needs of
your programmers in the same light, then you probably arent getting nearly as
much of your programmers as you could be.
Our job is to enhance peoples 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 withif you cant bring out the best in
people then how can you bring out the best in your projects?
I dont 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 youll continue to produce mediocre results. Your software is
produced by humans; learning something about their psychology is a good idea.