The last few weeks have been a frenzy of bug fixing for my team and I. We've been building an ecommerce website for a global drinks brand using Next JS for the UI, Contentful as the content CMS and Shopify for the ecommerce side of things. Bug fixing is a key part of a developer's job and one that can be a real buzz. Seeing those Jira tickets diminish throughout the week can be such a fantastic hit. I wanted to share some strategies I use to be as efficient as possible during this phase of a project.
Keep a record of the bugs
It can be in any format of course but I always like to list out the bugs I'm working on in a paper notebook...a black moleskin of course, standard agency issue. Ticket number, short description, and a great big tick when it's complete.
Bug fixing days can be fairly tumultuous. Some bugs you can fix in a few minutes, others a few hours, and some scale off into god knows when or how. Keeping a record like this can help remind you that despite everything that has happened during the day, you have actually managed to fix some things. Essential for a developer's mental health!
Take a systematic approach
It can be difficult to resist the urge to get straight into coding a solution to the problem faced, but it's much better if you understand what the issue actually is in the first place.
There's a practice in permaculture that I always liked, about when settling on an unfamiliar piece of land you wish to make a homestead: you don't turn up and immediately start changing everything. You don't understand where the sun falls, what winds you will encounter, how the seasons affect the space you're in.
Making decisions before you're familiar with the place can be catastrophic and at the very least cause a great deal of regret. I have been there and done that, planted trees in not ideal locations out of eagerness, only to have to look at those errors for many years to come. So, in coding just like in homesteading, better to first, pause and observe. Then strike when you have the full knowledge.
Collaborate with your team
One of my earliest mentors used to tell me to only spend 15 minutes trying to work out what the source of a problem was, before asking someone else for their input. This is a difficult thing to stick to I admit, as you want to be fairly autonomous for your sake and for theirs. However, as time goes by I'm more and more convinced that this is a good approach.
It's not cheating if someone name drops something you hadn't thought of and can then go off and research and experiment that line of enquiry. Better that, than going down a rabbit hole that could last until the next morning. You're the one doing the work still, not them.
Also, it's so important to get a second pair of eyes on a problem. On this project I would often ask my peers to just take a look at what I was doing, for 2 minutes over a slack call. That brief human interaction was usually enough to get the juices flowing again and either confirm my approach or jolt me into a new direction.
Be patient, take a break
Despite all these tricks above, you can still go down seemingly interminable rabbit holes, and that can be a very disheartening experience. You feel like you're never going to be able to fix this bug and that you're a terrible developer. The truth is though, you always manage to fix them in the end. You might not know how the nightmare ends, but it will, and soon, like it always does.
One of the best things you can do when you feel like this is to simply get up out of your chair, interrupt the coding coma and do something else. Go do the washing up, put some laundry on, go for a run. Anything to break your mind out of the loop it's stuck in. In almost all cases after I've taken a break, I come back with a new idea, something different to try, and the impasse clears.
Keep the faith, you've done it before, you can do it again. Now go slay the Jira dragon with that calm confidence, and enjoy that well deserved hit.