Fixing bugs, even if they belong to other teams, will let you grow as a developer. This is about some of my tricks for the right mindset.

Image for post
Image for post

I recently fixed some bugs for another team. My main takeaway of this work was that getting the right mindset and trying to understand the perspective of other developers makes bug fixing less annoying.

The bug ticket

Let's talk about the problem which I had to solve.

The ticket I grabbed from our ToDo column (JIRA) in the morning was about a failing request. The expected behavior of the application was to hit an endpoint of our backend at: www.a.com/uid=<UID>.
The bug report stated that sometimes the request looks like this: www.a.com/uid=null

Two things stood out for me instantly:
1. The word sometimes, because it usually means the developer either has to deal with race conditions or the bug reporter didn’t test it carefully enough
2. The word nullin the URL string, because it looks like a failing conversion to stringwhich could happen anywhere in the codebase.

Since I wasn’t able to reproduce the bug on our staging environment, I checked out the source code. I had to deal with a project of another team, so I was a bit nervous about being able to run everything on my local machine, but it worked pretty flawlessly. The project is a nextjs application.

I think it’s very usefully for us to take a short break and have a look at my situation at that exact point before talking about the solutions.
Let’s do what I call a pipe-reflection (PR). This method is a creation of mine. It is a mix between something from the field of personal development, interacting with code, and being realistic. In several books, you can read that you grow as a person by being thankful. One often mentioned aspect is to be aware of your situation, take one step out, and be grateful for what you see. I usually transfer this technique to my work as a programmer. Reflection is one part of it. The other part is the word pipe. On the one hand, it stands for the letter “I“, which looks like a vertical pipe. On the other hand, it stands for piping and considering every aspect of you and your actual problem one behind the other. It always reminds me of a chaining of method calls on an object or class.

Let’s do a quick example of pipe-reflection based on our actual problem. I start with the most abstract points and pipe my way to the real ones.


  • …am a developer
  • …work on a project of a team, which I am not a member of
  • …am able to code ReactJS but have minimal experience with server-side rendered pages
  • …think one-half of the bugs I have to solve could be a race condition, which in my experience is harder to find
  • …should be able to fix the nullbug relatively easy

How is your mind now? At least for me, the PR helps to avoid the well known anti behavior of developers touching someone else’s code, especially when it’s not part of your teams’ codebase. Furthermore, it now stands out for me where to start.

Solving the problems

If you understand the bugs, then solving them is more comfortable. You don’t have to rely on trial and error. Furthermore, you’ll be able to explain everything to other developers in the future.

The error itself was a wrong casting of a JSONresponse. The developer who implemented the solution used the Fetch-API of ES6. By casting the response to JSONthe null value transformed into a null string.
As a result, a wrong value gets into the local storage. I solved it by simply avoiding a cast of a null value.

One advantage of solving the null bug first was a better understanding of the project itself. I got a better general understanding of the application, and also the data-flow became more transparent to me.

To explain the race condition more clearly to you, I use a more easy but logically similar example. Let’s begin with one of the bugs I found. At one point in the application, a configuration loads via a simple API call. I discovered a utility function which called the endpoint. It looked somehow like this.

async function loadConfiguration() {
const data = await fetchConfig()

Of course, there was more code, but error handling and side effects don’t matter for our example. My first thought for this snippet was: “Hmm everything seems fine here”. At this point, I usually stand up, grab an energy drink, or have a non-smoker smoking break with a colleague. Right before I wanted to stand up, I saw a code line that got my attention.
My GitLens (plugin for GitHub inside VsCode) showed me “Edited by Anonymous 2 days ago” right at the line of the await fetchConfig().
I looked at the difference before that last commit and saw that only the awaitwas new. To make it clear to you why that line of code is an indicator for me, I have to explain a bit more about the bugfix mindset of developers.

Let’s think about how our all beloved product owners (PO) always need product aware developers. They want their developers to think outside the box. They don’t want story killing coding machines. The perfect developer should see the impact of changes to the product before they go public.

However, why am I writing about this at this point in my story? That’s easy. Think about it! “They need these guys” means that they usually don’t find or have these guys very often. Alternatively, the other way around: Most of the developers working at the code are the opposite and don’t think the product.
Especially when it comes down to fix a bug, the awareness of (even outstanding) developers decreases. As a result, they might close bug tickets a bit sooner, just because they enjoy working on something else more (new features, for example).

Back to our problem. Something was telling me that the described mindset and losing the focus to early could be what happened here. I decided to have a look at the part, where the loadConfiguration()function is called. I found the calling code in a React.Component. The code looked like this:

class XY extends React.Component {

componentDidMount() {
render() {
return <ADeepNestedComponent />

What do we see there? I was right guys. The DeepNestedComponentdoesn’t wait for the loadConfigurationto finish and that’s the cause for wrong nullvalues in our URL even if we have fixed the nullbug.
Sometimes the loadConfigurationlogic (e.g., request) might finish first, and the application might run as expected, but most of the times the render is faster and somewhere in the DeepNestedComponentthe second request doesn’t find the value that generally should be there (because it depends on the configuration).

There are several ways to handle the correct data flow in react applications. In general, you have to decide which data is necessary for the application to run. If you find the critical data (like in our example), you have to implement a behavior, which shows a loading animation or kind of blocks the rendering in general.

For the above case, setting a loading state and waiting for the configuration to be loaded is enough.
We can then render the DeepNestedComponent without running into unavailable data.

My checklist for bug tickets

  • Get a general overview of the failing behavior. Use your experience to remind yourself whether you have seen something similar or try to guess the cause of the problem
  • Before coding right away try to take a step back and make yourself aware of your situation (project, language, environment)
  • Maybe use the Pipe-Reflection to reflect everything outside-in
  • Try to prioritize the difficulty of the bugs (if you have more than one to solve)
  • Start from easy fixable to hard fixable

Do you have some routines or specialized knowledge in the art of fixing bugs, or do you go straight ahead?

Let me know!

Stay coded!

Written by

Full-Stack Web-Dev from Hamburg, Germany.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store