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.