There is a specific level of concentration required to write good code. Some programmers call this “the zone” or give it other such terms, but all of them - or at least the good ones - know how to put themselves in this state and just let the code flow. In order for the binary tokenizer you’ve been tasked with writing to function as expected, it needs to be your whole world for the few hours you may spend on it. Then, it’s abstracted away and left alone for as long as possible (and not any longer). Unfortunately, this very focused mindset can cause problems if interrupted. I’ve seen otherwise brilliant software engineers make intern-esque mistakes and I attribute those mistakes to this phenomenon. Here’s a (somewhat) contrived scenario:
Pointy Haired Boss calls several people from the engineering team into her office.
PHB: “The site is down and we’re loosing money.”
Inter: “I looked at that. The disk is full on the cluster head because of all these pesky errors being thrown to the log files. Let’s just comment out the errors and delete all the logs. In fact, let’s redirect the logs to /dev/null from now on to make sure this doesn’t happen again.”
PHB: “Great! Do it in the next 20 minutes and you have a job when you’re out of school.”
The Right Answer is obvious: Find why the error is being thrown and fix it. Whomever wrote the code logged those errors for a reason. Maybe a cron job and shell script to compress the logs and move them off the production servers would be a good idea. Asking your sysadmins to add a check for disk usage to their nagios/bigbrother monitoring system would round things out nicely.
This is where the slope gets slippery. Given that you have your own deadline to meet, and the Intern’s option could be done in a single command line, the first option may be tempting. You’ve already waisted enough time meeting with the PHB and your anxious to get back to work. Realizing that the interruption has already cost you at least an hour, you’ll need to fix the problem and then context switch back to your tokenizer. Fixing the problem The Right Way is going to take at least another hour, which probably means you won’t get to finish the tokenizer today. Killing those logs and getting back on track is sounding better. Maybe just killing them for a few days would be ok. Write yourself a post-it note and put it on your monitor. You’ll get around to it. Honest.
And so, an otherwise good software system now has a really bad patch. Stupid.