Don't question others until you've questioned yourself.
Developers, especially new developers, often forget this when debugging. We jump into the debugger. We add tracing statements. We review the commit log.
Such actions can be misguided. Before debugging the code we must follow a moral code. Debugging needs a Golden Rule. A rule to remind developers of a few important facts of debugging.
99% of the time it's you
I had an excellent TA for my introductory Computer Science course. He gave great advice for improving your craft. Some of which became the foundations for routines of a good developer.
In one of our more difficult labs he expressed his frustration with the class:
Listen up! Stop asking me, "What's wrong with
gcc?"gcchas been widely used for over three decades. You have been programming for half a semester.gccis not broken!
I remember his words anytime I start questioning others. A far majority of the time, the bug is in my code.
Avoid tunnel vision
Debugging is the art of asking the right questions. If you start by questioning others, you will likely waste your time asking the wrong questions.
We've all done it. A recent upgrade revealed a bug in the code. Now you have a bug in your brain: it's the upgrade.
Of course you should question the upgrade. But question other changes too.
You still have to fix it
Let’s say you prove the language has a bug, Internet Explorer behaves differently, or the developer before you broke the build. What then?
Well, you still have to fix it. Even when it is not you, you still must develop the fix. No point in focusing on blame.
Following the Debugging Golden Rule keeps developers grounded, focused, and part of the solution. Remember it the next time you find a bug in the code.
Top comments (6)
I definitely agree with you here: "99% of the time it's you."
Thinking back through years, this rings true. There have been a couple of occasions where there's been a bug in a Ruby gem or even an issue with Rails itself. However, the vast majority of the time it's either misuse of the gem or misunderstanding of a Rails API.
Like you said, searching for blame is a waste of time. It doesn't get you any closer to solving the problem. This is even more important when trying to ship a hot fix. Every minute you spend searching for blame is another minute of production being unstable.
I think it's ok to come back later, after you've fixed an issue, and figure out what went wrong. Maybe there's a process you can improve or some testing you can build. If we keep our focus on learning and getting better, there should be no time for the blame game.
For sure. Such things should be mentioned in a retro or standup after the fix. Especially if the fix resulted in any kind of outage or is a chance for the whole team to learn a different practice.
I agree but in my case it is well under 99%.
As developers tend to blame the other developer, I am often in the latter position. I'ld agree that it is not me initiating the bug report, but the argument is often that my code upgrade or my implementation is not correct.
So I am prepared to debug the code that I did not write and I only file a report back once Ihave the proof where the bug is located. That is in my experience the fastes way to go forward.
Debugging code that you do not necessarily have access to is another ball game, but it is an interesting skill set.
Amongst the bugs I have discovered there are:
So bugs in renowned systems do exist. While you have to consider your own Work first as the source of bugs, you do need to pay attention to any deviation from the expected behaviour and if it is a third party, build a "simple" test case that it is the third party. That test case can then serve for your bug report if needed.
Nice post. Mindset can have a great impact on a developers productivity.
Side note :
"But question question other changes too."
^ The word question is repeated here, you might want to fix that.
Thanks. I have corrected the typo.
I think 99% is an exaggeration for a lot of industries.
Recently I've been working in NodeJS - where it's incredibly likely that someone on the team has pulled in some dependency that someone hacked together without testing. So that's the first place I look.
Previously I've worked in the Enterprise .Net/Java space where most of the time any obscure bug is in some vendor software - for example in one form engine I remember where in several releases the underlying call to .Net's SMTP 'SendMail()' method was accidentally removed. If the license agreement hadn't forbidden decompilation I'd have been able to prove it to them in hours instead of weeks.
For higher quality open source software, such as GCC and the Linux Kernel 99% might not be far off. I for one have never found a bug in a mature open source project.