Debugging is about knowing how a program should work and how it actually does work, and debugging is a skill that can be applied outside of software and in the real world.

I was recently reading Michael Moritz’s book Return to the Little Kingdom: Steve Jobs and the Creation of Apple, and was struck by a description of Jobs’ and Woz’s high school electrical engineering teacher McCollum:

McCollum was also the quality-assurance center. When students finished building radios, he disappeared into his stock-room, inserted some faulty parts and urged them to troubleshoot with their minds rather than their eyes. “You have got to be able to think it through,” he repeated. Keen students brought the devices they built in their bedrooms and garages for McCollum to scrutinize. He would jab loose parts with a screwdriver and wiggle the solder joints much like a rough dentist. On one occasion he criticized a knob on a power supply that Bill Fernandez had built because it behaved in the opposite manner to most knobs. Fernandez later said, “It was the first time I started to think about standards and human design.” (p. 46)

“Troubleshooting with your mind instead of your eyes” is one of the most important skills a computer scientist needs to pick up. It reminds me of when we had a SEV0 outage at Dropbox that impacted several important enterprise customers. At this point, we had three versions of the product we were shipping, and two of them were public. Only some of the users at these companies had been given the wrong version of our product. We were perplexed and stressed.

As the product manager leading the product’s enterprise team, I was given responsibility for resolving the outage. But because I knew how our software worked, I actually realized where the problem was – without reading any of the code. The crux of the issue was that our sign up/sign in flow, although very secure, was also very complicated (and slow): all authentication for any product in the Dropbox portfolio was routed through core Dropbox authentication. It seemed very likely that our engineering team had accounted for sign ups for our product in most but not all parts of the code: users signing up through a particular sequence, being invited to the product through a shared link, hadn’t been accounted for. After checking the code, we confirmed this was in fact the issue, and we were able to fix the experience and communicate any issues the customer might experience without much trouble.

If you know how your software works, it saves you a lot of time to problem solve without having to read it. If you’re a product manager, this is also a good way to impress your engineering team.

This skill has come with me to other areas of my work. For example, when I was managing the team at Vsho, a member wasn’t working toward a deadline the team had that week. I became aware of the issue when some of our team was offline – during COVID, we had adapted to working across a few different international time zones. Given that the team member was a part of all the team meetings and communications, I realized it was most likely because a separate team member hadn’t finished their deliverable, which the first team member was waiting on. Once you have an intuition that something is wrong, the faster you can arrive at issue, the quicker you can brainstorm and solve the problem.

•

“Troubleshooting with your mind instead of your eyes” is an important skill to learn early on, and requires deep knowledge of what you’re working on, whether it be software, a product or a team.