Pros don’t make do
I had a locksmith come out to replace a doorknob that had gone bad. It had gradually gotten hard and harder to turn and finally the bolt got stuck inside the door. Which meant the only thing keeping the door shut was the deadbolt. I had replaced doorknobs before, but this one had a non-standard length and strike plate so I didn’t want to mess with it. The thing that struck me while watching him work is that he never had to try and force a tool to do something it wasn’t designed to do. He always had the correct tool and it worked exactly the way he expected it to.
He never tried to screw in a Phillips head screw using a knife blade or a flat head screwdriver. He didn’t have to duct tape anything
I have a small battery powered Dremel rotary tool. It works for very small jobs. There have been a couple of times when I’ve had to push it way beyond it’s limit, including once when I needed to make the opening on a door jam for a strike plate a little wider. It took me forever. I had to charge the battery twice and broke a bit before I finally had enough room, but just barely enough room. Contrast that with the locksmith who had to do the exact same thing. He pulled out a much larger Dremel that plugged into the wall. Where it took me almost 45 minutes to rout out the door jam, he took about 2 minutes with his much more powerful tool. I could have stopped, went to the store, and bought a more powerful tool and gotten the job done much faster. But I thought that this tool would do the trick and going to the store would have cost me some resources, it might have taken a little longer. I’d have to learn how to use the new tool. Get a new bit. But overall, it probably would have saved me some time in the future and probably would have saved me some time on that project. I could definitely find other uses for the new tool.
Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution. Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.

November 23rd, 2009 - 10:19
Couldn’t agree more. My team’s current project has several major pain points currently that are due in large part to not taking the time at the beginning to learn to use the tools correctly. The people in charge are “duct tape” proponents, so we shipped something broken and are now trying to fix it as we go while the client flounders with a half-working system.
Your dremel tool story and my story both have the benefit of hindsight, though. In both cases, neither of us had the clairvoyance (either due to simply not knowing, or worse, being lazy and not caring) to foresee the pain that our bad decisions would bring. That sort of foresight only comes from experience, as far as I know.
November 23rd, 2009 - 15:31
Pro’s invest in their future.
[)amien
November 24th, 2009 - 17:25
I find this post strangely ironic given the name you go by Scott
Great post – short and to the point. Nuggets like these live on because they strike at the very heart of things that developers so often overlook!
We need more of these to point to.
Thanks,
Rob G
December 4th, 2009 - 01:37
Hi,
My name is Gil Zilberfld. We’ve discussed your post on our webcast “This week in testing”. We’ll be happy if you can comment, and if you like the discussion and content, let us know. And everyone else.
Thanks,
Gil Zilberfeld
Typemock
December 4th, 2009 - 01:39
and the link is: <a href="http://learn.typemock.com/this-week-in-test/2009/12/4/episode-6-analyze-this.html" Title="This week in testing"