Why Fixing Your Peer’s Bug Is Better For You
Imagine yourself writing a program without any bugs at all, your employer is happy, you’re happy, everything is super pink! Now back to reality, I know you want to stay there, but let’s face it, there’s no program with no bugs at all.
In fact, when it comes to a developer’s life, significant time goes towards fixing bugs.
Did you ever think about the different approaches you take when it comes to solving a bug in an area you developed, opposed to an area you’re not familiar with?
In my post I want to talk about the differences between solving a bug you caused, versus solving a bug someone else did — and how it can affect your productivity.
As a software developer at AppsFlyer, in my day to day I develop and occasionally cause and fix bugs (normal right?).
Recently I had an observation while talking to a friend about 2 bugs I’d come across and how they made me feel.
I realised that when investigating a bug that was not mine I felt less stressed and when solving it I felt on top of the world. On the contrary, when investigating an issue I’d caused, a lot of stress arose in the process — inner voices of “What the **** were you thinking?”, “How did I not see it before?”, “Am I doing it right now?”, etc.
When asking my peers about what they prefer solving, most of them gave me the advantages of solving your own bug.
In this post, I want to share my point of view (Spoiler alert) on why I think fixing someone else’s bug is better.
Level of stress
Solving your own bug usually comes with some self doubt, as I mentioned before. On top of that, there’s the feeling that you are responsible for the things you wrote, and so the level of stress rises.
When you come across a bug caused by someone else, you’re free of these thoughts and feelings, your head is clean and goes straight for the solution — to me it feels like solving a puzzle.
Working on solving a puzzle when you’re stressed and in self-doubt can be quite difficult. But with that said, I think those doubts and stress become easier as you gain experience, which brings me to my next point…
Seniority
As a junior developer you want to prove you’re good and you’re worth the chance your employer has given you. So you receive your first feature, and after you make it work it’s deployed to production, amazing! But despite that, there’s this client that sees a problem, and you discover there’s a scenario that got away.
Congrats, it’s your first production bug and it sucks, but it happens to everyone.
When coming across a bug caused by someone else, it can be someone at the same level as you, or even someone at a higher level. This can definitely boost your confidence, knowing that people with more experience make mistakes too. Reassuring you that it does happen to everyone, and also making it eventually work.
My point here is that seniority counts when it comes to how you refer to a bug. The more features you release the better you’ll get, the better you’ll feel.
Code familiarity
In this section there’s a big advantage to solving your own bug that we can’t ignore, which is code familiarity.
When we talk about solving your own bug, a big part of the way to the solution is knowing where to look. While working on it, you save time on learning the involved components and understanding the flow of the code. Maybe you’ll need a few minutes to remember, but you’ll have the starting point at the back of your head.
On the contrary, when working on a bug that is not yours, part of your investigation will be to learn a piece of code with a few new unfamiliar components. How the components interact, and get inside a mindset that is not yours, that can be challenging. And yet, solving a puzzle can be challenging as well, but very rewarding.
Let’s talk about solutions
When thinking about the approaches my peers and I have, I thought of a few things that can help me, and hopefully you, cope with the disadvantages of both the sides I’ve mentioned above:
Unit tests
I know, it’s old news, but I’ve come to know that whenever I’ve fixed an issue I’ve caused and then tested myself with unit tests it gave me a lot of confidence in my solution. I am sure that now I know what I’m doing, the cases are covered and there’s nothing to be stressed about.
It’s also true when working on a bug in an unfamiliar area, if you can add unit tests to ensure your solution solves the issue and doesn’t cause regression, it will build your confidence in the solution and prove your solution works as expected.
Asking for help
When solving a bug in an unfamiliar area it can be difficult to understand what the author meant, why they chose to do it in this specific way, or why they chose to name a variable the way they did.
My suggestion here is to try to find the person who wrote this code, and ask them if they remember what the thoughts behind it were. I know, in most cases the person is no longer working in the company or has moved to another team, so in that case maybe you can ask the most veteran person in your team. Just for the possibility it will lead you to a better starting point.
Be patient and try to enjoy the journey
Seniority will come. And in a wider aspect, with every bug you face you’ll learn something new, whether the bug was yours or not. You’ll get better at addressing the source of the problem, you’ll get better at thinking faster, you’ll get better at your solutions and you’ll gain better confidence in yourself.
Wrapping up
A lot of what I’ve mentioned above relates to the confidence we have in ourselves, and how we cope with failures.
When investigating this topic, I came across a post that made me think. In that post the main conclusion was to embrace the imposter inside of you. Every time you feel like an imposter, you should tell yourself you’re learning something new, you’re challenging yourself, and that means there’s progress.
Another thing that came to mind is how we can leverage, in our mindset, the disadvantages of a bug that is not in our area to the advantage of working on a bug in our code. Meaning, for example: it’s a bug I caused, but at least it will take me less time to understand where it came from and what the path is for solving it.
