“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.
Actually, my favourite wording of the Law of the Instrument is:
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 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.
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:
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 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.