Mental models. If you've followed this podcast for a while, you know, I'm kind of big on mental models. I believe Shane Parrish of Farnam Street coined the term "latticework of mental models" to describe the ability to utilize analytical frames from multiple disciplines. That's the simplest way I can put it.
Well, when most people think about mental models, they're really thinking about economics, physics, philosophy, stuff like that. Nerds. Anyway, you don't have to read 50 books a year to accumulate mental models. If you have an open mind, mental models can be found in the most unlikely places. Case in point: how many of you have heard of Takeru Kobayashi? In 2001, Kobayashi stunned the world by winning Nathan's Coney Island hot dog eating contest, probably the most prestigious eating contest in the world. Kobayashi ate 50 hotdogs in 12 minutes, doubling the previous record of 25. This at a body weight of about 130 pounds. Kobayashi absolutely demolished the competition. And he made a bunch of corn-fed behemoths look like amateurs. It was amazing.
The first time I saw Kobayashi eating hotdogs, I was transfixed. I remember thinking to myself, wait a minute, this guy is better at his job than I am at mine. He literally doubled the throughput of the previous record holder. If I could double the throughput of my dev team, I would be walking on water. Well, easier said than done. Now. I know some of you out there might resist the idea that software projects are equivalent to a hot dog eating contest. You're probably thinking, hot dog eating contests are grotesque and undignified rituals of institutionalized humiliation. Nothing could be further from...Oh, wait. Yeah.
As Herman Hessler once said, he had very few doubts, and when the facts contradicted his views on life, he shut his eyes in disapproval. Well, if you're ready to open your eyes, let's go a little deeper into Kobayashi's eating technique. At the start of the contest, everyone is staring at a gigantic tray of hotdogs, and all contestants have the exact same challenge. The mountain of hotdogs represents the work you have to do. Your esophagus represents your capacity. The problem you need to solve is how to optimize your capacity, given specific resource constraints. Framed that way, a hot dog eating contest is notionally identical to a software project, it's the same thing. What most hot dog eaters do in the contest is what most techies do on a project. They take an entire hot dog, bun and all, stick one and in their mouth, chew, chew, chew, chew, chew, swallow, and so on.
Now, when you work this way, the only way to increase velocity is to chew faster. Well, what happens when you chew faster? If the hot dog isn't broken up enough, by the time it hits your esophagus, it's likely to get stuck. When that happens, you have a blocker and subsequent work backs up until the first bit of hot dog becomes dislodged. How do you dislodge the hot dog? Well, you have to gulp water. But that just fills you up and makes it harder to eat more hotdogs. Is this starting to sound familiar? Substitute "story" for "hot dog" and I just described 80% of all software builds.
The mountain of user stories represents the work. Your team is your capacity. The problem you need to solve is how to optimize your capacity given specific resource constraints. It's the same thing. So let's take a look at how Kobayashi solves resource constraints. First, Kobayashi takes the hot dog out of the bun then he breaks it in half, using two hands, he then sticks the hot dog pieces into either side of his mouth and chews away until it's time for another. So by breaking the hot dog in half, he doubles the impact of each bite. Because now both sides of the jaw are involved in the work. If you stick just one end of a hotdog into your mouth, only one side of your jaw is chewing, so you would have to chew at least twice as fast to match Kobayashi's work rate.
But wait, you ask? What about the bun? You have to eat the bun? Well, yes, but there's no rule saying you have to eat the bun with the dog. Here's what Kobayashi does. He tears the bun into pieces and dunks the pieces in water so that they'll be easier to swallow. Then he basically slurps up the soggy hotdog buns, essentially drinking them down at a ferocious clip. It's incredible.
Kobayashi wins because he's an expert batcher. He's excellent at batching. He's not an impressive physical specimen. He's not the biggest or the most powerful or the most aggressive or anything like that. He wins because he's better at batching.
Can it really be so simple? Well, let's bring this back to tech. I challenge anyone to show me any job posting in tech anywhere that requires batching as a requirement of the job. Instead, companies want to see five years of Java or eight years of React or whatever. Dude, you could be Dan Abrams or Josh Bloch. If you're on a team with poorly patched batched work, you will fail. It really does not matter how smart you are, or how good you are with the tech, or even how hard you work. If you don't understand how to batch the work properly, blockers will jam your pipe and your project will grind to a halt.
Unfortunately, very few people know how to batch software work well. In the last couple of decades, I've worked with maybe four people who are really good at it. And guess what my projects with those people were smooth like butter. We won and made it look easy. But experiences like that are an anomaly. Usually, you get the other kind of project, the kind of project where everyone tries to frantically stuff in tech type bogs down their guts until everyone is joking and miserable.
Well, batching is an incredibly deep topic, I couldn't possibly do it justice in an eight-minute podcast. So I'll try to break it down for you and give you some general ideas to think about. When you take on a big software project, you are presented with a vision, an intact and coherent whole. But if you look closely, there are seams. The seams are where you can dis-integrate the work into little batches that can flow through the pipes without getting stuck. Some examples of software seams would be layering, or API contracts, or component boundaries, or dependency models. When you assemble software, you sew it together at these seams. And if you understand the seams, it's so much easier to take the thing apart and put it back together when you need to.
So this is kind of basic stuff. Why does everyone suck at it? I have a theory. Batching is something that you do to make other people successful. It's essentially an act of servant leadership. How many servant leaders do you work with? Yeah. In a typical institutional setting, you don't rise in the ranks by making other people successful. Someday that may change. Until then, just remember, break the hot dog in half.
I'm hiring software engineers! Check out the jobs page to see my open positions.