BUGS & more bugs in your code!
Bugs will happen whether you like it or not.
But it pays off to know the type of bugs they are.
External bug in an API/service your system relies on?
A syntax bug?
A logical bug?
A bug caused by server itself?
The list goes on. But that’s really the first step. You must know the type of bug you’re dealing with!
That out the picture here’s 5 methods I use personally:
1. Dig deeper into system’s architecture.
Pretty simple but without having broad understanding of the system you’ll struggle to find or fix the bug in a reasonable way. There’s a time when you should narrow down vs think broadly.
Do both, you can think in details but you can’t think broadly without understanding the system. Thinking broadly means you’re less likely to break other parts of the system.
2. Clear mental model of the bug/issue
When issues are reported they don’t have all the information from the beginning. Often, they’re written badly. It’s your job to understand the problem fully, line by line and create a solid mental model of the problem. This is better than having to visit the issue 20 times in 30 mins because you keep forgetting the details.
Simply put, you need your own version of the issue/bug. How you understand it, not how someone else is framing it. Onto next step…
3. Take a walk but know where your goal really is.
The step #2 is very important. Simply going for a walk doesn’t magically solve problems. You have to know the goal and every single detail about the bug.
Once it’s in your head you’re free to go for a walk or make yourself a coffee. With everything absorbed in your brain, let it solve the bug in more relaxed way. Chill down now.
4. Time does the trick
Very easy to get frustrated but ultimately being patient pays off, if you put in enough time to resolve a bug, you’ll likely succeed. Every developer knows this! If not today, tomorrow!
5. Code isolation
If your code is tightly coupled, you won’t be able to focus on portions of it. If you can isolate class/function from rest of the code, you’ll resolve the issue more easily. This works because instead of thinking about 50 different files you’re focused on 2-3 files.
It’s easier said than done. Writing classes in a way where it accepts other objects as dependency help a lot.
Top comments (2)
Here's a trick I like to do when I discover a bug.
Break It More
I break it more! Since bugs are so subtle at times and are difficult to find, I usually double-down on it and try to make the thing break even worse. I give it even worse data or put it into a state that I know will make it break. This often leads to finding the bug faster.
I checked out your books on gumroad. Looks interesting.
If you get a chance, check out my latest article here on dev.to, Software Developer, Are You Just A Hammer? and let me know what you think.
Sure thing!
Good one because I have never thought about this, would love to know about how breaking it more helps finding bug!