Thoughts on Debugging
I was recently asked to help resolve an escalation at work. It had already bounced around between a few people, and was very muddied with conflicting reports not to mention frustration that the issue existed in the first place. Apparently I am insane, because I like situations like this.
I don’t mean that I like they they exist, but I like getting involved, because I’m good at debugging. I’ve been being paid to write code professionally for at least the last 10 years, of which at least 5 of them I’ve had any idea what I was doing. I’ve never taken a college level computer science course. But I’ve learned a thing or two about engineering in the last few years.
Debugging is a very strange skill to develop. It requires a certain intuitive distrust in all technological systems, developed over the course of continually observing engineering decisions that make you question the fabric of reality. It requires excellent written and verbal communication, and the ability to focus on the facts at hand instead of emotions, which typically also run high especially in high profile or otherwise intense debugging sessions.
I prefer to debug and coordinate asynchronously, others prefer to huddle. I’ve seen both be effective and I think both are worth trying out if the other approach doesn’t seem to be working. On especially complex issues, it’s important to get the right people “in a room” together. The Right People are the people who need to be in communication with one another to resolve the issue. This could be software or support engineers, integrations specialists, managers, or possibly even architect-level software generalists depending on the rest of the team’s ability to communicate and debug.
