State machines
A state machine is an abstract model for representing different states and the transitions between them. It tends to have various inputs that trigger something to pass from one state to another and then produce various outputs. A simple example is a button on a lamp: when you press it (that’s the input), if its state is ON then it will turn off, and if its state is OFF then it will transition to ON. Understanding state machines is the basis for most computer programming — what’s known as “procedural” programming is structured specifically around the steps a program takes to reach a state, whereas “object-oriented” and “functional” programming still deal with state but treat it a little differently. Computer programmers aren’t the only ones who work with state machines though, as I’ve learned from working at a restaurant.
At work, the cold station (Garde 1) is the simplest state machine, which is why newcomers tend to start out on it. The only real events that you listen to there are instructions like “2 regular, 1 vegan tomato,” or “2 regular, 1 vegan caviar,” which contains all the information you need to produce the tomato cake dish or the seaweed caviar dish. These instructions sometimes come in quickly, one right on top of the other, so you have to remember what to do. You can think of it as a queue of tasks that must be processed asynchronously, or you can maintain a mental count of total vegan tomato (1) and total regular tomato (2) and when you hear a new instruction like “1 and 1 tomato,” you just update those total counts: vegan tomato (2) and regular tomato (3). (For some reason, kitchens use the phrase “all day” to mean total count needed. So that’s 2 vegan tomatoes all day and 3 regular tomatoes.) You subtract from your all-day counts when you finish dishes and set them on the pass, where a runner will pick them up and take them to the guests. The only other bit of state required is that for most of the night, you want to keep a certain number of caviar tops ready and tomato cake pieces iced. Let’s say you want to have 10 of each of those at all times until 9:00pm, at which point the velocity of orders drops so you only want 4 ready. You can extract that number from Amanda-Lee, the expeditor, or you can start to get a feel for it by looking at the spread of covers (the list of reservations over time). By “starting to get a feel for it,” you’re probably devising an algorithm that would be somewhat complex to write out. Generally, though, this station doesn’t require holding a lot of state, so your working memory isn’t overloaded.
On Hot 2 (the mushroom and beets station), the state is represented literally on the ticket holder, a long stainless steel strip into which you can stick the paper tickets. There are two pieces of tape on the strip, the one on the right representing mushrooms and the one on the left representing beets. When a new ticket comes in, it’s placed on the furthest right side of the strip. In programming, you might say that a new object has been created, with an ID (Table 103), a vegan-count (1), and a regular-count (2). Its next input event is when Amanda-Lee calls “Pre-fire 103.” You slide the ticket just to the right of the mushroom-tape, meaning that the ticket is now in mushroom pre-fire state. The procedure that state transition triggers is for you to add up the vegan-count and regular-count (3), multiply that by the number of rings per mushroom-dish (3), and place the total number of rings (9) into the batter. On the next input, “Fire 103,” you slide the ticket just to left of the mushroom-tape. That state transition means you will dump all the rings into the deep-fryer, prepare the total-count (3) plates, and then finish each one off with the fried mushroom and garnishes. (The mushroom dish is vegan, which is why we can deal with the total-count, rather than vegan-count and regular-count.) You push the ticket along to the limbo state between the two pieces of tape.
The next event is when the carrots-crudo station calls “Walked 103,” which means carrots have gone out. (This is a rare example of what would be called a “side-effect” in a computer program — one section’s event having an effect on another section). You slide the ticket to the right of the beet-tape to indicate that it’s in beet pre-fire state, then take the total-count (3) number of beets, douse them in oil, and pop them in the oven for 7 minutes. You also prepare the vegan-count (1) plate, with only vegan sauces, and the regular-count (2) plate with the non-vegan sauces. The next event, “103 is fired” (slide the ticket to the left of the tape) can happen a variable time after the previous event, so there’s another detail in there. If the beets have come out of the oven so long ago that they’re cold, they need to go back in the oven for a couple minutes. In programming, you would set a timeout after the beets are out of the oven, and when the time window is up, the beets would switch from a “hot” to “cool” state, which would tell you that they needed to be reheated. Regardless, you next multiply the total-count (3) by the number of chickpea fries per order (9) and dump that many (27) fries into the deep-fryer. You put the hot beets onto their plates, garnish them, add the fries when they’re ready, and then they’re ready to go out. You crumple up the ticket and throw it in the trash so that you don’t get confused by it, and because the ticket holder has a limited amount of space (i.e. memory in a computer program).
The Hot station ultimately is easy, though, when compared to the job of Amanda-Lee, the expeditor. She represents the global state of the whole program. Where Garde 1 and Hot 2 are discrete pieces of logic that are linked together only by listening to the same set of commands, Amanda-Lee is the one absorbing all the raw events and then transforming them into instructions that can be carried out by the kitchen. The number of states she keeps track of is extensive and you can see it when you glance at her presiding over the pass with an array of tickets marked up in front of her. She has to know the internal state of every station, in case anything was missed, and when plates are brought up to the pass, she keeps track of who they’re going to. She needs to know how long it’s taking between courses for all the diners, and whether that has to do with the food taking a long time to make or the diners taking a long time to eat. Because she knows roughly what each station is preparing at a time, she can try to space out orders so that everyone has a more uniform flow of work. I’m not even sure how she keeps track of everything, but presumably she uses a system of notes on the tickets and a lot of internal timers.
As you can see by the amount of writing it takes to detail the tasks of making a meal — while ignoring some stations altogether and simplifying the rest — the kitchen would make a complex computer program. Creating a well-functioning system in the kitchen does seem to bear a lot of similarities to programming. Restaurant people already grasp the logic of programming best practices like “separation of concerns” (the mostly isolated stations) and “single-source of truth” (Amanda-Lee). Organization of anything, basically, is a problem of information flow, so it makes sense that we would all converge upon the same principles. Systems are systems, wherever they’re found.