131–140 of 141 posts
Hugged to death for me right now, here's an archive link: https://web.archive.org/web/20250228192142/https://www.autod...
Thanks for posting an archive link. My site has survived previous HN traffic spikes on Fly.io's free tier, but 256mb of RAM wasn't quite adequate this time :)
Brendan Gregg's USE method is for performance troubleshooting but could work in any situation (broken is just the worst performance, right?) https://www.brendangregg.com/usemethod.html
He promotes many more methods , based on the exact needs: https://www.brendangregg.com/methodology.html
> Realizing that I spend more time troubleshooting than I do building or doing ... That's not good. The problem with troubleshooting is that it messes up with your reward system. After you fix a hard-to-debug problem, you feel a sense of accomplishment. Which would be ok, but the problem is that this sense of accomplishment is often time higher than it should be. You go home at the end of the day thinking "well, toda…
And it isn’t just your _appearance_ or _pay_ you should be worrying about. If you fix a nitpicky bug that affected 5% of the users — congrats that’s a pretty big bug! But could you have built a new feature that would roll out to 50% of users in that same time? In many situations, building the new feature will have a bigger impact on the world than the bug fix. Obviously will depend on the exact circumstance. But you…
Earlier quoted context omitted.
And it isn’t just your _appearance_ or _pay_ you should be worrying about. If you fix a nitpicky bug that affected 5% of the users — congrats that’s a pretty big bug! But could you have built a new feature that would roll out to 50% of users in that same time? In many situations, building the new feature will have a bigger impact on the world than the bug fix. Obviously will depend on the exact circumstance. But you…
Building features and fixing problems should both be about solving problems. Work on whichever one gives the right balance of effort and benefit.
Earlier quoted context omitted.
The code rarely resembles the runtime state of the system. Debuggers are an incredible shortcut almost all the time.
I strongly and emphatically disagree on every point (I don't even know what your statement about runtime state and code even means actually, it just seems like a category error, but how do you even write code without being able to reason about runtime state? It just makes no sense.), but I understand there are people who love their debugger and I respect them. Basically the only time I pop open the debugger is when i…
Troubleshooting is one of my main comparative advantages - I'm better at it than I am at programming and I enjoy it more. It's also a relatively independent skill, not everyone is good at it or likes it. It reminds me of the lateral thinking puzzles I did as a kid where you had to ask questions to uncover whatever the weird situation was. You have to question your assumptions - think about how you might be wrong, som…
1. You have to start having hypotheses that you test, but should be ready to throw them away as quickly as you thought of them, when the results from testing it says so. Let data
2. You should preferably think hard about effective way to quickly rule out influencing variables and so quickly square in on the area where the erroneous effect is coming from.
3. You have to really rule out confounders. Make sure to turn off any caches or similar that might play games with you.
The area where I see most colleagues fail in this process is not being stringent enough with things like ruling out confounders and being systematic about organizing the outputs from hypothesis testing, to make sure you are 100% which outputs belong to which inputs etc.
It is the discipline and strictness in the process that will do the trick. Anything less and you will just trick yourself.
Troubleshooting is one of my main comparative advantages - I'm better at it than I am at programming and I enjoy it more. It's also a relatively independent skill, not everyone is good at it or likes it. It reminds me of the lateral thinking puzzles I did as a kid where you had to ask questions to uncover whatever the weird situation was. You have to question your assumptions - think about how you might be wrong, som…
I think troubleshooting has a lot of overlap with thinking along the lines of the scientific method. 1. You have to start having hypotheses that you test, but should be ready to throw them away as quickly as you thought of them, when the results from testing it says so. Let data 2. You should preferably think hard about effective way to quickly rule out influencing variables and so quickly square in on the area where…
The other thing I see trip people up is being unwilling to make a fast hypothesis that can be easily tested to narrow scope.
Instead they’ll often try to look at the code to understand but that’s usually slower for anything remotely complex.
Shouldn't this say "... than when in a hurry."?
Troubleshooting is one of my main comparative advantages - I'm better at it than I am at programming and I enjoy it more. It's also a relatively independent skill, not everyone is good at it or likes it. It reminds me of the lateral thinking puzzles I did as a kid where you had to ask questions to uncover whatever the weird situation was. You have to question your assumptions - think about how you might be wrong, som…
Have you found effective ways to market this skill?
In my company, I'm often the person who joins a production bug troubleshooting call, after sometimes hours of investigation, and rapidly identifies the root cause.
My typical workflow is:
* Clarify the issue and our assumptions. Often, simply restating the observed behavior aligns everyone.
* Pose questions to validate or challenge those assumptions.
* Suggest alternative methods to test the primary hypothesis.
Often, testing the initial hypothesis reveals its inaccuracy, leading to a swift discovery of the actual root cause.
Ultimately, it comes down to critical thinking and questioning assumptions I think.