Syntax Error #14: I don't know

Happy May!

When we work on our code base, we accumulate a lot of knowledge of how it operates and what might be the causes for our software misbehaving. Often, this is an asset. I'll quote Jenn Creighton again: "The best debugging tool is knowing something well".

But knowing too much can also become an obstacle that slows us down. When we think we know something, we start to skip steps which can lead to a wild goose chase when we pass over the real issue. I've touched upon this in the first issue and in the fourth issue but I want to dedicate an entire newsletter issue for this as well.

So join me today to explore how to say: "I don't know".

Leave your assumptions at the door

In the first Syntax Error email, I shared my secret sauce:

Whenever you are debugging, don't try to read your code and find the issue like that.

Looking back at it now, I feel my idea was too narrowly communicated.

At its core, I see debugging as a practice where a great tool is asking questions: from ourselves, from the code base and from the application runtime.

The main question you should start with is: "What's happening?"

To be a bit more specific:

• What is the problem?
• When does it happen and how it shows?
• Can I replicate it consistently?
• What is the code path that is executed?
• What's the state of the program at the point of the problem?
• What's the state of the program in the previous step?
• What's the state of the program in the previous previous step?
• What's the state of .... (you get the drift)

The less assumptions you make about the answers to any of these questions, the better. Instead of asking "what I think is happening?" or "what should happen?", focus on making sure you ask "what does actually happen?"

None of these steps require you to read your code and reason with it.

They all require you to say "I don't know" and then start working on it.

Answering those questions

First three questions are about making sure you know what you're dealing with. If you're not sure you've identified the problem correctly, you may end up spending all your time wildly chasing geese (I've always wondered if it's the geese or the chase that are wild in that idiom).

The fourth question is about knowing and/or finding out how the execution of the code flows in your code base. I was lucky in my first developer job that our CTO had the patience to sit with me and teach me this. Not how it flowed in our application but how to figure it out in any code base. Thanks Justin, much appreciated.

One thing you want to make sure from the get go is that the code you are working with is the one being run. The next thing is making sure you've found out the parts that contribute to the issue.

The last four questions (and counting...) are answered by mastery of debugging tooling. Print to the console, set up logging or set a breakpoint and run a debugger. All of them help you explore the state and make discoveries based on facts about what is happening rather than your guesses on what it should be. Remember, if your assumptions and guesses were correct, you wouldn't be debugging in the first place.

And remember, whenever you're in doubt, the ducks are there to help you out!

Finally, you'll land in a spot where you can say: "Hey, I know what's wrong".

Then you can go on and fix it, document it well and enjoy your win.

Story time

"What?" I uttered, stunned.

"The Wi-Fi only works while it's raining," he repeated patiently. "It started a couple of weeks ago, and I haven't had a chance to look into it yet."

When I ran into this story in Predrag Gruevski's blog, I read with a big smile on my face. It's the kind of story I love - and it's a perfect debugging story.

On the surface, it sounds ridiculous. How could rain make the wifi work? And that is what makes it such a great debugging story: when something is so weird and out of place, you end up having to drop your assumptions and start debugging.

It is also a story of how regression can cause issues just by time passing by. Nothing in their setup changed but the world around made things worse.

I find those kind of issues often harder to debug. When you are sure things used to work, you need to take a hard look at the big picture and then dig into details because you cannot simply look at the changes you or your team has made.

I'll let you find out what happened with Predrag's story from his blog.

~~ ~~ ~~

In Mastodon, this great toot by SnackTraces popped into my feed:

New(-ish) software creation folks, do not mind those that may make fun of you for using or tell you that debugging tools are "for the weak", etc.

Learning how/when to use them only makes you...
- more efficient writing/debugging code
- more likely to learn what chunks of code do while stepping through
- better at writing live expressions in a watch window to prove a small concept without restarting session

and I felt it was worth sharing with my readers too.

Almost every time I've been to a meetup or tech conference to talk about debugging, someone has come to talk to me and mentioned how someone has made them feel lesser of a developer for their approaches to debugging. I'm happy they come to have a chat but it makes me sad that there are people in the industry putting others down like that.

Syntax Error is created with love by Juhis. If you liked it, why not share it with a friend? Or if you have any feedback or just want to say hi, hit reply. I'm always happy to hear from my readers and learn about what you do and how you debug your issues.