How Debugging Can Make You a Better Developer.
Inside every large program, there is a small program trying to get out.
Ravi Shankar RajanBlockedUnblockFollowFollowingFeb 2Image Credits: unsplash.
com JeshootsIf I were to sum my programming career into 2 hard truths, they will be the following.
· Anything that can possibly go wrong, will go wrong.
· Code smells.
And the only skill that is required to counteract these bitter realities is debugging.
Yes, Debugging.
No one (or almost no one!) starts off programming with a love for debugging.
Instead, it’s often a source of frustration and dread.
“How many hours am I going to waste fixing this bug?”, a lot of us wonder.
We’d rather go back to building cool stuff.
(Because who doesn’t like building cool stuff!?)Yet it’s hard to find a developer that we admire that doesn’t consider debugging important.
That’s because they know that it’s an invaluable source of growth for them.
There are a few situations that will test your abilities as a developer to the extent that debugging will.
And the real problem with debugging is that it is not amenable to a time box.
You can timebox almost any activity in programming from design to development.
But debugging is a different kind of fish altogether.
With a debugging session an hour, a day, or even a week may come and go and find you no closer to finding and fixing the problem.
That’s why you should start approaching debugging as a learning opportunity.
Sure the pain will still be there but you keep it under control by doing it the right way.
And here are some ways in which you can be better in debugging.
Understand the System FirstWe often make the mistake of “understanding the problem” first and then “understanding the system”.
It should be the other way round.
Some time back I was debugging an issue in an SAP smart form.
Some values were not coming properly on the form, I debugged the entire form for two full days and I could not find the issue.
Needless to say, I was frustrated.
There was nothing wrong in the goddamned form.
Then inspiration struck me.
I noticed that the form is been called simultaneously from two places within the main code.
On further analysis, I found that the problem was in the calling code and not in the form.
I solved the issue in a jiffy.
My effort for two days just required a very very minor tweak in a different place.
What did I do wrong here?I couldn’t debug the problem unless I understood how the system worked.
As soon as I did understand it, the problem was obvious.
Always remember, you need a working knowledge of what the system is supposed to do, how it’s designed, and, in some cases, why it was designed that way.
If you don’t understand some part of the system, that always seems to be where the problem is.
Attack Problems in IsolationI learned this important nugget of wisdom the hard way.
Some time back I was working in a large SAP data migration project.
The timelines were critical and too many code blocks were happening in parallel.
And at this crucial juncture, I ran into a data corruption problem.
Some of the migrated customer data was getting corrupted and it was a humongous task to find out what went wrong in the millions of records migrated.
I knew the problem but where the problem existed was the main issue.
Finally, I solved the problem with prototyping.
I created a small prototype which displayed similar symptoms with a subset of data.
Working with this prototype got me to the root cause and finally, the issue was closed.
The point here is narrowing the search.
Large systems are complicated and many factors are involved in their execution.
While working with the entire system it is hard to separate the details that have an effect on your particular problem from ones which don’t.
The solution is divide and conquer.
Don’t try to work with the whole system at once.
Separate the component or module you are having problems with the rest of the code for serious debugging.
Isolating a problem has many advantages.
You are able to focus directly on the issues that are relevant to the problem.
You get to the problem quickly because you are working with a minimal amount of code.
Always remember It’s hard for a bug to keep hiding when its hiding place keeps getting cut in half.
Change One Thing at a TimeIn a one-liner; Use a rifle, not a shotgun.
Let me explain.
Imagine you have to remove a tooth and you visit a dentist.
The dentist “tries” to find the issue and starts tinkering with all your teeth.
You groan in vain as one by one your teeth bear the onslaught of his hammer.
How will you feel?.“What the hell is happening.
Does the guy know his job?”Bad debugging exactly works the same way.
Change one thing at a time.
Get yourself a good rifle.
You’ll be a lot better at fixing bugs.
I’ve known developers trying to fix a bad code by just swapping or tinkering with other components.
They might change three or four things and discover, hey, it works now.
That’s kind of cool, except that they have absolutely no idea which part was the bad one.
Worse, all that hacking can break other things that were fine, to begin with.
In many cases, you’ll want to change different parts of the system to see if they affect the problem.
This usually should be a warning that you’re guessing rather than knowing the code well enough to see what’s going on.
You’re changing conditions instead of looking for the failure as it occurs naturally.
This can hide the first problem and cause more.
This is an illusion trap that developers need to avoid.
Always remember you can always tell exactly which parameter had the effect if you make one change at a time.
And if a change doesn’t seem to have an effect, back it out right away!Check if It is Really Your Fix That Fixed it.
A golden rule of debugging is that If you didn’t fix it, it isn’t fixed.
Everyone wants to believe that the bug just went away.
“We can’t seem to make it fail anymore.
” “It happened that couple of times, but gee, then something happened and it stopped failing.
” And of course, the logical conclusion is, “Maybe it won’t happen again.
” Guess what?.It will.
Sorry to disappoint, but there are no magical fairies in the real world.
When you think you’ve fixed a bug, take the fix out.
Make sure it’s broken again.
Put the fix back in.
Make sure it’s fixed again.
Until you’ve cycled from fixed to broken and back to fixed again, changing only the intended fix, you haven’t proved that you fixed it.
Fixes tend to behave in a funny manner more often.
Sometimes they just “hide” rather than actually fixing the issue.
And by the time we realize that the fix has nothing to do with the problem been addressed, the product would have been shipped to the customer who obviously will not be happy.
Don’t fall in the trap.
Always remember, If the system fails as it used to when you remove only the fix, only then you can be pretty sure the fix is indeed working.
And Lastly, Keep a Solution LogThis might sound trivial.
But it is a very important problem-solving tool which is often overlooked.
Problems occur and reoccur in life, work and even in relationships on a perennial basis.
And it does not make sense to reinvent the wheel again and again.
In terms of what type of information is actually maintained in solution logs, it is difficult to predict, given differing requirements from business to business.
However, generally, the following items can be considered.
· Issue #· Initiator (who logged the call)· Initiator Extension or Phone #· Date/Time Opened· Summary Description· Impact/Importance· Type (of fault)· Owner (of system)· Current Status (open, in process, closed)· Next Step· Next Step Date· Completion Date· Resolution, development request # or link to vendor support requestDon’t get burned twice.
To be more productive, maintain a log of problems faced and solutions found.
When a problem appears, instead of saying “Hey, I have seen this before.
But I have no clue how I fixed it.
”, you can quickly look up the solution you have used in the past.
Needless to say, it not only saves your time but boosts your self-esteem and confidence to unthinkable levels.
Remember, debugging is a learning opportunity.
Sure, sometimes you’ll realize that you made a silly mistake that you shouldn’t have made in the first place.
But that’s as much a part of becoming a better developer as learning some cool new language feature.
As Richard Pattis has rightly said.
“When debugging, novices insert corrective code; experts remove defective code.
”About the author-:Ravi Rajan is a global IT program manager based out of Mumbai, India.
He is also an avid blogger, Haiku poetry writer, archaeology enthusiast, and history maniac.
Connect with Ravi on LinkedIn, Medium and Twitter.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +418,678 people.
Subscribe to receive our top stories here.
.