Steve stared at the empty screen for a moment, confused. The text editor had casually informed him that it was creating a "[New File]," but the file should have already been there. Steve had been editing it all day. In fact, he and Donna had been working all weekend to get the project finished before Monday. Had he finger-fumbled the filename? Was he in the wrong directory? No, he was typing the right name in the right place. "It's something stupid I'm not seeing because it's Sunday night at 11PM and I'm too tired," thought Steve as he vainly tried to reconcile the conflicting details of his shell history.
Then he saw it. In preparation for a build, he had meant to delete all the intermediate object files, but he had deleted the source files instead. The extensions only differed by one frickin' character, and that was the one he got wrong.
The enormity of Steve's mistake began to dawn on him as he went down the list of fail-safes and watched each one crumple like Wile E. Coyote's umbrella under the weight of a falling boulder. He and Donna had been working in the same directory to save time. They hadn't committed anything to source control all weekend for fear of breaking the build, and they hadn't gone to the trouble of establishing a branch. The last backup occurred Friday night. They lost the entire weekend's effort.
Even if Steve hadn't mistyped that command, it's possible something else like that might have happened, or that he and Donna might have introduced more insidious errors. Their mistake was much broader than one typo: they were in a hurry, and they were tired.
It's a lethal combination, and the two often worsen each other. When you're hurried, you burn up more of your energy fretting over the schedule. When you're tired, you just want to hurry up and get finished. Both things can lead you to take risky shortcuts and make careless errors. We should slow down instead when our brains aren't functioning at 100%, but we're usually like the Seattle drivers in the rain: we speed up to get it over with quicker.
Self-diagnosis is also problematic. We usually know when we're hurried, but we often can't tell when we're tired until we make a stupid mistake. We need to be able to gauge our alertness before we mess up something important.
One tool I use to perform a periodic self-evaluation (as well as to take a much-needed break) is to play a game. You have to choose your game wisely, though. It shouldn't have such a long duration or require so much mental effort that you burn up all your time and energy playing it. Five minutes or less is ideal. It should provide a tangible result that will serve as your alertness score. Most importantly of all, it should test the relevant parts of your brain. Given that, playing it will serve the dual purpose of evaluating and improving your faculties.
There are exceptions, but they're pretty easy to recognize. For instance, at the very beginning and especially towards the end of the game, you may confront a situation in which there is no logical way to determine the location of mines, and you're forced to guess. If you step on a mine at that point, that's not a measurement of your ability.
There's also the odd outlier: I achieved my best score ever one late night after three beers when I was angry. I wasn't even thinking about the game, I was thinking about the events that had upset me, and I just let my cerebellum play the game on its own in order to burn off some energy. Winning surprised me, and setting a new record for myself even more so. But that's a different phenomenon called doing without thinking. Real work for clients usually requires some thought.
What you're looking for is the specific kinds of mistakes you make. For instance, a well-known pattern is 1-2-1. Whenever you see that, you know that there is a mine by each 1, and no mine by the 2. However, if you see 1-2-2 and mark the 1, you've either mistaken the pattern or confused the valid assumptions about it. That's an indication that your concentration is lacking.
Once you've determined that your brain is operating on reduced power, the best thing you can do for your client and yourself is to stop working; otherwise, you will likely create more problems than you solve. However, if you must continue anyway, at least slow down. Double-check your assumptions and your conclusions. Don't cut any corners on the good practices (like source control and backups) that can save you if you do fail. The explosion you avoid could be your client's.
Thanks to TechRepublic member Bob Eisenhardt (reisen55) for suggesting another great topic idea.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.