Hello friends,
What do you think of best ways to improve debugging skills.
Does taking regular interval breaks while coding help you to do better debugging? What do you think?
P.S. Many times I have skipped my lunch because of debugging 😭 , yes at the end you get the code right but it's not good for self.
I don't think it's usually good to skip lunch or breaks or going home, at best delay them a bit if you're in the middle of something and almost done.
You're still going to have bugs to fix tomorrow and next week, you'll need to be energetic again.
When our code is in multiple layers and you have separate each of your important tasks in modules then you may need a debugging tool, otherwise echo, print_r(), and var_dump() are enough.
Depends on what language,platform(s) you are using. For a web development it's enough of print_r() or var_dump() statements. In my experience of 2.5 years of PHP web development - I have NEVER used debugging facilities- just these statements above. IMHO, if you feel the need of debugging (in a web development) this means that something with your code structure is not right and you need a complete code re-write. Then sit down, and re-think deeply how you can help yourself in the future by changing code architecture now.
About the question part - How and where to put breakpoints or print_r() statements in the code. Well, actually nobody can answer this question - just YOU. Because you are the master of your code and just you know it well (except maybe your colleagues or a project manager). Analyzing code paths is a developer duty and we must perform it well. So get used to it, otherwise it may mean that developer job is not a dream work for you.
I believe debugging is a little bit like a craft. What I mean is that like any crafts, it requires both some basic knowledge and practice to get good at it. Practice is key. And because it’s a complex process, it’s difficult to give a basic set of rules to help you have a better start. But let’s try with generic helpful ones!
A few tips (not rules, rather like guides) could indeed help in practicing your next debugging sessions in the right direction. I’ll list only 2, which are the main 2 ones I believe are the most important in my experience.
Let’s explain this a little bit. Debugging a system is not so much in finding what’s going wrong, but why and how it went wrong. In order to do that you ask your system questions, get answers, check if they match your expectations, and proceed. Step by step, you hopefully narrow down the set of hypothesis until there’s only one explanation left explaining the unexpected behaviour.
Getting answers back from the systems is easy: breakpoints (or logs) when it’s a small piece of code, but also metrics, stack traces, ... depending on if it’s a single piece of software or something distributed. But usually, it’s the easiest part.
The tricky part - the one where I keep seeing lots of good engineers waste a lot of time - is being able to ask the right questions to the system. Asking the right questions makes it much faster to narrow down the problem. And that’s where those 2 tips come in. You need to refrain yourself to add logs, put tons of breakpoints. But first, think of where you should put them to get a meaningful piece of information which will confirm or not one hypothesis. (That’s the stop and think part, leaving your hands off the keyboard) And in order to formulate a relevant hypothesis, you need to have a good mental model of the system. This might seems obvious, but we see so many times people wasting their time troubleshooting the wrong part of the code, because they didn’t correctly understood what they saw in the logs (or elsewhere), because their mental model was incomplete.
To recap:
Hope this helps