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!
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!)
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, about how you can move past a problem! We heard everything from naming variables, to process, and (literally) changing your environment.
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.
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…
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!
.webp)
