How to be a “Dirty Harry” programmer

"Dirty" Harry Callahan (© Warner Brothers)

How often have you heard and/or told this story?

Right before the project started I’d seen some blog posts about Tool X and I really wanted to give it a try. So I talked the other developers into using Tool X. At first it went really well, but we kept on running into problems with the tool, and no one else seemed to be able to offer any solutions. About a year in we realized it had been such a disaster that we took six weeks to completely strip out Tool X and go back to Tool W. Looking back, I think we really misused the tool because we didn’t fully understand it. And I don’t think it was the right kind of project for Tool X anyway.

You can freely substitute “Practice X” or “Methodology X” for “Tool X”.

For any relatively new tool, practice, or methodology in programming there are typically two camps among the people who have tried it. There are the true believers: the people who completely embraced the tool and can’t understand why anyone wouldn’t want to use it once they’ve tried it. And then there are the skeptics, people who have tried to tool, been burned by it, and think that the true believers have been drinking spiked kool-aid. Often the skeptics have a story to tell of some true-believing early adopter insisting on using the tool and as a result setting their project back by several months.

This is a .44 Magnum, the most powerful handgun in the world, and would blow your head clean off.

— “Dirty” Harry Callahan

Dirty Harry was a guy who liked powerful tools. The Smith & Wesson Model 29 revolver he used really was the most powerful production revolver in the world at the time it was introduced. In fact, it was so powerful that it wasn’t for everyone. Here’s Major Hatcher, writing about the gun in American Rifleman in 1965:

In shooting the .44 Magnum, we found it advisable to use gloves, as the recoil can only be described as severe. Without gloves, the checkering hurts the hand, and the sharp edges of the cylinder latch are almost certain to shave off bits of skin. After firing many heavy handloads in the .44 Special, we expected a heavy recoil with this ultra-powerful new cartridge. At the first shot the gun rose up a bit, and the first reaction was that it was not as bad as we had expected. Just about that time, however, we suddenly experienced a sharp stinging sensation over the entire hand, as though we were hitting a fast baseball with a cracked bat. I fired quite a few shots with this gun, but I must honestly confess it is not an unmixed pleasure.

A tool like the Model 29 is only useful – and safe – in the hands of someone who has the strength and experience to control it. Someone like Dirty Harry. An inexperienced shooter wielding the gun would be lucky to hit the target, and might very well cause themselves injury in the process. The same is true for any other powerful tool, even if it’s just a tool for thought – like Test-Driven Development, or Object-Oriented Design.

It is not enough to know that a tool exists, or that others have found it useful. In order to add value, you must also know how to wield the tool effectively. And if you are working as part of a team, while not everyone on the team has to be a pro at using the tool, you need enough tool-experienced members on the team to help bring the less-experienced members up to speed without stalling development.

A man’s got to know his limitations.

— Dirty Harry

There is a huge difference between knowing a tool, and mastering that tool. Part of maturing as a craftsman is understanding that difference, and having the self-awareness and humility to recognize where you are on that continuum. This ability to recognize your limitations with regard to a particular tool is vital. It’s the difference between saying “this is so awesome, I can’t wait to use it in my next project”, and “this is so awesome, but I don’t know enough about it yet and neither does anyone else on the team, so I’m going to hold off on using it on client work”.

As enthusiasts for our craft, it takes a lot of self-discipline to say this. We naturally want to apply the latest tools and techniques to our current work.

How do you identify your limitations? How do you know if you’re ready to not just explore a new technology, but to add value with it? Here are some questions you can ask yourself next time you’re deciding whether to use a new tool or practice:

  1. Have I been actively using it for six months or more?
  2. Can I describe a situation in which I would opt not to use the tool?
  3. Can I describe three or more incorrect ways to apply the tool?
  4. Are my team members familiar with it; or, am I confident in my ability as a teacher of the tool?
  5. Who will I call for one-to-one help when I run into a roadblock with the tool?

If you can’t answer all of those questions, you should consider sticking with the tools you’re more familiar with for now.

“But” you may object, “isn’t this a chicken-and-egg situation? Isn’t trying a tool on a real project the only way to master it?”

This is indeed a conundrum. Here are two suggestions for how to become more comfortable with a new tool or practice without using your client as a guinea pig:

  1. Use it in your personal projects. Most enthusiast programmers have side projects that they work on in their spare time; these are an excellent place to try out new tools and techniques.
  2. Work with an expert. See if there’s an opportunity to work with someone who has mastered the tool — for instance, by bringing them on as a consultant on a part-time basis. Make sure you and every other member of the team has an opportunity to work closely with the expert, observing how he or she makes decisions about how to apply the tool. Note that this is very different from hiring someone to teach a class on the tool.

What about you? Do you have any stories about the difference between knowing a tool and mastering it? How do you stay on the cutting edge without endangering projects with unfamiliar techniques?

P.S. before I get a zillion comments pointing this out, yes, I know, Dirty Harry is in many ways a poor role model for programmers; not least of which being his inability to work well with others. I wouldn’t recommend trying to stretch this particular metaphor very far.

1 comment

Leave a Reply

Your email address will not be published. Required fields are marked *