Last week, the team and I ran into two obscure bugs. The first had to do with an IoC configuration gone wild, and the second involved Entity Framework and object tracking. My first reaction in both cases was to push code that just "fixes" the issue. A quick pull request was issued for both. While code reviews moved forward, the pressure to merge became high. Then a team member said something obvious and profound:
I think just merging the quick fix without understanding how the change fixes the problem just encourages this behavior in the future.
As a developer, when bugs become an issue for end users, my first instinct is to cover my mistakes. In that defensive state, I may lose my ability to slow down, understand, and ultimately see the real problem. Balancing the current experience of the user, with the responsibility of not making the situation worse is hard when things are on fire. I'm a professional, right? What could go wrong? While the stress of a broken application can seem overwhelming at the time, I am going to try harder to slow down, investigate, and understand a problem before just assuming I know what will fix the issue. Good assumptions may fix the problem. Bad assumptions lead to more code, more deployments, and more bugs.
I promise to do my best not to rebug my codebase.
You might also be interested in these articles...
Software Developer and All Around Nice Guy
Cover image credit: https://www.flickr.com/photos/clearlyambiguous/