The Toaster Parable

The tech industry has a problem that I refer to as the “the toaster problem,” which is of course, best illustrated by “the parable of the toaster”. Suppose you are in the break room and a new employee says “Hey, can you help me with the toaster?” You spend the next 10 minutes explaining how the various knobs and dials work. You say that this toaster uses photoelectric sensors to detect browning instead of a thermostat or a timer. You teach them that the little red bits inside the toaster are filaments that have electric current run through them and that’s why you shouldn’t stick a knife into the toaster while it is plugged in.

If the new employee were wondering “Hey, how does this fancy toaster work?” your explanation would be perfect. But if the employee was thinking “Hungry. Want toast.” they are probably hungrier than when they started, and they still don’t have toast. Of course, you were right to give them the full explanation of toasters. The new person will be safer understanding why they shouldn’t stick a fork into the toaster. Understanding that the toaster works on photoelectric sensors will help them understand why it works a bit differently on white bread versus brown. Since the new employee understands the toaster, they’ll be better equipped to debug toaster related issues in the future. But at the same time, most folks would say that you should have just shown them where the bread is kept and how to plug in the toaster.

The problem with the tech industry is that we often explain the details of toaster design to folks who just want a piece of toast. We give them tons of details and expect that they’ll learn all about how toasters work. From there they’ll be able to make perfect toast. That logic is sound, except some percentage of people are going to get annoyed, wander off, and just have another snack instead.

I don’t think giving the full explanation is a bad thing. This analogy came to me after a particularly frustrating meeting where the folks on the other side of the table kept asking “but how does it work,” and I kept replying “I don’t care, it just does.” I didn’t need to understand how the toaster worked to make toast, but the other folks did need that understanding. Our brains worked differently. Depending on context, we all fall somewhere on the “How do toasters work?” to “Hungry. Want toast.” continuum. To reach people on the other side of the toaster debate, I had to believe that understanding how toasters worked was important for them and then provide them the information they wanted. Understanding the opposite perspective is hard. I’m pretty biased toward “let’s just make toast” most of the time. After all, the failure cases for toast aren’t that bad. But the underlying tension of the toaster parable keeps coming up. No matter how many times I try to convince people they don’t need to understand the details some people truly do need that information. Whether you are a “toast, now” person or an “understanding the details” person seems to be at least partially a personality trait.

The big issue with the toaster problem is that the solutions to “Hungry. Want toast.” are different than the solutions to “How do toasters work?” Neither concern is better than the other. There are multiple great solutions to both issues. But if you try to provide a “How do toasters work?” solution to “Hungry. Want toast.” it won’t go particularly well.

So how does this apply to tech? Go look at the documentation for your favorite library, framework, or tool. Does it address “Hungry. Want toast.” or “How do toasters work?” Most of the documentation I’ve looked at skews one way or the other. Some companies are known for providing great “Hungry. Want toast.” documentation. Others are great at providing all the details about how the underlying technology works. Rightly or wrongly, many folks believe the SRE community is more on the “How does the toaster work?” end of the spectrum. Developers at startups often are on the “Hungry. Want toast.” end. If we want to help a wide group of people, we need to ensure we’re providing information from both of these perspectives.

Addressing the toaster problem is straightforward, but it takes work. The first step is to acknowledge that the other perspective exists and is just as valid as your own. There’s a tendency in technical communities to look down on folks who don’t want to understand the inner workings of their kernel and are just happy that the gnomes in their computer keep returning correct answers. This isn’t an issue of better. This isn’t an issue of one group having the right priorities. In my experience, this is an issue of different people’s brains working differently. So back away from the frustration and the judgment and try to see the other side. I’ll be doing the same.

Second, we need to look at our talks, our documentation, and our tutorials and make sure we aren’t only providing solutions to one of these problems. It is human nature to explain things in the way we’d want to learn them. Just looking at my blog I write a lot about “how to build things with " and very little about "how works." Once you've seen your bias, find ways to address it. You can try to create content from the other perspective, or if you are part of a team, you can find the folks on the team who tend the other way and use teamwork to achieve balance.

Finally, we need to be better at figuring out the perspective of our audience. Providing a detailed schematic for the toaster isn’t helpful to someone who is hungry and handing a piece of toast to someone who needs to understand the inner workings to be successful is frustrating. When we are giving advice, we can ask about someone’s goals to get a better idea what type of information to provide them. When we are giving conference talks, we can use the abstract to help folks understand which problems we’ll be addressing. And we can use the introductions to blog posts, documentation, and tutorials to help people figure out if this content will address their current issue. It may take a couple more minutes and some awkward perspective shifting but by considering the toaster problem I’ve reduced conflict in design discussions and had more success reaching a wide audience.

Have you run into the toaster problem in your work? I’d love to hear about it.