Syntax Error #15: Walking the walk

Hello all Internet friends!

Three weeks ago, I started a new job as a full-stack web developer. In addition to learning a ton of new things and making new friends with brilliant developers, I noticed the situation truly tested how well I can follow the advice I've been writing in this newsletter.

I'm using this month's newsletter as an opportunity to self-reflect and share what I've learned about myself, the situation and debugging in general.

Welcome along!

Walking the walk

I advertise this newsletter as a way to turn stressful situations into joyful explorations. Debugging is almost always a stressful process to some degree. It starts when something is wrong, and we don't yet know why. That stress can trigger our fight-or-flight response and cause us to have tunnel vision.

I consider myself rather adequate debugger but I've noticed I don't always remember it right away when the situation starts. I get that tunnel vision, forget most of the things and don't notice the obvious.

Starting a new job has been a great way to put my debugging abilities to a test. I've been given a codebase I've never seen before, tasked to build new features and some of the technologies I'm not that familiar with. As a result, a bunch of small-ish bugs have appeared during the development phase.

One interesting thing I noticed while debugging them was that because both the codebase and some of the technologies were new to me, it was really difficult to adjust my assumptions. You know, those things that you should leave at the door. (Spoilers: I didn't leave them at the door.)

I made a bunch of assumptions about how these bugs appeared. My main assumption was that I had not understood the new project or the tooling and that's why I was struggling. Once I realized I was following those assumptions, I remembered what I'm supposed to do and took a step back and started debugging better following the good practices I share in this newsletter.

So far, none of the bugs have been caused by the things I assumed caused them.

They have been rather simple, basic mistakes that mostly happened because I was balancing multiple things at the same time: learning new codebase, implementing new features, learning new technologies, and the small nervousness or stress that starting a new job in a new team brings. With all those things in my head, there's been less available mental energy for the complex art of writing code.

One of the bugs was caused by me using a snake_case when camelCase would have matched the expectations of the code. When debugging, I saw the snake_cased properties having right values but thanks to the tunnel vision and wrong assumptions, didn't realize the camelCased once were also present (from defaults) and they had the wrong values. Oops.

What has been fun to notice is that each time when I've noticed myself falling into the trap of assumptions, I've been able to check myself and fall back to my debugging routine. I then start to follow the breadcrumbs, set up print statements and breakpoints and take full advantage of the developer tools. Not to forget the rubber ducks - sometimes with my many ducks at home and at the office, and sometimes bouncing ideas with a colleague only to finish the initial problem description with an "oh, now I see it".

What I really want to say is this: it's okay to make mistakes and it's okay to make mistakes when debugging. When you catch yourself slipping into following assumptions rather then real clues, take a step back and take all the tools and approaches you've learned so far and start applying them and you'll figure out the bugs.

Story time

Last few weeks have been busy with the new job and a conference we ran last week so this month's story time is shorter than usual.

Nikita Lapkov's "urban archeology project" to discover what a touchscreen device in his new apartment was all about is a great story of following breadcrumbs and debugging a real-life mystery.

Chris Wellons has two handy GDB breakpoint tips for C programmers: continuable assertions and named positions.

And finally, Brendan Gregg's Linux Crisis Tools is a worthy read for everyone who's ever gonna debug systems in Linux. He has compiled a list of tools that you should install now (and learn how to use), before you need them for debugging.

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.