4 ms·
I've spent a number of long days and late nights hunting bugs that made it into production - or the master branch - and are blocking our release, blocking my co
by MaulingMonkey 10y ago
I've spent a number of long days and late nights hunting bugs that made it into production - or the master branch - and are blocking our release, blocking my coworkers, or crashing for our customers. It sucks, it's stressful, it's frustrating - it's even depressing.
So I'm actually kind of stoked when a code review catches a bug in my code. They're often the exact kinds of edge casey corner cases that would've manifested as the kind of heisenbugs that lead to exactly those kinds of long days and late nights - but the code review caught it, so none of us will have to go through any of that over it. Yay!
Do I wish I hadn't made the bug in the first place? Sure. But to err is human - and statistics means this err will be you averaging X bugs a month, Y of which won't get caught before the code review, Z of which will get checked in when the code review doesn't catch them either. The goal isn't to have no bugs, it's to reduce X Y and Z until it's no longer cost effective to do so (which is at a very different point for NASA than it is for your website or app.)
I'm also acutely aware that when you've been staring at the same code too long, your brain starts replacing the code that's there with what the code "should" be, and you start missing the obvious right in front of you. Again - human nature. The solution is a second set of eyes from time to time. This isn't an excuse to be lazy or to avoid trying to improve, but it is a perfectly acceptable excuse not to beat yourself up when you've been putting in the effort, and still somehow missed the fact that you were assigning a reference to itself.
What's that? You want to be human too? I'll allow it!