I recently had to fix a nasty bug in an Ionic application. It was painful.
As part of the trauma recovery process I decided to document the lessons learnt fixing this bug.
Why was fixing the Ionic bug painful? Mainly because I've never worked with Ionic before. When you're debugging in a tech stack you don't know you don't know what's up or down and the ground on which you walk is constantly moving.
So here are some hard lessons I had to learn along the way. Hopefully you'll learn them by reading this blog post
Create a debug branch
This is an obvious one. You want to be free to explore without any consequences
Commit every progress you make
Whenever you think you made progress – however small – commit it. Given that you're coding in the dark there you're likely to get lost often. Put flags in the ground (aka. commits) you can come back to.
Use a debugger
A debugger is a tool that allows you to execute your program step-by-step. It's very valuable to see your code at run-time. This is extremely valuable to reason about your code. Sometimes it can be a pain to set this up depending on your tech stack. However it's worth effort.
Use a debugger to understand the external libraries you use
Don't be afraid to step into the code of external libraries at run-time. Most libraries are poorly documented so stepping into the code will help you understand the actual API of the external library.
Take a break when you get too frustrated
You get frustrated when you're not making any progress. Being frustrated also drains your energy. While you take a break you can think of a plan to make progress and you give time to your unconscious to think about the problem
Try to always have a plan
The danger of programming by accident is high. Try to formulate a plan whenever you can. It can be an extremely simple and/or crude plan. Your plan should not always be to solve the problem. Getting an understanding of the system is also a good intermediary goal that will help you down the line
Take time to read the docs
Spend time reading the docs whenever you feel you don't know what plan to make
Delete code
You have version control so use it to your advantage. When you want to fix a problem it helps when you delete all superfluous code that could interfere with the solution to the problem you want to solve
Constantly test your mental model of the system
As you make progress you will create a mental model of the system. Stress test your mental model. Use your mental model to predict how the system will behave after you've made a code change. It's hard to make progress on shaky fundamentals
Start from scratch
Create a new codebase with the same stack and see if you encounter the same problem. If you do then you've either stumbled on a bug in a library or it's a bug specific to your machine (more likely).
Upgrade your libraries
Upgrading your libraries can make the bug go away. There is a chance the upgraded versions have more helpful error messages or have a fix for the issue you're facing.
Be on the lookout for changing error messages
Sometimes a system is broken for multiple reasons. So after you've fixed one problem your program still doesn't run because there is another error you need to fix. Don't assume you haven't made any progress. Commit your changes and proceed to fix the new error that popped up.
Avoid running in circles
Following the lessons already mentioned will help you avoid running in circles. It's important to make any kind of progress as much as possible. Progress is broadly defined. It can be narrowing the search space, understanding the system better, removing a warning message that's not causing an issue ...
Understand why an error went away
Sometimes we make changes to a codebase and an error away. However you don't really know why it went away. This is dangerous. You haven't learnt anything and you might not have fixed the problem structurally. A good way to help you understand why the error message disappeared is to make it appear again