ACM Digital Library
www.acm.org/dl
The UltimateOnline
INFORMATION TECHNOLOGY
Resource!
• Over 40 ACM publications, plus conference
proceedings
• 50+ years of archives
• Advanced searching capabilities
• Over 2 million pages of downloadable text
Plus over one million bibliographic
citations are available in the
ACM Guide to Computing Literature
To join ACM and/or subscribe to the Digital Library, contact ACM:
Phone: 1.800.342.6626 (U.S. and Canada)
+ 1.212.626.0500 (Global)
+ 1.212.944.1318
8: 30 a.m.-4: 30 p.m., Eastern Time
acmhelp@acm.org
www.acm.org/joinacm
ACM Member Services
General Post Office
PO Box 30777
New York, NY 10087-0777 USA
Fax:
Hours:
Email:
Join URL:
Mail:
again but expecting a different result.
You don’t want your coworkers to
think you’re insane, unless, of course,
you like sitting along at lunch. Still,
there are better ways to convince people you’re out of your mind than repeating the same stupid process and
getting nowhere.
What you describe makes you
sound more like a changeineer than
an engineer. What’s a changeineer?
Usually this is the person they send
out to a remote site, like a data center,
when something breaks. They don’t
really know how the system works or
how to fix it, but they do know how to
change every single component in a
system until the problem magically
disappears, at least for a few days. Disk
is slow? Change the disk. That didn’t
work? Upgrade the CPU. Still slow? Get
faster RAM. Ad nauseam.
Changineer is a term I learned from
some friends who work in a data center. Unsurprisingly I heard the term
over drinks, at lunch—yes, it had been
that kind of day. They see changineers
every day, and learn to spot them and
do away with them quickly so they can
get problems solved instead of having
them obscured by many random new
components.
The thing you want to avoid is becoming a changeineer. Changineers
use their hands, or worse, a text editor,
while engineers use their heads. When
you find yourself doing the same thing
over and over and you’re still frustrated
it’s time to walk away from the problem and think about it. Paper and pen
or pencil are still the best for this, or
perhaps a whiteboard. Write down the
symptoms. Think about what could be
causing the problem. Come up with a
hypothesis—that is, a guess—about
the real cause of the problem. Figure
out how you would test your guess.
Then test the guess. The process can
also be repeated but unlike the process you described each change is preceded by careful thought. You’re a lot
less likely to go on spinning around.
Kv
George V. Neville-Neil ( kv@acm.org) is the proprietor of
Neville-Neil consulting and a member of the ACM Queue
Editorial board. he works on networking and operating
systems code for fun and profit, teaches courses on
various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Communications column.