Post

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
Post

The Problem with Averages

If you’re interested in inclusive design, I’d recommend listening to “On Average” from the podcast 99% Invisible. From the episode:

So in 1926, when the army was designing its first-ever fighter plane cockpit, engineers measured the physical dimensions of hundreds of male pilots and used this data to standardize cockpit dimensions. Of course, the possibility of female pilots was never considered. Of course.

The size and shape of the seat, the distance to the pedals and the stick, the height of the windshield, even the shape of the flight helmets were all made to conform to the average 1920’s male pilot. Which changed the way the pilots were selected.

You basically then select people that fit into that and then exclude people that don’t.

Designing for the average and excluding anyone who doesn’t fit that average isn’t, well, inclusive. The episode goes on to discuss how design (including in the military) has become more inclusive — but it’s still something we struggle with.

From what I’ve seen in software design and development, one of the challenges is deciding which user personas and scenarios will be considered in your design, and which issues are only edge cases. Where and how do you draw that line? It’s also a matter of just remembering to think outside your own perspective, to consider cases that you haven’t thought of already. (As designer and fellow Automattician Mel Choyce pointed out, it’s about challenging your own biases by seeking out and really listening to users with different perspectives.)

As a linguaphile, I tend to notice when software design struggles or forgets to include non-English languages. For example, designs that aren’t responsive to languages that take up more space (ahemGermanahem) or that don’t consider right-to-left languages end up excluding entire populations of potential users in other parts of the world. It can be hard for monolingual designers and developers to know how their products work in other languages, and it’s always satisfying when I have a chance to test a product and suggest language-based enhancements, so people can use our products in any language. It’s one small way I can help democratize publishing for users around the world.

Post

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

Post

Building a career in support

We need to build our support teams to add value across the company. We’re all expert communicators. We know not just the ins-and-outs of our product but how to convey our expertise in a way that’s relatable to our customers. That’s an immensely valuable skill. Our next step must be communicating back to the company what we learn from customers and from each other.

It’s that next step where we all too often come up short in support. We’re great at communicating with customers but, at times, terrible communicating internally to other teams at our companies. How many times do you hear about a development team not being on the same page with support? Or a sales team that makes promises to customers which support knows they can’t do? Those are real problems. And while they’re hard problems they’re solved with clear, consistent communication across teams. That’s our specialty!

Andrew Spittle — Building a career in support