The Josephus Problem: How math teaches us to solve problems

When I was in school, I always thought math word problems were a little funny. I understood that the point was for me to apply math to solve real-world problems, but the problems never felt real. However, these days I truly appreciate all of the ways that math taught me how to think about, break down, and work through problems.

Numberphile has a wonderful example of how to approach problem-solving with the Josephus problem:

These are the same skills you can use to solve a problem in support, as well:

  • Gather data about the problem
  • Look for patterns
  • Make a conjecture
  • Test your conjecture

As noted in the video, it’s also incredibly important to tackle small, discrete parts of the problem and work from there to the larger solution. If you stare at a big problem, it can look impossible to solve. But if you can prove theories about small parts of the problem, the larger solution can become clear.

Thank you to all of my teachers and others who encouraged me to learn and practice these skills — although I don’t do much pure math these days, I use these skills every day!

Advertisements

Using Mental Models for Troubleshooting

When a user reports an issue they’re having with the product you support, how do you know what to do next? How do you identify the source of the issue? How do you know where to start investigating?

I’ve mulled over these questions countless times as I tried to explain to coworkers how I troubleshoot. When someone describes an issue, it always seems like the possible causes just pop into my head, unbidden. But of course that isn’t it at all — I have gotten better at troubleshooting our products over time, and that didn’t happen by chance.

When I read Jim Grey’s post How to Hire an Entry-Level Tester, his key traits for testers meshed with how I understand troubleshooting and this trait stood out:

Create mental models:  Building a mental model of a system, even if it’s incomplete or partially inaccurate, helps a tester orient themselves to a problem and generate ideas on how to work through it.

When I look at a problem, I fit it into my mental model of the product and use that model to start investigating. On my team, I’ve started to explicitly discuss mental models, how to build and expand them, and how to use them to get better at supporting and troubleshooting our products. Rather than trying to summarize the things we’ve talked about on my team, I’ll share the introduction to mental models I wrote recently, as part of a troubleshooting training I’m developing for WordPress.com support.


Mental Models

mental model is “an explanation of someone’s thought process about how something works in the real world” (Wikipedia). In other words, a mental model is how you understand or represent a real thing in a more simplified or abstract way.

Mental Model of a Bicycle

To get a better sense of mental models, let’s look at an example: Bicycles. Not everyone understands every part of a bicycle, but even if you just ride a bicycle now and then you probably have a concept of what it is and — at least to some extent — how it works. That is your mental model.

A user’s mental model

As a bicycle user, your mental model might be very simple — all you need to know are the parts you interact with or a general sense of what makes a bicycle different from, say, a tricycle or a car. In this simple mental model, you’ll see that the bicycle includes a frame, handlebars, a seat, and two wheels:

bicycle-simple
Continue reading “Using Mental Models for Troubleshooting”

Troubleshooting in 5 “Simple” Steps

I recently talked with my coworkers about strategies for troubleshooting. We were focused on how to troubleshoot issues while chatting with our users, but I wanted to start with a basic workflow for troubleshooting bugs in any support medium. Here’s what I came up with:

  1. Understand the problem from the user’s perspective
  2. Determine if it is expected behavior or a bug
  3. Search for previous reports of the bug or discussion of the feature
  4. Test to see if the bug is reproducible
  5. Report the bug in the appropriate place

I feel pretty good about that workflow, in terms of describing how you can identify and report a bug. As soon as you start considering the rest of the support picture, though, it gets more complicated.

Here’s a rough flowchart I just sketched out that takes into account the larger context:

Troubleshooting flowchart.jpg

I like how that flowchart encompasses not only what to do while troubleshooting a bug, but also some ideas for how to handle non-bugs — and what to do about the user who’s still stuck even after you identify and report a bug. Because let’s be honest, some bugs aren’t going to get fixed, or the fixes might take a while, and we’d still like to help those users get to where they want to go. I guess that’s a more holistic view of troubleshooting, beyond being a bug collector. 🙂

Ask for Information, not Answers

One of my favorite parts of my job is troubleshooting. I enjoy troubleshooting issues for users, and I enjoy helping my coworkers troubleshoot issues they encounter. There’s just something satisfying about seeing a mysterious problem and picking it apart until you find the cause.

As a result, people sometimes ask me how to get better at troubleshooting. It’s a hard skill to explain — sometimes it feels like I just know the correct solution to a problem, and sometimes it feels like I’m just intuiting where the issue lies. Those aren’t really helpful to someone who wants to improve, and the truth is that I didn’t walk into this job with all of the answers or intuition I have today. So where does it come from?

One key that I realized is that to be good at troubleshooting, you have to be curious. Specifically, you have to ask questions (either literally asking another person or just asking yourself as a step in the process) with the intent to learn, not just the intent to get an answer for the one problem you are currently facing. Whether you’re getting help or you’re eavesdropping on someone else who’s troubleshooting an issue (also a great way to learn!), here are things to consider:

  1. How did someone else break down the issue I’m looking at and approach or investigate it?
  2. What is the general subject underlying this issue, and what information can I brush up on (with further reading, classes, conversations with experts) that will help me solve an issue related to that subject later on?
  3. What keywords (error messages, feature names, descriptions of the problem) can I use to search for past occurrences of this issue?
  4. What tools do I have access to that could possibly give me more information about the problem that underlies this issue?

A lot of the time, my troubleshooting is a lot of trial and error. I might pop open my browser console to discover it’s completely blank, and later find out that my terminal could have given me more useful information. Or I’ll be absolutely sure I’m encountering a theme bug, only to discover that the problem is solved by changing a widget. That’s ok.

Learning to troubleshoot is learning how to approach a problem, and going down the wrong path is bound to happen in that process. But the more practice you get, and the more techniques and information you learn, the better you’ll become at identifying the likely cause of any given issue and figuring out how to resolve it — without having to rely on someone else handing you the right answer.