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
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:
- New to coding practices/industry
- Learning a new system
- 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.
