Repeatedly trying solutions to see if they work isn't the optimal method for fixing bugs. Whenever I find myself doing that, I know that I need to stop what I'm doing and come up with a better plan.
If you take the time to understand the problem first -- run test cases to narrow down the precise conditions under which the bug occurs, read the code, step through the code with the debugger, etc. -- you'll spend less time trying and rejecting random solutions because you'll already have a good idea of what you need to do to fix the bug.
Another advantage of getting a good understanding of the code and the bug before fixing it is that it makes it much more likely that you'll actually fix the bug, and not some limited subset of it.
When I'm tired and/or lazy I seem to lack a ability to accept the truth. I seek for easy solution instead of actually doing what I already know I supposed to do. Luckily nowadays I am able to recognize this and call it a day.
When you are trying different solutions you are trying them in a specific order based on your intuition of which solution has more probability to solve the issue. If your last solution worked that means the analysis by which you decided the probabilities of the possible solution was completely incorrect. When that happens you should not just move on rather you should think about why this was the case, what were those heuristics that you used to figure out most probable solution and how they were wrong. This introspection will allow you to evolve your heuristics over time and will give you better idea about which solutions are more probable to solve the issue.
As in you actually make a [mental] list of things to try and it's always the last one? If not maybe it's just bias. If you do maybe you're really decent at sorting things to try by effort [and like to try easy ones first].
maybe when you fix a bug, think about the solution you used and if it one of the earlier solutions you tried might be improved to actually fix the bug. Often there can be a range of solutions, just because something you tried didn't work doesn't mean the process you were using was faulty - just the implementation.
11 comments
[ 2.5 ms ] story [ 33.1 ms ] threadIf you take the time to understand the problem first -- run test cases to narrow down the precise conditions under which the bug occurs, read the code, step through the code with the debugger, etc. -- you'll spend less time trying and rejecting random solutions because you'll already have a good idea of what you need to do to fix the bug.
Another advantage of getting a good understanding of the code and the bug before fixing it is that it makes it much more likely that you'll actually fix the bug, and not some limited subset of it.
Similar to how what people truly want to do is often written LAST in their list. After subconscious pressure is gone.