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.
, and to wonder whether most programmers are mildly autistic. )
