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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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!
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.
"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.
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.
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.
If you liked this and are looking for more debugging strategies, I recommend Chelsea Troy's article A Framework for Debugging
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.
Very insightful article! But I’d argue the answer to your pop-quiz is in fact 3 😉
So, I'm not the only one...
Thanks for sharing !!
Thanks for this nice post, but since I'm not yet into c# much, what is the bug in the get/set code?
The get code for last name returns first name
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..."
This may helps you.
Mastering the Art of Debugging: Tips and Tricks for Every Programmer