3 ms·
I follow, yet I disagree that "first priority" must always be a reproducer. There are a lot of conditions that can be rootcaused clearly from diagnostics; say,
by fch42 2y ago
I follow, yet I disagree that "first priority" must always be a reproducer. There are a lot of conditions that can be rootcaused clearly from diagnostics; say, Linux kernel code deadlocks can exhibit as two different (in their stacks) repeatedly shown "task stuck for more than ... seconds" messages; the remainder follows from the code (to see the abba-lock-ordering violation).
There's a certain fetishisation of reproducers not unlike the fetishisation of build-time testing - to denigrate a bug because "you can't reproduce it" or "if it doesn't show in the tests it needn't be changed". Personally, that mindset irks me.
Fortunately, most developers are happy to learn more about their code any which way. And debugging, tracing, monitoring is cool in itself.
- viraptor 2y agoIt's a nice ideal to aim for. But I agree, it's not "must" and not "exactly". If I run into a "very-interesting-problem" which depends on synchronisation between multiple machines and includes some geographic dependencies and caching, I may do the mental calculation: - reproducing the issue in a repeatable way would take a week or more - I can make 2 educated-guess fixes a day which don't affect production negatively I would be a fool to choose the first (or at least start with the first) in most companies. I mean, I want to display pictures on the internet, not send people into space.
- catskull 2y agoExcellent points! I considered how to work in those cheap "Hail Mary" kind of commits. In then right situation those can be effective but it can also be incredibly risky. This is coming from someone with "Revert Revert Revert..." commits with my name tagged on them hahaha!