AdviceToolbox
though, because they have to deal with the
exceptions before they happen.
Programmers tend to be people who like
order and love exceptions. This can make them
annoying, because they love to point out the
one obscure counter-example to your otherwise
sound explanation. Who doesn’t love a good
round of “Spot the logical flaw”? Many non-
programmers, that’s who.
SECOND-GUESSING
Programmers have an interesting relationship
with rules. They both respect and can’t stand
rules. Specifically, they like sensible rules and
will not tolerate nonsensical rules. Of course,
nonsensical rules are defined as rules they don’t
feel are worth listening to. They don’t phrase
it that way; they say those
rules are outdated, illogical,
contrary to stated policy, or
just stupid. But once you
translate the nerd-speak,
that’s the bottom line.
Programmers are also looking for the ultimate
elegant solution. Not only must they handle every
possibility, but they also want to be as efficient
as possible. To this end, software people are
constantly spouting, critiquing, and reforming
ideas before settling on an approach. They’re
chasing the question: “Is this the best solution?”
(Fun fact: the efficiency of a programming effort
is typically measured by how nicely it solves
the problem, not by how long it takes to create
the solution. Time to creation may be ignored
entirely – by the programmer, not their manager.)
Once a path is finally chosen, the second-
guessing and reworking begins. Warning:
doing this for extended periods may have side
effects. The impact ranges from the comic to
the tragic. My wife sums it up nicely with: The
Cabinet Story...
wfmag.cc \ 29For her, it was simple. “Sweetheart, could you
please move the office cabinet to the den?”
“Absolutely.” Done.
Twenty-five minutes later, she comes by the
office. I’m striking a pensive pose, staring intently
at the open (but as yet untouched) cabinet.
“What are you doing?” she asks.
“I’m thinking about the best way to do this.”
“You take the books and games out, move the
cabinet, then put them back in. That’s the best
way to do it.”
“But where do I put them in the meantime?
Should I move them to the den as I take them
out or move them later? Do we really need
all this stuff, maybe this is the time to dump
some of it? Oh, there’s
backgammon, we used to
play backgammon, that was
a lot of fun. Or maybe I can
carry it without having to
remove everything. What’s the
minimum stuff I can take out and still move the
cabinet? Maybe we should get a handcart, that
will save time on loading and unloading.”
“Save time? Seriously? It’s been half an hour.
You could have done it already!”
“Look, planning time is just overhead. I’m trying
to optimise here!”
She disappears down the hallway, but her sigh
of exasperation lingers. In moments like this,
I’m glad she loves me, but this is what it looks
like when Programmer Brain kicks in. It’s a place
where my approach to the task becomes more
important than completing the task.
Remind you of anyone you know? Programmer
Brain isn’t a side effect, it’s a full-on world view,
and a fundamental way of being. It becomes the
systems analyst’s system of analysis... for better
or for worse!“Programmers tend
to like order and
love exceptions”Game
programmers
Those wacky computer
programmers. They do have
their quirks and eccentricities.
However, there is a subset
(or inheriting class) of
computer programmers
that’s even wackier: video
game programmers. Game
programmers have all
the wackiness of regular
programmers, but their
neurotic engines rev at
higher RPMs. That’s because
regular programmers only
have to meet a spec. Game
programmers must hit their
spec and still clear one more
hurdle: the game has to be fun.
Want to drive a programmer
insane? Give them a
specification with subjective
criteria for success. When are
we done? When a bunch of
middle-schoolers say so. Howard Scott
Warshaw, in full
Programmer Brain
mode at Atari in the
early eighties.