What a Systems Programmer Learned from Working at a Fast-Food Restaurant

It’s that time of year when we look back and take stock of ourselves, our industry, and of all those moments in the year passing by. And programmer Mark Mossberg has a wonderful tale to tell…

“I used to work in the infosec industry, where I worked on emulators, operating systems, and compilers, reverse engineered binaries, and wrote exploits,” Mossberg explains on his blog. But this year he’d decided to take some time off, spending the year contributing to the Linux kernel and the LLDB debugger (and also recording some music.) And the last few months also included a part-time job as a short-order cook at a local restaurant. He’d always wondered what it would be like, and this year off provided the perfect opportunity to find out.

He’d titled a post about the experience “Double fetches, scheduling algorithms, and onion rings,” and Mossberg seemed to welcome this chance to stretch his skills in a different direction, gamely tackling whatever new and unforeseen challenges arose along the way.

Soon he’d learned that he wasn’t the only IT worker with some fond affection for the lessons learned from working in the fast-food industry…

Operating Systems

“I’m delighted to present this overanalysis of life as a fry cook, from a programmer’s point of view,” Mossberg wrote. The job had also required working the milkshake machine and the cash register, but most of his time involved the deep fryer, where he prepared everything from French Fries, onion rings, and curly fries to bacon, chicken patties, and the fish fillets and clam strips.

Mossberg soon discovered what fry cooks have in common with an operating system: they’re in charge of 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.”

Just keeping track of incoming “requests” presented a challenge. Orders could be different sizes — and would also require different containers if they were to-go orders. But thinking adroitly, Mossberg soon discovered he could capture all that information — along with the order itself — just by grabbing the appropriately-sized container that uniquely corresponded to it.

In fact, Mossberg ultimately discovered that the restaurant staff never wrote down their orders. And yes, this sometimes meant asking again — especially when settling the bill. But it turns out their customers didn’t mind, problems were rare, and basic common sense prevailed so that “we can loosely detect when something seems off with an order.” Whereas passing around the single written copy of an order presented its own challenges, including stale information, greasy fingers, and even the issue of accessing this “documentation” in a cramped workspace during the lunchtime rush.

But the final concern was something anyone in IT can relate to: “A major transition to a new system would have generated more confusion than it’s worth.”

This led Mossberg to his first lesson. “Human systems, at first glance, can appear broken, but due to subtle human factors, they might actually work just fine.” Mossberg explained his thought in a tweet summarizing his key takeaways from the experience.

• “The real world has subtle complexity that prevents human systems from being evaluated like computer systems.
• “There’s a surprising amount of nuance & complexity behind ‘low skilled’ work like a deep-fry cook.”

Switching Contexts

But there was another lesson to be learned. From 11 a.m. until 4 p.m., Mossberg dutifully handled his shift — and discovered it still managed to dominate his entire day. “There wasn’t much time for project work in the morning and by the time I got home, physical exhaustion made it difficult to context switch into programming, blogging, or making music.” And even his off-day between shifts still suffered from the additional challenge of context switching. “There wasn’t enough time to shift back into deep work. So 10 hours of work translated in practice to three less days per week for project work.”

On the plus side: Fridays felt great. Whereas before most weeks had been a seven-day blur with “little distinction between weekend and weekday… Since it all mushes together, Mondays hurt less but Fridays bring less relief.” There was another lesson to be learned there as well: “a small amount of external pressure can make you appreciate your free time more, and use it better.”

It turns out he’s not the only IT worker who’s gained valuable experiences from their time in the food-service industry. Earlier this month a self-described Unix Mercenary/DevOps/InfoSec Dominatrix remembered on Twitter that “We once hired a former barista in our #DevOps team.

“Our dept always had epic coffee.”

This kicked off a much larger discussion about the many non-traditional paths that lead into a career in IT, as Microsoft senior cloud advocate Chloe Condon applauded the tweet, and others joined in with their own personal stories. David Brunelle, the VP of engineering at Starbucks, remembered that he’d also started out as a barista. And tech CEO Andrea Gatley also tweeted “Not gonna lie, I’ve done the barista thing. It can be really fun.”

“One of our techs is a former baker. One we inherited from an acquisition when he was a high school student. Both of them are amazing.”

The inspiring stories kept coming, like a minor Christmas miracle. Senior gameplay programmer Nikky Armstrong remembered that “For 18 months I worked as a barista, in an airport, at 3 a.m. The question was whether a programmer could hack it as a barista, not the other way around.”

WebReduce

• A poet’s perspective on programming.
• Rediscovered video shows everything you needed to know about the internet — in 1996.
• Non-profit hopes to improve the world through role-playing games.
• Authors of a new book discuss innovation vs. “the work that matters most”.