DEV Community

The Secret Art of Debugging

Jeremy Likness ⚡️ on January 24, 2020

Mastery of the art of debugging is rare. I know this from years of experience working on enterprise systems. If it was simple, more people would be...
Collapse
 
doug_schiano profile image
Doug Schiano

Very good insights. I have a hard time understanding why others do not understand how to debug issues. You have put it in a very good context.

It reminds me of my first development job out of school. First day on the job we had to undergo a month of training. On the tables was a legal notepad and a pencil. My instructor wrote a simple task to add two numbers together and display the outcome. Everyone started turning on their computers and he said to stop and use only the paper and pencil in front of us.

Every program we wrote during that training class was first written out with a pencil and paper and reviewed by him before we could enter the code in an IDE and execute it.

This process had a profound impact on how I code and how I perform testing.

Collapse
 
jeremylikness profile image
Jeremy Likness ⚡️

I am thankful that I started out on simple 8-bit operating systems hand-coding instructions into memory. Not necessary today, but provided insights and an approach that has helped me master modern computing. With only 64k of memory and a slow CPU (2.6MHz) you had to really think about what the code was doing and reduce overhead and waste. Then you could reasonably step through every instruction to see what was going on. With today's frameworks a simple task like responding to a keypress and updating a view model can take you on a journey through code orders of magnitude beyond what you might expect. Thanks for the feedback and your thoughts!

Collapse
 
doug_schiano profile image
Doug Schiano • Edited

I should have added we were writing applications in assembler directly in prod on AS400 mainframes. No room for error. Being off one bit can cause havoc; corrupt core memory and cause the whole thing to crash.

I only witnessed that happen one time in my career there and it was not a fun time for anyone. (No I was not the cause.) It caused a system-wide outage for major players in the airline industry. Fortunately, it is easy to roll back the changes in real-time so once the issue was identified it only took seconds to fix but there were a lot of unhappy folks in management.

I fear in today's world of IDE's, frameworks, and helper functions, we are no longer teaching developers how to think in systematic steps but in abstract concepts. This is one of the reasons debugging is difficult for people. The XYZ framework takes care of that, or I was told by developer Joe to just use this object for this function and that object for the other function. They have no idea what those objects are used for or how to use them properly.

Collapse
 
__orderandchaos profile image
Order & Chaos Creative

"Unfortunately, too many people focus on tools and language features instead of a mental framework that will work regardless of language, platform, or tool."

This. This, so much.

Collapse
 
murrayvarey profile image
MurrayVarey

Nice article! Debugging is definitely a skill you can home.

For me, debugging happens in two separate phases: (1) gathering clues, and (2) finding the cause. Basically, phase 1 is an attempt to stop me from chasing my assumptions. Sure, it's fun to try and work things out purely in my head ... but that often sends me down the wrong path. So now I just don't waste the energy, until I have a clearer picture of what's going on.

Collapse
 
zakwillis profile image
zakwillis

Hello. Very good article. Will read it again. Have my own bit of advice, I have found with coding on my own project.

Always run a program start to end. When I started my project, I picked up a lot of my old applications. it was natural/stupid to assume everything written just worked. There were subtle but major bugs with a couple of apps. Only once I stepped through the app code, these bugs finally appeared.

The second to is make sure you have lots of logging. Read the log files to make sure they make sense, there are no errors, code processes in the right order etc. Indeed, I probably put logging higher than debugging because often testers, analysts and support staff will all read log files.

Three. If you can, write data tests/integration tests on what the expected state should be. These tests can be shared with testers and analysts, run as part of the build process. NBI is a great tool for this.

Collapse
 
piannaf profile image
Justin Mancinelli

If you liked this and are looking for more debugging strategies, I recommend Chelsea Troy's article A Framework for Debugging

Collapse
 
fwd079 profile image
Fawad

Pretty decent read. Your mentor said the exact same thing my professor said to me, run the code in your head, if it works then you are good to go.

Collapse
 
joeyorlando profile image
Joey Orlando

Very insightful article! But I’d argue the answer to your pop-quiz is in fact 3 😉

Collapse
 
aschwin profile image
Aschwin Wesselius

So, I'm not the only one...

Collapse
 
bernardoow profile image
Bernardo Gomes

Thanks for sharing !!

Collapse
 
patricktingen profile image
Patrick Tingen

Thanks for this nice post, but since I'm not yet into c# much, what is the bug in the get/set code?

Collapse
 
jeremylikness profile image
Jeremy Likness ⚡️

The get code for last name returns first name

Collapse
 
chrismoreton profile image
Chris Moreton

An open mind is a big benefit. Many a bug has gone unfound for too long following a developer's assertion that "No, it can't be that, because..."

Collapse
 
muhammadtayyabbhutto profile image
Muhammad-Tayyab-Bhutto