The thing that still surprises me to this day about software development is it really isn’t about the coding. It’s really all about the DEBUGGING!
Unless you’re somehow perfect and never make mistakes, your software application will have DEFECTS, LOGIC ERRORS, or just plain WON’T WORK. And since our computers aren’t self sufficient, A.I. aware thinking machines (yet), your software code won’t fix itself…you, as a software programmer, will need to roll up your sleeves and try to figure out what went wrong.
I can’t stress enough just how important the ability to debug a program really is. It’s probably the most important tool in a programmer’s belt.
It can also be one of the most frustrating aspects of software development. When I first started out in my professional programming career, I was IMPATIENT. Maybe it’s the general nature of YOUTH. You want instant gratification. For things to work right the first time … yeah, wouldn’t that be a nice world to live in?
Sometimes I would get so frustrated by debugging my early programs, I would sometimes wonder if software engineering was really the right career path for me.
Eventually I learned the single most powerful tool in debugging.
PATIENCE.
It’s vitally important to keep a cool and calm head when debugging. A computer does not have emotions. It doesn’t CARE if your code works or not. It will cheerfully fail to run your code a million times.
We humans, unfortunately, don’t have the infinite patience levels of computers. We have to constantly keep our emotions in check lest we end up emotional wrecks.
Easier said that done, for sure. When you’ve got a production bug that’s causing your company lost revenue and your customers are breathing down your neck and your manager is asking you for a status update every 2 minutes, the need for PATIENCE is key.
It happened to me during my third professional programming job. I was under the gun to integrate and activate one of our bank customers to one of our core company products, and it wasn’t going well. It was probably a combination of my inexperience with both the customer’s system AND the core product of my company.
From morning till late in the evening, I was pretty much doing nothing but trying to figure out HOW to integrate our customer’s banking mainframe system to one of our sub-systems of our core company product (one of the first commercial online banking systems).
It seemed like a straightforward project. Or so I thought. I naively thought it was going to be a piece of cake. I kept reassuring my project manager that I was close to finishing the integration point. Day after day. Week after week.
Yet I just couldn’t integrate the two systems together. My code would simply fail to establish a connection to the external banking mainframe system.
Each additional day of delay added that much more stress. I wasn’t employed at that company for very long when this project landed on my lap. That project could literally make or break my chance for success at that company.
I eventually did manage to figure out how to integrate the two systems together. And I came out of the experience with two important nuggets of truth.
- Patience is key … do NOT panic
- Don’t be afraid to ask for help.
I think if I had to boil down the two key ingredients to successfully debug ANYTHING, can probably be boiled down to these two points.
It doesn’t matter how powerful your computer is, how sophisticated your debugging tools are, or even how smart you are, if you let your emotions get the best of you, you will end up frustrated, stressed out and nowhere close to figuring out why your application isn’t working.
That old adage about “slow and steady wins the race” really does have some truth in it, regarding debugging an application. The last thing you want to end up doing is panic … you’ll end up making unwanted mistakes, and let your emotions get the best of you.
Asking for help is the other key component of debugging. I am a huge supporter of collaboration.
Which of course, was (and still is) one of my personal development weak spots I continually force myself to improve on.
Having another fresh set of eyes looking at a problem or task often spawns new avenues of thought and experimentation to tackling the problem at hand.
Asking for help isn’t just limited to working with someone directly in your presence.
You have the limitless length and breadth of the internet to help you out. When I get stuck on a particular technical issue or bug in my application, one of the first destinations I go to on the Internet is StackOverflow.
Stackoverflow is a huge question and answer style website for programmers. You post a technical question on the site, and more often than not, you will get a response(s) which will hopefully answer your question.
The site is a very popular one and has a very active community of very smart and talented programmers with a desire to help fellow software developers out. In fact, the site has a ranking system where everytime you successfully answer someone’s question, you get points and a point based “rank”. The more you successfully answer a question, the higher your rank. I’ve read that having an active presence on Stackoverflow actually serves as a “living resume”, and has helped software developers find new jobs.
I’ve discovered that it has personally helped me in the art of debugging. In order to increase your chances of getting a good answer to a technical question, Stackoverflow, by its very nature, forces you to UNDERSTAND THE PROBLEM.
This is truly the secret to successfully debugging a problem. You need to understand EXACTLY what the nature of the software defect/bug is. Much in the same way a medical doctor needs to understand the nature of their patient’s physical pain, before they go into the TREATMENT phase, a software developer needs to understand the exact nature of the software defect before going into the actual process of fixing the defect.
At Stackoverflow, you need to CLEARLY explain the nature of your technical problem.
Believe it or not, just the very act of explaining the problem often helps the person solve their very own problem!
If you don’t truly understand the nature of your technical problem, then there’s no chance someone else will.
Once I’ve explained the problem, it helps others to explain what I have already done to try to resolve the problem. This helps others get a good background and context. Oftentimes, other developers will recognize what you have gone through to try to address your problem.
Finally, with any luck, you’ll get some responses by other developers, which you will try, and hopefully fix your issue.
Of course, it’s important to get as familiarized as possible with the particular programming language and technology stack you work in.
Sometimes, debugging is nothing more than recognizing a piece of code JUST DOESN”T LOOK RIGHT. Maybe you’re using the wrong method of an object. Or the wrong piece of whatever framework/API you’re using. I’m a voracious reader, so much in the same way that reading a lot, will help you recognize when words are spelled wrong, or when a sentence is grammatically incorrect.
It comes naturally with time and experience with your programming language and stack.
Finally, know your development tools. I primarily work professionally on the Microsoft stack. Their primary development tool is called Visual Studio, often referred to as an Integrated Development Environment (IDE). It combines a text editor where you write your computer code, with a full debugger to debug your code, a feature called “intellisense” that pops up a list of the possible methods that belong to a particular object. It can even analyze your code in realtime, as you type, and offer code optimization suggestions to make your application more efficient.
Other tech stacks like Java and Mac OS X and iOS have their own IDEs and toolchains to help developers debug code.
Developers need to understand the basics of using debugging tools, which are mostly the same across most tech stacks and languages.
You will often hear the phrases “stepping over code” or “stepping into code” amongst software developers.
It’s basically running your application in “slow motion mode”, one line at a time. As you step forward (or backwards) through code, you can examine the current state of all your variables and objects up to the point where your program is currently stopped.
With the help of your IDE tool, you’ll get lots of other useful information like where you’re at in the current call stack (the overall point in your application where you are currently stopped).
The better you get with your debugging tools, the quicker you’ll get to the heart of your software defect.
I think there’s a true art to debugging … it’s a combination of both technical skills AND the human virtue of patience and focus.
And maybe just a wee bit of luck and human kindness from fellow developers willing to give you a hand.
