I'm a big believer in the 80-20 rule (http://en.wikipedia.org/wiki/Pareto_principle) because I see it work almost every day while developing business applications. After gathering the requirements and sketching the application, we try to identify that 20% of effort which will give us 80% of the results. Usually after building it, our users are so satisfied with the product that we only have to tweak a few more things and move on to the next high value item. If the business side thinks it's worthwhile to invest more in the product we proceed to identify what else will give the company the best bang for their buck.

The phrase "Use the right tool for the right job" gets thrown a lot and in my opinion it's just overated. You're much better off learning to use a small number of tools very well than trying to learn how to use a plethora of tools because you want to use the right tool for the right job.

Do you really need a tool set that will allow you to tackle nearly 100% of your home problems?

Or do you need a small tool set that will help you fix 80% of your home problems?

With a smaller tool set even if you don't have the "right tool" (an exact match) you WILL be able to do a decent job if you know how to use your tools.

Lets take an example from the software development world. If you know what kind of collection class you want/should to use (List, Collection, SortedList, Array, etc.) then go ahead and use it. The problem is that sometimes people fret too much about selecting "the right tool". Since the generic List class will solve pretty much 80% of your collection needs, just use it as a rule of thumb.