Knowing Where To Hit

As a consultant, most don't know where to start with new systems. In the end, it's all a matter of knowing where to hit

Written by Jonathan "JD" Danylko • Last Updated: • Business Lessons •

Man using a hammer to hit wood

This is a repost from 2010-Jan-28 titled "Knowing Where To Hit." This was another post I wanted to freshen up a bit.

This post has stood the test of time since I've referred a number of developers to it and a couple of my consulting friends got a kick out of the joke as well.

So what do I mean when I say you have to know where to hit?

Well, this saying refers to a consulting joke that I've been carrying around for a while from one of my ex-bosses. Very wise man and a good friend.

The joke is about a locomotive engineer who calls a consultant.

One day, a consultant was called by the locomotive engineer to examine a locomotive that was making a loud noise. The staff couldn't figure out what was causing it.

The consultant walked over, ran his hand over the noisy section, and asked the supervisor to bring him two things: a large sledgehammer and their biggest guy to swing it.

The supervisor was accommodating and brought both over to the consultant within 10 minutes.

The consultant ran his hand over the noisy section again, marked an 'X' on the dirty steel, and looked up at the guy with the sledgehammer and said "Hit it right there!"

Both the supervisor and large man shrugged. The large man swung and connected the sledgehammer with the side of the locomotive. Immediately, the noise stopped.

Everyone was amazed as to how he used the "sledgehammer" approach and quickly fixed the problem.

He submitted his invoice to the client for $5,000. Standard procedure.

A week later, the consultant receives a letter in the mail to itemize the invoice for tax and auditing purposes.

The consultant immediately sent a revised invoice back that explained the following:

$10 for the time of materials and labor (sledgehammer and resource) and $4,990 for knowing where to hit!

There are a number of consultants who I can actually hear laughing at this.

What's the Point?

So what does this have to do with coding?

When a bug is caught in code and a developer is asked to fix it, said developer may not understand the system and is thrown off the boat without a life-preserver. Just for clarification purposes, if you throw developers at a problem, does 1 developer equal 1 developer? No, it doesn't.

I've seen developers write large amounts of code to fix something when all that was needed was one or two lines.

Most seasoned developers analyze the situation first, then decide on the best approach that will take the least amount of time and provide a quick solution.

After the analyzing phase is done, they have a good understanding of the system and they know where to hit. At this point, they proceed to code like a madman. I usually call this "the coding frenzy." They have a clear path in their mind and they know how to attack and solve the problem.

For those new to coding coupled with learning a new system, developers now have three problems:

  1. New to coding practices/industry
  2. Learning a new system
  3. Fixing the bug initially reported

They may not be familiar with the system or design patterns and start writing code to work around something. They require knowledge from either a developer's point of view who understands the system or work experience in the industry to identify familiar coding patterns.

Either way, furthering your coding education or asking for help can provide clues as to how to fix certain problems and this allows developers to "know where to hit" in the code.

How do you solve your coding problems? Do you based your solutions on past experiences? Do you hesitate and analyze before you start coding like a madman? Share your discussion in the comments section.

Did you like this content? Show your support by buying me a coffee.

Buy me a coffee  Buy me a coffee
Picture of Jonathan "JD" Danylko

Jonathan "JD" Danylko is an author, web architect, and entrepreneur who's been programming for over 30 years. He's developed websites for small, medium, and Fortune 500 companies since 1996.

He currently works at Insight Enterprises as an Architect.

When asked what he likes to do in his spare time, he replies, "I like to write and I like to code. I also like to write about code."

comments powered by Disqus