🎓 Why Seniors embrace bug bashing and site reliability duties.
Bug fixing might not be glamorous, but it can often be challenging, fulfilling, and a great source of knowledge and experience.
I can see you making a face already.
Ugh, bug duty 🙄
The bane of many an engineer. Why would you want to fix pesky bugs, when you can be architecting and developing new features that will take your company to the next level?!
We want big wins for our resume, dammit!
I don’t blame you; those are definitely more exciting and potentially more valuable.
However…
Site reliability duties will make you better at those big feature wins.
Bug duty comes in many different flavors, from being the occasional point person for escalated support tickets (we called this “triage” at my last org) to full-time site reliability positions, and everything in between.
Many devs lament stepping into bug duty because they focus on the negative aspects. You have to fix others’ mistakes. It isn’t very glamorous work in comparison to feature development. It doesn’t seem to make a tangible impact. And so on.
You know the reasons. You’ve felt them.
Instead, let’s highlight and focus on the benefits of bug duty, and how it can help you grow into a Senior Engineer.
Every bug is a learning opportunity.
It is incredibly unlikely that you are such an experienced developer that you can easily resolve every bug that lands in your Jira board. (I bet there’s an AI for that somewhere…)
But that’s a privilege! An opportunity to learn, explore, tinker, and more.
You get to practice problem solving, which is the core skill an engineer should have and should be practiced as often as possible.
You get to see technology you haven’t used before, such as new parts of the code base, or software like a database or logging tool.
You get to practice optimizing your time by recognizing when you’re stuck or focusing on something less efficient.
You get to potentially work across teams, recruiting assistance from support, security, infrastructure, or whomever can help assist you in your bug squashing quest.
You get to practice reading, understanding, and modifying code written by others. With any luck, you can solve the problem and teach the solution to others so they can learn, too. Which is part of the “leave everything better than you found it” mentality.
Bugs reveal opportunities for extra improvements.
Speaking of “better than you found it”, bug fixing can identify and inspire a slate of improvement opportunities around your technology and processes unrelated to the bug itself.
Seeing a lot of bugs that follow the same theme? Teach your team how to avoid them. Or even better, automate protections against them where possible.
Automation in general goes a long way. Increase test coverage. Reduce build times. Automate deployments and rollbacks. Reduce code review time by automating certain checks and fixes that code reviewers shouldn’t have to focus on.
Are you having trouble identifying a bug due to lacking logs, metrics, or other exposure? Add them!
Suggesting, and more importantly implementing these improvements to your products and organization are a key way to increase your influence and seniority as an engineer.
Every bug increases your domain knowledge.
Seniors are domain experts. They have a depth of understanding in one or more areas of an application. They’re considered subject matter experts of the technology and the business problems the features solve.
When you fix a bug, you learn about that area of the business, thus increasing your domain knowledge.
The more you understand what problems the business is solving for your customers, the more your engineering efforts will match the business’ value, increasing your value.
Bug fixes are a great time to practice TDD.
Test-driven development can be tough to use for the majority of your everyday work. Fixing a bug is a perfect time to practice, because most of the infrastructure is in place. You already have working endpoints or services or whatever your entry point is. You have a well-defined outcome that currently isn’t happening. And you definitely don’t have an existing test in place, or it would be failing already.
Applying TDD when fixing bugs helps you practice TDD, it adds more test coverage, and it helps guarantee the problem is resolved as expected.
Every bug fix is a customer problem solved.
Engineers are often isolated from customers, and as such rarely see the direct impacts of their work. This has pros and cons. On the good side, you never have to deal with rude and irrational customers. On the bad side, you never hear about how your work is impacting in a positive way.
At the end of the day, there’s a real person on the other end of your bug fix, who is ecstatic that one of their pain points has been removed. And that’s a real win.
Even if the ticket was created internally, it’s likely a customer has experienced it without reporting. Like reviews on purchases, bug reports cover only a fraction of total occurrences.
Ask your customer-facing team to share the response when the customer is told their bug has been fixed. It should brighten your day!
And speaking of your customer-facing team, they love delivering good news. Bug fixes have an impact internally, too.
Bug fixes may seem like a mundane task lacking excitement and value. By focusing on the learning opportunities around your app, technologies, and business, you can see how much value they really hold.
That said, hopefully you don’t get stuck only fixing bugs for a long time. 😉
Happenings & Findings
Articles
Hatchet, a distributed, fault-tolerant task queue, wrote about implementing fair queueing strategies for Postgres-backed task queues.
Technologies
Canvas Confetti, a confetti effect JS library.
Pragmatic Drag & Drop, a low-level drag and drop JS library by Atlassian.
Fun
Up Next
🎓 An Introduction to Architecture Testing
You’re the best!
Aken 💙
Great summary! Making software more robust is a good feeling. Bug Bashing can enable that and lead to a cleaner codebase!