Step 9: Check Your Code First Before Looking to Blame Others~Allan Kelly
This is the Ninth Step towards gaining the Programming Enlightenment series. If you didn’t learn the Eigth Step, read it.
“Before you point fingers make sure your hands are clean.” ~ Bob Marley
Bug free code is a myth. As a developer we often envision whatever better code we put in, is the best. The tendency of the usual code base is to create another bug when one is solved, because no code is free from Technical Debt. We introduce new code or clean the legacy code, which is well tested and may introduce new bugs. Every introduced has history, which is preserved by the power of source control.
With VCS power comes the responsibility?
There are many Version Control System and with it comes the power to write/rewrite/rewind history. A simple look at history of the committed code, will show who/when/why did the commit in first place.
$ git log commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test code
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 10:31:28 2008 -0700 first commit
This power will give any developer who committed the certain piece of code. It is the source of truth as to why there is some issue with the code and why it happened. Most often the commit history will have your own name in it. So, we must be aware to Git Blame others.
Think about Tools and Technology stack?
Most of the tools and technology stack that one developer uses are tested and hardened over time. There will be little doubt to reason the quality of it. But, if you are an early adopter for different tools, than there might be some doubts. In that case, you can succumb to blame the tools of the trade. Especially, when you are dependent on some physical hardware to test your software, this is always a probable situation.
But even before pointing the finger at tools and technology stack, we should try to eliminate all possibilities that might have introduced the broken code. Just keep in mind, this means a lot of time, support time and management time will be wasted to investigate with petty results.
Deductive Reasoning?
Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. ~ Arthur Conan Doyle
It will be very hard to track if it’s the tools or technology stack that’s causing the damage, as those are out of our understanding depth and control. So, we must try to eliminate the impossible and deduce it’s the tools. We should question our own assumptions and the assumptions of others. What I’ve found so far with my experience, is if you pair/talk with your co-workers, magically the faulty part may surface.
TL;DR Always question your assumptions, wear the hat of fellow developer and think differently. Never blame others, try to fix the problem.
Go to Eight Step.
Go to the Tenth Step.
References:
- 97 things Every Programmer Should Know ~ Git Book
- 97 Things Every Programmer Should Know ~ Paperback
- Git as Versions Control System ~ Web
- Git Blame ~ Git
