#best-practice #development #reading-list

🔗 A systematic approach to debugging
ntietz.com

I've got a reputation at work as being a skilled debugger. It's a frequent occurrence that the weird stuff lands on my desk after it goes through another skilled engineer or two. To say my job is substantially "debug the weird shit" would not be an understatement and I'm here for it.

This extends throughout our codebase, and into code I haven't seen before at all. I'm the longest tenured engineer at my company, so I'm familiar with most of our systems. But I've lost track of most of the features that get deployed, and we have way more code changes than I can personally review. And my debugging spans the stack: backend to frontend to database to weird Ubuntu behavior on our dev laptops. (Yes, our principal engineer also does tech support, and again, I'm so here for it.)

So... How do I do it? If I'm presented routinely with bugs I'm expected to solve in systems I'm unfamiliar with, what's the process? And does it extend to things outside of code?

continue reading on ntietz.com

⚠️ This post links to an external website. ⚠️

You might also like:

If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe use the RSS feed.