Published in


Conscious of debugging approaches

When I’m stuck, I like to fall back to old ways and just do things that I remember worked for me, even when the situation then and now are quite different.

For example, I was trying to start an Android emulator for a React Native app on my MacBook and it kept showing some kind of View error in the spawned emulator window. What I did was to go back to the repository’s README and follow the setup instructions again to the tee. It didn’t help.

Then I realised that this had worked for me in the past for web applications, not mobile applications. Are these development environments similar enough for the troubleshooting steps to translate? I’m of the opinion that they probably are not.

Web applications involve running a Node.js runtime while mobile applications, even React Native ones, also involve running a bunch of compilers and require Xcode and other native tooling. There are probably more points of failure in the build process.

So here I was, basically falling back to what worked before without thinking, and it was wasted time.

The next thing I did was to read the error stack trace in Terminal to try and narrow down the specific error and search on our Slack channels for other occurrences. I hoped I’d find an answer. In this case, I didn’t.

So I tried a few more things, falling back on Things That Worked In The Past, like commenting out some environment variables. Trial and error here and there, googled for answers, the works.

Only after two hours in a frustration spiral did I stop and say to myself, “hey man, maybe you should ask someone in the team. They might immediately know what’s wrong.”

So what’s the moral of this story? Perhaps it is to be more conscious of the chosen approach to debugging something. Falling back to doing what has worked before is not a good default.

A better default, I think, is to:

  1. try each of the familiar ways once quickly, and if they fail to resolve the problem,
  2. then copy-paste the error message and post it to your teammates with an accompanying description of what you understand of the problem.

Compress all this into 15–20 minutes max, and move on while you await the answer.




notes from the field of software engineering

Recommended from Medium

All about UX (How to Build a PaaS, Part DeUX)

Setting up your first Azure Repos codebase

Three tips for entry level programmers from a junior

1 Line of Code and your 2D-Player will Look Where It’s Going

Welsh Azure user group with Abel Wang and April Edwards!

READ/DOWNLOAD=@ UML Distilled: A Brief Guide to th

Debug .Net Core apps using Linux Kernal in Windows OS

A CI/CD solution in under 10 minutes Featuring Terraform, Ansible and Drone CI on GCP

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
Nick Ang

Nick Ang

Software Engineer @ Shopify. Dad, rock climber, writer, something something. Big on learning everyday.

More from Medium

Why Software Development Works Like The Culinary Arts

Reproducible builds don't make sense in a cloud-native world

Adding The Most Value In Your Software Engineering Discussions

Tech debt explained to everyone