What does your nail look like?
In a previous post, I outlined a habit I have of using, over-using, and downright abusing “new” tools that I learn for a while – until their novelty wears off I start to learn the line between when it is, and when it is not, appropriate to use them. Here’s the gist:
I call this the New Solution Syndrome. The person has been given a new tool. A new way of doing things. A solution in search of a problem. People (when subject to the New Solution Syndrome) will then go, and try to find problems to solve with their new tool, even if it isn’t necessarily the quickest, cheapest, or more significantly, the best tool to use for the job.
Posted to that article was a particularly concise comment:
Think of it this way: you used the hammer so much in the right and wrong situations that you developed a very accurate picture of what a nail is supposed to look like.
Reflecting on this, I had one of those coding “poof” moments. One of those thoughts that you – and every mother’s son what calls himself a coder – has thought thousands of times before. Sometimes, though, I think we have these thoughts without ever… truly… groking the real concepts at hand. Say you have some sort of tool (i.e. a hammer) to choose for each of the following:
- Before you go to create a repository for that new project, figure out what the nail looks like.
- Before you go to author a brand-new file, figure out what the nail looks like.
- Before you write another function/method, figure out what the nail looks like.
- Before your mind starts wandering about how best to re-write that bottlenecked bit of code, figure out what the nail looks like.
- Before anyone can cloud your vision and poison your thoughts with their own opinions about architecture, figure out what the nail looks like.
- Don’t even think about changing that server config file before you figure out what the nail looks like.
“Duh,” “obvious,” and “what does this guy take me for?” are all responses I would expect you to be thinking at the moment. But take thirty seconds, and think about some recent software development faux-pas. I don’t mean general coding blunders – a seg fault here, an array index out of bounds there, a few NullPointerExceptions and a nice infinitely recursing function – those are the minutiae of our work. I want you to think of system design flaws, overly complex interfaces, major scaling problems, or a case of software simply not meeting its spec.
Why do these things happen? [And they do happen, in the real world.]
Because someone, somewhere down the line, sat down and grabbed a hammer before they really knew what their nail looked like. Maybe they sat down and spilt too much rhetoric at a board meeting, maybe they stood and drew inaccurate pictures on a whiteboard, maybe they sent that usability report off in too much of a hurry, or maybe they chose a language based on mere whim and personal preference. It doesn’t matter. That person didn’t take the time to fully comprehend the task at hand, and now there are issues.
If that person was you, then it’s your fault for failing to look before you lept. Accept that, move on, and pay attention next time.
If that person was a superior, then it’s your fault for letting someone else think for you. Accept that, move on, and pay attention next time.
If that person was an inferior, then it’s your fault for leading them astray. Accept that, move on, and pay attention next time.
At the risk of digressing into a societal flame war here, I need to say that people are far too concerned about shifting blame, and about appointing credit, and not nearly concerned enough about getting the job done right. Coding well is as much about taking responsibility and ownership, and about making informed decions, as it is about writing code. One of the easiest areas to start this habit is in choosing which tool(s) to use for a given job. Of course – you can’t know what kind of hammer you need until you figure out what the nail looks like.