Good advice! I would add just a bit of supplement:
Finding the exact source of the buggy behavior is often harder than fixing the bug once found. Once we find a piece of code taking some odd input and emitting a bad output, we can be trigger-happy to fix that code. Easy! Check if the input is odd, and if so, make the output behave.
But we should stop for a moment, and ask: Is this odd input supposed to arrive here? Why does it even look like that?
It is important to recurse and stop the problem at the roots.
For example, an aggregation behaves bad when receiving duplicate key inputs. Ok, so let's fix it to drop the dups? No, we should ask, why are there duplicate keys? And recurse checking how those were generated.
Then do two things:
Fix the source of the problem (maybe some racy database writes), and add logging to our aggregation if we encounter unexpected behavior.
My book Programming Without Anxiety has a chapter in progress on debugging with tricks like this and more. For example, it covers preemptive debugging strategies in case you can't interactively reproduce the bug, or time to reproduction is slow.
/Sidenote: I once had to reproduce a bug at Ericsson that only manifested after a call was running for more than 24 hours.. fun times../
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
By reducing the scope I by no means intended, just solve the symptom! **
A good developer always finds the right spot where to make changes, and often is **further up in the chain. Most of the changes should be made to prevent the bug from happening by ** investigating the root cause.**
By reducing the scope I meant to try to investigate on the smallest possible piece of your infrastructure.
I see too often full-stack dev s- with 2 or 3 screens - with everything open ( DB - Dev Console - multiple IDEs with Frontend code, backend code ) reading console.logs everywhere. when they could at least try to isolate the problem.
Thank you very much for pointing this out.
( I guess I will write a separate post for that. Because it pisses me off when in Code Reviews I find silly quick solutions to bugs that would have been better to be handled somewhere else.
Bug fixing shortsightedness (myopia) is also a big problem!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good advice! I would add just a bit of supplement:
Finding the exact source of the buggy behavior is often harder than fixing the bug once found. Once we find a piece of code taking some odd input and emitting a bad output, we can be trigger-happy to fix that code. Easy! Check if the input is odd, and if so, make the output behave.
But we should stop for a moment, and ask: Is this odd input supposed to arrive here? Why does it even look like that?
It is important to recurse and stop the problem at the roots.
For example, an aggregation behaves bad when receiving duplicate key inputs. Ok, so let's fix it to drop the dups? No, we should ask, why are there duplicate keys? And recurse checking how those were generated.
Then do two things:
My book Programming Without Anxiety has a chapter in progress on debugging with tricks like this and more. For example, it covers preemptive debugging strategies in case you can't interactively reproduce the bug, or time to reproduction is slow.
/Sidenote: I once had to reproduce a bug at Ericsson that only manifested after a call was running for more than 24 hours.. fun times../
That is absolutely a very good point!
By reducing the scope I by no means intended, just solve the symptom! **
A good developer always finds the right spot where to make changes, and often is **further up in the chain. Most of the changes should be made to prevent the bug from happening by ** investigating the root cause.**
By reducing the scope I meant to try to investigate on the smallest possible piece of your infrastructure.
I see too often full-stack dev s- with 2 or 3 screens - with everything open ( DB - Dev Console - multiple IDEs with Frontend code, backend code ) reading console.logs everywhere. when they could at least try to isolate the problem.
Thank you very much for pointing this out.
( I guess I will write a separate post for that. Because it pisses me off when in Code Reviews I find silly quick solutions to bugs that would have been better to be handled somewhere else.