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: [phone] (U.S. and Canada) + 1.212.626.0500 (Global)

+ 1.212.944.1318

8: 30 a.m.-4: 30 p.m., Eastern Time [e-mail] 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 ( [e-mail]) 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.