“When all you have is a hammer, every problem starts to look like a nail” is but one of the many wordings of the infamous Law of the Instrument. Many of us are blinkered by our tools, instantaneously choosing what we know best to solve a problem—even though it might not be the best solution to that problem. It doesn’t take long to end up with complex solutions for simple things. Fortunately, the more tools you master, the higher the chance you choose the right one. Thus, an extensive toolbox is exactly what I recommend.

30 July 2013

Actually, my favourite wording of the Law of the Instrument is:

Give a small boy a hammer, and he’ll find everything he encounters needs pounding.

This implies things that don’t need hammering still get banged with that hammer, just because we can—just because it’s fun. Happy hammering is a far too frequently encountered practice amongst software engineers. We were the kids who couldn’t be taught to keep our hands off knobs and switches. Give us just a pencil and we launch it as a rocket, give us a toy rocket and your neighbors never talk to you again, ever. The only thing more dangerous than a creative kid with exactly the right tool is that very same kid without. Never trust a future engineer with your stuff. Or without.

Sadly, somewhere along the process of growing up, many of us loose the power to turn a toy rocket into a paint bomb. We become so attached to our tools that we don’t think out of the box. This is the Java programmer who will write two classes to parse a string (or three if that string is multi-lingual). This is the Fortran programmer who still does Fortran after forty years because it is the most robust programming language on earth (and should in fact be the only).

I’m not saying that Java is bad. I’m not saying that JavaScript, Ruby, Python, Haskell or any other tool in my toolbox is better than yours.
I’m saying that everyone’s toolbox should have at least five hammers, and that you shouldn’t carry around the same ones for the rest of your life.
Learn a new programming language every year.

Nailing a hammer

In the end, more important than choosing the right tool is how you use it. And this is another reason why I highly recommend learning to master other tools as well. There is a lot of cross-talk going on: my knowledge of Ruby made me a better Java coder; my experience in Haskell lets me write better JavaScript. Even if you know you need to use that one hammer, then still it pays off to bring the whole toolbox. Every acquired skill lets you think about your tools differently and makes you a better engineer.

One of the great self-tests to see how flexible you are is the Five Essential Phone-Screen Questions. As an opponent of IT-monolingualism, my favorite quote is this:

Many C/C++/Java candidates, even some with 10+ years of experience, would happily spend a week writing a 2,500-line program to do something you could do in 30 seconds with a simple Unix command.

If you’re anything like me, you’re now visualizing the happily hammering kid. Oh yes, everything needs a good Java pounding, why not?

I especially recommend learning the basics of Unix-like systems, precisely because they are created like a toolbox: they do one thing well, and only one thing. They made me a better developer, as I see more opportunities to break down functionality into smaller parts.

The universal hammer

The absolute worst kind of thing you’ll ever see is when people can’t think of any other solution than the one they have. Or if they can, but think they shouldn’t. There’s a great case of a company who as offered a more agile solution in JSON, but refused it because it was not XML.

Speaking of which, XML is a wonderful example of a mythical does-it-all hammer. Around the year 2000, is was going to solve all our problems. Now it’s JSON, although discussions are substantially less religious. The thing is that we should always remember that the tool is just a tool. Once it starts becoming a goal by itself (“must solve this problem using X”), the road is endless and boring.

Every time a new technology is born, it’s difficult to resist the immense optimism. The Semantic Web was also going to solve everything. When I started doing semantic research, I considered the Semantic Web vision as this goal we were all working towards. But along the way, I was reminded often enough that it is just another tool in an ever expanding toolbox.

It was never about the hammer. It has always been about the nail.