Knowing Where To Hit
Since this is a business lesson, this joke has a meaning behind it. See if you can find it.
You may be wondering what I'm talking about when I say that. This 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 consultant and a locomotive engineer.
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!
So what does this have to do with coding?
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."
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.