How to Be a Better Debugger - a Series
One of my favorite things to ask interviewees is this: imagine the ideal software engineer. This engineer has 3 discrete skills:
Their ability to communicate with others.
Their ability to debug code.
Their technical expertise and experience.
I then ask the candidate to rank those skills in order of importance. Then I ask them to rank themselves on each of the skills. The way the candidate answers the question tells you a little bit about how self-aware they are; it also tells you what the ideal software engineer looks like in their head. The order doesn’t matter so much as their rationale for the order.
I think the order above is correct. Also, note that I called them skills and not qualities. Skills are things that can be learned and improved. Communication is at the top because of how difficult it is to learn to do well. Yes, you can become a better communicator. But I think the results depend a little more on aptitude than the other two on the list. As for expertise and experience - I think it’s nice to have. But you can gain experience by doing a job poorly. I have experience in woodworking. I’m not a good woodworker. Debugging — debugging is huge. Depending on the maturity level of the project, I’d wager that you spend 35%-75% of your coding time doing some kind of debugging. In an interview, I’m more interested in the person who tells me about an interesting problem that they solved than the person who rambles on about why Redux is clearly the best way to do state management in React apps.
That might be because I’m self taught. I got into this field because I enjoyed the problems. I never studied computer science or software engineering, so early on in my career I wrote a lot of code that didn’t work. Because of that, I got decent at figuring out why stuff wouldn’t work. But it wasn’t until I got onto my current project that I really honed my skills as a debugger.
I’m currently in a team lead role on a project I helped start. It’s a multi-process javascript framework and architecture designed for creating enterprise grade workflows. It’s very complex. Any given problem can be in the DOM, in the layer above, in the layer below, or somewhere in the communication layer. The product itself is only about 3 years old. We currently have 11 very smart engineers working on it, most of whom have been with us for less than a year. Because the problem space is so big, so complex, and so novel, I often end up serving as pair-programmer, rubber duck, and observer. Over the course of several months, I found myself giving the same or similar advice to different people. At some point, I had an epiphany in the form of a series of thoughts.
“Not everyone solves problems like I do”.
“ 😱”
“They’d be more efficient if they did.”
”Maybe I should do a talk about debugging.”
A couple of weeks later, I did a talk about debugging for the whole company. I want to be clear - I don’t think that the approach I will outline is the best way to solve every problem. However, if you combine the general approach and avoid some of the pitfalls that we will go over, you will be markedly better at debugging code.
By the end of this series, you should feel confident enough to parachute into a section of code with nothing but a stack trace or a description of what should happen and what is happening. From there, you’ll be able to make a guess, gather data, test your guess, and iterate quickly.
Up next: A Scientificish Approach to Debugging Code.