Recap

This week we talked about troubleshooting and debugging; Toggle and I love to talk about this stuff! Since we did resiliency last week, we wanted to continue to weave in the steps we have in software development. Often, we only look at these things when something goes wrong; however... we think it’s so much more. It’s a core part of what we need for discovery and growth. When we talk with junior engineers, this is one of the first things we are looking for beyond language knowledge. When you’re presented with a problem, what are the steps you take to try and solve it? From that challenge, comes a conversation. The conversation can delve into tools, processes, and general ideation on how to handle problems. When we posed that theme this week, we got a lot of responses!

Questions

😂 What’s the weirdest bug you've encountered?
🛠 Have a favorite debugging tool/process?
💡 Biggest lesson learned from debugging?
👩‍🏫 Fundamental beliefs on the debugging process
😫 Advice for when people get stuck?

Highlight Reel

Simple can be best

When you're just getting started and need to see what is happening, sometimes a quick console.log() can be just what you need. Regardless of your editor, you always have this available to you. Not fancy, not quick, and you’ll need a few of them – but they’ll get the job done!

🛠 Have a favorite debugging tool/process?

console.log(JSON.stringify(obj, null, 2)) I know it's not fancy, but it work 😅 — Carter Rabasa (@crtr0 ) April 22, 2020

TIL

On the flip side of this discussion: our Developer Advocate, Yoz, kindly pointed out all the debugging tools we had available to us beyond print statements. What was great about this response, was not only did he talk about why, but he gave us a demo. (No, he was not prepped ahead of time – he is just that plugged in!)

The problem is that adding *one* console.log() might be quick. But it’s almost never just one. That screenshot has at least FIVE, including the type that feels the most shameful whenever you have to use it:

if (...) { console.log(“yes we went down this branch OK”) — Yoz Grahame (@yoz ) April 22, 2020

Advice

One of the amazing things about community in general, which we love, is helping each other out. This week we heard from a lot of people on the advice column, regardless of experience, how you can move past a problem! We heard everything from naming variables, to process and (literally) changing your environment.

My main tips for people learning:

Have a project - actually build something. You learn so much more than learning in abstract. If you're struggling with some code, extract that code out on its own. Get it working, then apply what you learned in the larger codebase. — Judy2k (@judy2k ) April 23, 2020

Experiment as you learn, give variables meaningful names, with Python 3.7 make use of type hinting.

— shawn (@sbmccarth ) April 22, 2020

My biggest lesson, fundamental belief, and my best advice if you're stuck debugging is: Changing your view often leads to an answer!

Ways to do that: 🚶‍♀️ Take a walk around the block 🦆 Try explaining your issue out loud 👀 Look for similar problems 👩‍💻 Change your color scheme https://t.co/fsSI8Ub50m — Ryan Lynch (@shiftyp ) April 22, 2020

People and Processes first

This was a real treat: Jennifer graciously gave us an amazing thread on all things debugging. However, we want to highlight a few key items here which no one else quite keyed into. Beyond the actual tools we use for debugging, we need to take a step back and look at the people and environment we set for developers to debug and write code in the first place. This involves training, empowering, and sharing knowledge with your team. More importantly, as a leader, be sure to not take the problem on as an individual, even if you are the most qualified. Use this as a teaching moment, and distribute the workload. It opens up the problem to be solved in a different way, and gives an opportunity for your team to learn.

One of my fundamental beliefs about debugging is that you have to be prepared. If you are new to a company/environment/technology, you need to talk to folks and build up the set of tools and techniques that apply. #ToggleTalk

— Jennifer Davis (@sigje ) April 22, 2020

So the "what to use" isn't super interesting, but we had looked at TONS of tcpdumps prior to this. Having the space/time to do so while not also dealing with the intricacies of high impact incidents was critical to figuring out what happened #ToggleTalk

— Jennifer Davis (@sigje ) April 22, 2020

Next, I worked on leveling up everyone on the team to be able to recognize the symptoms so that we could minimize the impact of the stampede. This meant coordinating response and NOT immediately doing all the work myself. #ToggleTalk

— Jennifer Davis (@sigje ) April 22, 2020

A Funny

Well, we only got one funny story this week (darn it!), but we found it doubly funny as it had a recursion irony involved. By trying to debug, they wrapped the entire method in an if debug enabled case, which caused the program to not start in production and well, you can imagine that didn’t work well. Maybe a case for LaunchDarkly to do this test in production… 😏

Oooohh a fun bug, speaking of logging. Many moons ago we worked with a junk logging framework where debug was really slow even if it was not logging. So we would check for debug with an if. When in dev the app worked when in prod, Nope. The if wrapped too much code causing a bug.

— shawn (@sbmccarth ) April 22, 2020

Summary

This is a big theme and one that we probably could have talked about all week! Troubleshooting and Debugging are at the core of what we do as developers. Oftentimes, we can spend more time troubleshooting something than we do writing lines of code. One of my teammates said it best, “Writing 10 lines of code in a day, truly is a victory.”

Want more?

Guess what? We run this each week and if you missed it this week, we’d love to hear from you next week! We’ll change the topic and let you know through the hashtag #ToggleTalk. Please join us if you can, next Wednesday! Sneak peek… we’re going to be talking about Chaos Engineering. And if Twitter is not really your thing, you could check out our Test in Production Twitch Stream, featuring Casey Rosenthal as our guest next week!