Debugging

I remember the first bug that I shipped to production. I was upset that I’d broken something and was anxious to fix it. But I noticed something curious: the calm demeanor of a senior mentor helping me. They refused to meet my intensity. While the world burned, they wanted to instead discuss the bug and its relative importance. Engineers don’t want to break things. We don’t want to make mistakes or look dumb. We don’t want to ship a sup-par experience or disappoint customers. When I was a junior engineer I reacted strongly to bugs that I caused or contributed to, no matter how small. ...

You were stuck, and now you aren’t. Congratulations! Before you move on, it’s vital to stop and learn from it. It’s the best way I know to get better and spare your mind for increasingly harder problems. “What Did I Miss?” Every time you get unstuck, ask yourself: when I was stuck, what did I miss? Was I misreading a message? Was I hypnotized by an irrelevant detail? 😵‍💫 Did I make a bad assumption and reject information that didn’t fit into my assumption? “What did I miss?” ...

We’ve all seen this: a frustrated coworker hunched over a computer after hours, flailing alone against some impossible bug. Go home, coworker. Don’t stay stuck. I once took a CS course that featured an online puzzle where you had to perform a series of tasks in a seemingly random order to solve it. The solution was not discoverable without brute force. You just tried each step until something happened, and then you tried another. It was maddening, and I gave up. ...

Here’s a trick that that has helped me as a programmer: before doing anything major, like killing a process, stop and count to ten. I learned this in IT. When a screen froze, the IT professionals I worked with would stop and count to ten before taking action. You’re watching a process run, it seems to have frozen, and you’re getting no instructions. Before killing it, stop and count to ten. If the process is still hanging after that, kill it, if you must. ...

When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate. Bug Terminology First, some context. Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. Bugs are defects in a computer program that produce undesirable behavior. And so, pointing bugs means trying to estimate how long it will take to fix a bug, or how complex it is. ...

Me: Hey, I’m experiencing an issue with your software. Here’s a detailed bug report. SAAS Engineer: What you’re describing isn’t possible. Narrator: But it was possible. This is a frustrating, unproductive snippet of a conversation I’ve had a few times in my career. What can we learn? Treat bug reports like gold. For every person who takes the time to fill out your support form, there are many more who just gave up, found a janky workaround, or possibly abandoned your product altogether. It costs them nothing to move on. You might not like the message, or how it was delivered, but you are still lucky that they spoke up. ...