Being a Better Programmer #3: Ahab and the White Whale Snippet

As developers, we solve problems for a living. We spend our hours at work fixing things, testing things, troubleshooting things. It gives one a great sense of pride and accomplishment to fix almost all the tech problems that get in the way of productivity. But what happens when this need to solve problems becomes the problem itself?

“Commonly, people believe that defeat is characterized by a general bustle and a feverish rush. Bustle and rush are the signs of victory, not of defeat. Victory is a thing of action. It is a house in the act of being built. Every participant in victory sweats and puffs, carrying the stones for the building of the house. But defeat is a thing of weariness, of incoherence, of boredom. And above all of futility.” - Antoine de Saint-Exupery

I spent 6 hours on one problem this week. I am not proud of it. In fact, I'm really pissed off. You want to know why? I quit. I gave up. I had to. I had to move on. All I wanted was a simple SQL statement which would magically pull the data from 6 tables in the right way that it would output all possible paths in through the data which has not already been taken. I know it's possible, but I also have no idea how. It's frustrating. I gave up and broke it up into multiple SQL queries within a single for loop. In hindsight, I should have done this from the beginning as efficiency is not even close to one of the requirements for this project. It still brings a tear to my eye to think that I couldn't get the right answer I was looking for.

But I spent 6 hours being productively non-productive.

I'm sure it brings a tear to my project manager's eye to think that I didn't move on earlier. I would have, had I not felt so close to the answer.

I felt like Ahab chasing the White Whale. I knew what I was looking for was just below the surface, waiting to be discovered... but every time I thought I saw it, the answer eluded me. Due to the nature of the project, I couldn't ask for help. I couldn't get feedback on why my logic was wrong. And as a result, I could only look in the mirror at the end of the day knowing that if I had just tried harpooning from a different angle I might have caught my blasted white whale. The moral of the story? A programmer programs. Avoid getting caught in an obsessive-compulsive cycle. Do not let your ego rule your coding. Get the job done first, then worry about the white whales. Sometimes it's ok not to have all the best answers. The idea is to be productive, not productively counter productive. To learn to do this is to be a better programmer.

If you enjoyed this article and wish to read more by Collin Cusce, visit his site HumanErr at http://www.humanerr.com/