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. 🙂


How We Engineer Happiness at

The Happiness Lead at Automattic, Andrew Spittle, did a nice interview with Olark about how we approach engineering happiness for everyone who uses and other Automattic products:

Engineering Customer Service at

Along with the larger overview of what we do, Andrew included this little tidbit describing what I think is one of the biggest challenges (but also biggest opportunities) in our work in the forums, where I spend the bulk of my time:

… a Happiness Engineer also does a little bit of qualitative customer feedback. We always get long public forum threads whenever we change something. It’s partly going back through those and picking out the highlights or the commonalities, and communicating those back to product teams.

Using GitHub at Automattic

As a Happiness Engineer at Automattic, I try to be generally aware of things that are happening across the company — or at least in the areas that touch, where I do most of my work. It’s impossible to keep up with every detail, but I need to be ready to reach out to a variety of teams if something comes up that’s related to what they’re doing.

Over time, I’ve noticed myself turning to GitHub more and more during my daily work at Automattic. Whether they are developing code, tracking bugs, or sharing resources, many teams are now using it. You can find public GitHub repos for projects as varied as Jetpack, _s (a starter theme), Babble (a plugin for multilingual WordPress sites), and Legalmattic (legal documents used for (You can also browse all of the public Automattic repos if you’re curious!)

I was aware of the basic idea behind GitHub and how it worked, but up until about a month ago I only ever opened new issues or added to existing issues, to track reported bugs. Recently, though, I cloned a GitHub repo and learned how to switch between development branches to locally test out features that are under development. And yesterday, I finally committed and pushed new code to an Automattic repo for the first time!

It was nothing earth-shattering — just a modified piece of JavaScript to share with my support team, so we can experiment with tracking support issues in a different way. But it felt good to understand how the whole process works. (And, I won’t lie, I feel pretty badass every time I learn to do something new on the command line.)

In addition to Google searches and tests I did on my private repo, here are a few tutorials and references that helped ease my mind before I made that first commit:

English only? I hope not!

It’s no secret that English dominates the tech sector. From communicating with coworkers to launching software, English usually comes first. Even the most well-meaning companies can struggle to reach non-English-speaking users and provide a localized experience in their native language. And no surprise there, either — it’s really tough to do well.

As a small part of my job, I do what I can to help make better for users around the world. (And I’m certainly not alone. There are a lot of rockstar translators contributing to, along with a well-established group of polyglots working on the open-source WordPress project.)

I’m not a developer, so much of what I do is connecting people with resources. I help volunteer translators get oriented so they can help translate into their own language. I teach our internationalization team about the tools and methods used by professional translators. I find or report bugs that cause translation issues so the code can be improved. And I help educate all of my colleagues about how translation works. For a lot of people, just thinking about using in another language is … well, entirely foreign to them.

But every time someone stops to think about how a product works in another language, it makes a difference for users around the world. That’s why I was so impressed when I saw that Mark Zuckerberg held a Q&A session entirely in Chinese:

Sure, it wasn’t flawless Chinese, and I wouldn’t bet on Facebook’s developers switching from English to Chinese any time soon — but this Q&A session is a gesture. It’s recognition of a user base outside of the English-speaking world, a clear message from the CEO of a major tech company that he cares about speakers of other languages.

As a linguaphile I find it incredibly heartening to see what Zuckerberg did in this session, although I don’t expect every CEO to start speaking other languages. It takes a lot of time and dedication to learn a new language, and Zuckerberg has personal motivation — his wife’s family speaks Chinese. (I understand that motivation!)

What matters are the resources, attention, and energy that are invested in making the web a better place — for everyone.