Most people thought I was crazy for doing this, but I spent the last few months of my gap year working as a short order cook at a family-owned fast-food restaurant. (More on this here.) I’m a programmer by trade, so I enjoyed thinking about the restaurant’s systems from a programmer’s point of view. Here’s some thoughts about two such systems.

Double, triple, and even quadruple fetching

Human systems, at first glance, can appear broken, but due to subtle human factors, they might actually work just fine.

My best example is the system for taking and fulfilling orders. We never wrote anything down, and would re-ask orders multiples times, including when ringing customers up. (In computer security, this is known as a double fetch.) Not great service and can theoretically let customers lie and pay less.

In practice most customers didn’t mind too much, liars are rare, and we can loosely detect when something seems off with an order.

Writing orders down and asking strictly once seems optimal but has subtle flaws. For one thing, there’s not enough space behind the counter for everyone to walk to the written order, so it requires more internal communication. This will fail during a rush when you’re blocked on order details and coworkers are too busy for questions. Customers are always idle; coworkers aren’t.

It can increase confusion if order slips aren’t thrown out when orders are finished and is also logistically (and literally) messy if you have greasy gloves and want to avoid touching a pen, then food. Lastly, many of my coworkers were older and very used to the existing system. A major transition to a new system would have generated more confusion than it’s worth.

Scheduling algorithms for the fry cook

While I covered a range of duties including the cash register, milkshake machine, and grill, I spent the most time on the deep fryer. I’m delighted to present this overanalysis of life as a fry cook, from a programmer’s point of view.

This is what deep fryers look like (source):

This picture has 2 fryers, each with 2 baskets that can be submerged to sit in the vats of hot oil below. At work, only 1 fryer would be active on any given day which effectively allows 2 items to be fried at the same time.

Fry cooks have a lot in common with operating systems in that they are both responsible for scheduling. Operating systems schedule threads to run on a limited number of cores; fry cooks schedule food to be fried in a limited number of fryers. Different food items have different priorities, and different lengths of time to cook.

French fries, curly fries, and onion rings (collectively, “fries”) are the main menu items from the deep fryer. Each fry order could be large or small (except for rings which were only large) and eat-in or to-go. The job of the fry cook is to:

• Accept fry orders from the greeter.
• Allocate portions of fries from the big bags of raw fries
• Cook them in the fryers
• Put them into the appropriate eat-in/to-go container
• Serve them onto the customer’s tray on the counter, or their to-go bag

The goal is to do this with maximum speed and accuracy and without dropping orders. You’ll ideally minimize the number of times you ask customers and coworkers for order details. In addition, there are a few sources of complexity to handle:

• Incomplete information: Depending on the greeter, they may forget to specify if it’s eat-in or to-go. You can always ask the customer, but the grill chef will likely ask the same question in a little bit. You might be able to save a customer ask if you can eavesdrop on that interaction.
• Timing requirements: You need to finish orders by the time the grill chef finishes the burgers/hot dogs, but you shouldn’t finish too early. If you put the fries on the counter way before the burgers are ready, they’ll get cold. This matters less for to-go orders, which you can serve into the bag immediately.
• Scale: During a rush, you might receive many orders per minute, while only being able to process 1-2 per minute. Once the greeter relays the order, they forget it, so it’s up to you to remember. And remember: no writing things down.
• Waste avoidance: Sometimes you or another cook will make too many fries. To avoid wasting them, you can use the excess towards a future order by refreshing them with a splash later and adding them to a fresh batch.
• Changing orders: Customers sometimes change their order after you’ve started cooking (e.g. regular fry to curly fry). Now you have to figure out what to do with the partially cooked portion currently in the fryer.
• Misc items: In addition to fries, there other items that need to be scheduled for time in the fryer, including chicken patties, bacon, clam strips, and fish fillets.

A few techniques to manage all this:

• Batching orders together. If a large and small fry order are in the queue, you can cook them in the same basket at the same time.
  • Some customers request their fries “well done”, meaning cooked extra long. This makes batching more complicated.
• “Wait n Splash”: If a fry order is done cooking far before the rest of the grill items and you don’t have pressing items that need fryer time, you can raise the basket from the oil, but leave the food in it. When the grill items finish, you can quickly splash the food back in the oil to refresh it, then serve it. This will prevent it from getting cold on the counter.
• Inactive fryer baskets: It can be handy to have extra storage space for cooked food. If you have a “wait n splash” order waiting, but you have more orders to fry, you can use the 2 spare baskets from the inactive fryer to store the waiting order and free up the fryer slot. This is also useful when customers change their order and you need to quickly stash the half cooked portion somewhere and start the adjusted order.
• “The tong dip”: If both fryers are in use and the grill chef hands you bacon to be urgently cooked, you can hold the bacon in tongs and dip it into one of the submerged baskets. This lets you effectively cook more than 2 things at the same time.

Here’s the system I ended up using. When a new order came in, I’d stop whatever I was doing and grab the appropriate container and place it in the corresponding fry bucket. This captures all 3 pieces of information about the order (fry type, size, to-go?) letting me forget it. If I strictly follow this, I can just process the containers in the buckets like a queue. However, I still need to keep a sense of order memorized because the system doesn’t capture global ordering – if I have containers in the fry, curly fry, and onion ring buckets, I can’t tell which order came in first.

I don’t have a solution for this. On a super busy day, this system falls apart and I drop orders. Extreme load like that has only happened a few times and in that case, I just make large batches, forget about syncing up with the grill items, and hope I don’t have too much excess at the end. Generally, the system worked nicely.

Conclusion

It’s fun to think about human systems, like those in a restaurant, from a programmer’s point of view. A fry cook’s job closely resembles that of an operating system scheduler, complete with optimization points and edge cases. One can try to optimize human systems as if they were computer systems, but it’s critical to understand the subtle human aspects of the system when evaluating improvements.