What My Cousin Vinny can teach us about debugging

If you haven’t seen My Cousin Vinny yet, go watch it real quick, we’ll wait.

Great movie, right? Marisa Tomei absolutely deserved her Academy Award.

In case you didn’t watch a whole movie in between the first and second line of this post, the central plot of the movie involves two people on trial for a crime they didn’t commit. There are multiple witnesses who all claim to have seen them and they call up one of their cousins (Vinny) to defend them (this summary doesn’t come close to doing it justice though).

What does that have to do with debugging customer issues? Well, there’s actually a few things:

Witnesses are unreliable

If you’ve ever been in Customer Success, or just been on the receiving end of an unusual ticket that you need to fix, you know that your customer’s account of what’s happening is just one piece of the puzzle.

And while I would recommend…

…yelling at them until they admit that grits take 20 minutes to cook (or whatever your products version of that is), you should clarify exactly what the user is seeing. That way you won’t waste a ton of time chasing down the wrong issue.

A simple comment like “I can’t edit my settings” could mean anything from “Your APIs are down” to “The validation error isn’t displaying correctly” to “Someone changed my permissions and I am not allowed to edit settings anymore.” One of those isn’t even a bug!

Your questions might be BS

It’s really easy when you know your product inside and out to make assumptions about what a bug can be. The unfortunate truth is that those assumptions can blind you to real issues.

This can be made worse if you go into a debugging situation assuming the customer doesn’t know as much as they do.

This might feel somewhat contradictory to the first point, but I don’t think it is. Your customers can be mistaken or use different language than you would use, but they still are seeing behavior that they weren’t expecting. If you ask your questions assuming you already know the answer, you might end up missing the real customer issue or a scarier underlying bug.

If only I knew what he knows

While having a conversation with a customer about what they are seeing is a good first step, you may need to rely on other sources to help you fix it. You can think of the entire process as collecting evidence and the conversation/bug report is just one piece of that.

There are tools like Sentry which can provide stack traces or you can set up an ELK stack for managing your logs/traces. At PropelAuth, we introduced user impersonation so you log into your product as your customer and see what they see.

The amount of evidence you need to gather will vary depending on the situation. However, having a few tools in your toolbelt ahead of time will simplify any process that involves debugging customer issues.

Closing arguments

Debugging may seem like a simple process, but it actually can be incredibly noisy. The next time you are struggling with a bug that you just can’t reproduce, try rechecking your assumptions. Does the user’s report of what happened make sense or do you need to clarify something? Is there more information you can gather that will help you get to the bottom of it?

If you aren’t careful, you might be accidentally convicted of murder (or… you know, whatever your product’s equivalent of that is).