"How do I fix more bugs?"
I was asked “How do I fix more bugs?”
The answer is to own buggier areas! Devs who own buggy areas (best when not through some fault of their own) will resolve more bugs because more bugs will be incoming.
Another is to file bugs and fix them. Not dumb bugs, but real bugs. Sometimes only devs can see the problems while looking at the code. If you feel bad filing and fixing your own bugs, assign them to PM first to prioritize.
More importantly, seek out buggy areas. This shows initiative and desire to help ship the product. If instead you wait until you run out of bugs and someone assigns you something else to do, it’s less impressive. “He fixed it, but only after I gave it to him”.
Of course, if the area remains buggy, you haven’t helped yourself. If bugs keep incoming, it could be the feature needs to be scoped again. This usually means talking with PM and test about cutting or stripping down features. Sometimes, a small change in spec cuts off an entire area of bugs. This is just as good as fixing a lot of bugs, since you identified a key area that if cut would dramatically reduce bug counts.
One such example would be supporting rotation of entire SmartArt diagrams. It’s a simple user scenario, but it affects every aspect of editing the diagram plus you need to deal with the content pane when the diagram is rotated and the list will go on and on. In the end, not supporting rotation simplifies the entire implementation and cuts off a whole chain of bugs. (Today of course you can just ungroup it and rotate the group if you really want).
Better bug ordering means better fix rate
While there are many bug priorities, they are rarely stacked in such a way that will lead to the most amount of bug fixing possible. I’ve found fixing everything strictly in priority order will get you stuck on the hard bugs the entire cycle.
Instead, I always have one machine used to fix hard, important bugs and another free to fix easy, “fun” bugs. This gets rid of lower priority fit and finish issues that we wouldn’t normally get to if we didn’t just fix them. It also gives me a break from working on any particular monotonous and difficult bug which usually leads to better a fix anyway as I’ve had more time to think about it.
Fixing lower priority bugs in between higher ones prevents a backlog of stuff to work on which PMs will have to go through and make cuts of. You can’t save every bug and many bugs should be punted, but getting rid of the easy ones means less things PMs have to cut. Plus it makes you look good with a higher resolve rate and less bugs assigned to you.
Negative space
Additionally, the most severe bugs from the user’s perspective are not always the most important to fix first. Many bugs which come to be known as “Work Items” in Office need a lot of ground level support to really fix. It’s not enough to just fix the symptom of a particular bug, there tends to be a larger cause that needs addressing to prevent future bugs.
These are probably the most important things for devs to identify since no one else really knows that the future holds many more problems if the area doesn’t get looked at.
And that’s probably the most valuable thing to put in a review, but the hardest to prove: that you prevented downfall of the entire feature because you reworked the area. If you hadn’t done it, you’d be drowning in bugs, but because you did it there’s no proof there was ever a problem. It’s productivity in “negative space”.
One way to show this is to show how bugs in the area tended to go down after your fix. Another is to show a certain class of bugs that kept coming up over and over but stopped after your fix.
Either way, hammer it home during reviews. Every manager should know exactly how much awesomer the product is now that you’ve graced it with your presence.
