|
I don't think any amazing programmer is immune to every bug. Just imagine a programmer who, when confronted with a bug, is always like "oh, that must be X or Y, we can test that real quick!" (And is right.) What a crazy world that would be. What I do know is that my programming style is to really dig into every new project I have to work with. Maybe not every part of an application, but everything relevant to the feature I care about. I'm an incredibly judgemental reader (this is sad for personal reasons) and as such, I come up with long lists of "I don't think this would handle that scenario." I don't have time to dig into them, but that list stays there in the back of my mind -- a vague sense that a loop wasn't accounting for a particular kind of array value, etc, etc. Inevitably, months down the line, some of those bugs surface as actual things. I keep an eye out on tickets, or listen during stand-ups, and I only have to remember just enough of that problem to cut out the investigative time. Eventually I become the person everyone goes to to get them up to speed on any problems within any of the features I've worked in, over people with much more seniority on the team, or often even the people who are responsible for that project. This is also how people seem to always think I've been around twice as long as I have. I'm not a 10x engineer -- I find it incredibly difficult to stay "on task" and that massively kills my productivity. But the way I approach codebases, outlined above, is just one of many tactics that can, in the right environment, make a programmer far more productive/useful than they would otherwise be. |
I guess that's also an additional argument for not being the only person working on a codebase - it's far harder to read it judgmentally if you wrote it.