How do you avoid the law of the instrument? [duplicate]

Question

This question already has an answer here:

• Should I be worried if I solve a lot of my problems the same way? 10 answers

A common expression you hear is "If all you have is a hammer, everything looks like a nail". It appears on Wikipedia as the law of the instrument.

It also manifests in IT, with developers, that, once they learned something, they use it... everywhere.

But how to truly avoid this if all you know of is a hammer at some point ?

Answer 1

Expect things to go smoothly. If you have an object X and a hammer H, and H fails to drive X into a plank of wood W, it must become obvious to you that X is not a nail, and H is not the right tool to drive X into W.

Answer 2

Tim Post nailed it in his comment.

Make sure that you either learn the basics of how to use other tools, or are at least aware enough of them that you know what they'd be good for.

This awareness will make you better able to judge the weaknesses of the tools you are using.

The other thing to realise is that sometimes using a non-ideal tool that you know how to use well, is better than you using the perfect tool badly.

Answer 3

Stay informed

You don't need to be a guru in the whole tools department, but if you stay informed, at least you've heard of the screwdriver and know where to look if you need it some day!

Read blogs, go to developer days, try other languages at home for fun or be active on StackOverflow? ;)

Answer 4

You must understand your tools

If you don't understand what your tools are for then you're not really a software craftsman, you're just blindly copying the actions of one. When you truly understand the nature of the tool, and therefore it's limitations, then you'll be much better placed to apply it where it is most effective.

You will also know when to leave it aside and use, or find, a different (perhaps better) tool.

Answer 5

I can't think of an advancement since the discovery of fire that didn't start with "There must be a better/easier way .." Except in science, where that is transformed to "There must be a better explanation .."

If you find yourself fighting your tools equally or more than the problem you hoped they would help you to solve, you need more tools. Have faith that your fellow programmer encountered a similar situation, and fashioned something much better suited for the task at hand.

I program mostly in C. I can't think of many things that I could not write using C, but I can think of many things that I wouldn't want to write in C. That's why my tool box also contains the following:

• Python - For any kind of desktop app or rapid prototyping, or string intense stuff
• Shell Scripting - For automating darn near anything
• PHP - For when I need to make something web related and find myself too lazy to use Python
• OCaml - When I need to go beyond a prototype and keep shooting myself in the foot with C
• Various esoteric languages for when I want to amuse myself

I was almost not going to answer this, but then you said:

but suppose, i only know of the hammer. is screwdriver a tool ? does it exists yet ? how long to learn to use it ?

If you are fighting something, you should realize that there is probably a better way of doing it. That way might exist with the tool you are using .. or it may mean you need to look for something else.

As for the time / learning curve, learning is always an investment. Are you going to be confronting many similar problems in the future? Would you like to deal with them in 1/10 of the time with code that doesn't break so easily? Then yes, learn a new tool.

If your back is against the wall and you have no time to learn something new, then you will probably elect to muddle through it using what you know and (hopefully) finish it. Still, let that serve as incentive to spend some time learning something new.

I can say, from experience, it is easier to learn a new language or method when you have a very specific problem in mind. It's not "oh, gee, I wanna learn Python" .. it becomes "I need to learn the innards of twisted because I need to make a working client for this API and my hammer isn't cutting it!" If you study examples that actually help you do what you want to do, you learn much faster.

Answer 6

I find that (at least in the .NET world) podcasts are a great way to survey new technologies, so that you know about the screwdriver.

Hanselminutes and DotNetRocks are especially good.

Answer 7

Get exposed to new stuff. You can talk to other people in the field, read blogs, read questions on SO, browse bookstore shelves, whatever. If you don't keep your eyes open, you won't know what's out there.

Once you've been exposed, you can learn more about what might help you.

And, to repeat something that lots of people have repeated in the past, get familiar with several different sorts of computer languages. You should be able to do procedural, object-oriented, functional, and declarative programming, at a minimum. Keep an eye out for things that you don't understand and puzzle you and learn about them.

Answer 8

Do things differently just for the sake of doing them differently. Some people will frown on this, but there's only one way to know if something works or not: try it out.

Answer 9

Every time you hear about a tool and think "that's a terrible idea.": Go use that tool. Many times your initial reaction to the tool indicates not how bad it is, but how little you understand.

• Think that significant whitespace is a terrible idea: Use python for a while.
• Think that dynamic typing will produce bugger programming: Use a programming language with dynamic typing.
• Think that Aspect Oriented Programming will result in a terrible mess of a code base?: Try using AOP on a project
• Think expressing an entire program as being a function of its input is a terrible idea?: Try Haskell
• Think running on a VM will be too slow?: Try Java

Once you have tried it, then you can judge whether it works for you.