Mental Models for Debugging Hard Problems

Good debugging skills come with a mix of intuition and some mental models on how to approach the problem. The former has no practical actionable steps because it comes from the experience of being exposed to many different problems and you just need to keep going on with your career and learning with every new debug. This blog post is about those mental models that will help you get rid of bugs faster.

First Principles Thinking

Start with the absolute truths about the problem. The idea is to break down the bug into its basic building blocks and then reason from there. Assuming the wrong things can lead you to lose hours down the wrong debugging path.

Scientific Method

Raise hypotheses and work towards validating or invalidating them, one by one.

This will prevent you from going down a path you’ve already tried just because you have no other ideas of what to do. This will also help you narrow the scope of your debugging which will make your google searches more specific and helpful.

Don't be lazy about validating any hypotheses because you think that it's not an important hypotheses to validate (or because it's too difficult). Go forward until you can be 100% sure and get rid of any doubt.

Know what you don’t know

There are four stages of competence

Really hard problems in programming are a reflection of lack of knowledge (think “probably there is someone out there that would solve this in an instant’’) so it’s important to bring awareness about your own skill set. If you know you don’t fully understand one of the building blocks of your problem (Conscious incompetence), it’s a good strategy to take a step back and dive into learning about it.

You may be having difficulty solving a problem because you are not aware of the deficiencies in your skill set (Unconscious incompetence) and a mentor or an online forum can help you with that if you ask the right questions (What are the building blocks of this?) instead of just going for the solution.

Good communication when asking for help

Your communication when asking for help should be efficient, which means you communicate the most information with the least amount of words. This requires a lot of mental energy on your part but will increase the likelihood of getting help back (because it will require less energy on the helper part to understand what you’re asking).

You should describe all your hypotheses, the ones already validated/invalidated (and the steps you took for this) and the ones you’re still trying to validate.

Practical real life example

The problem

Release build of our react native ios app not building with success after upgrading from RN61.5 to RN63.4

First Principles — What I know is true for sure?

Scientific Method

What I don’t know and should get knowledge?

AWS Expert and Full-stack Javascript Developer

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