Code Specialization - Lessons from restaurants in Turkey

Living in different places is a great way to rethink and compare the processes that are around you. I recently returned to the US after about 3 years of living in Ankara, Turkey.

In the US, going out to a restaurant typically follows this flow:

• The party of diners is seated. The servers quickly checks in on those seated for any appetizers or drinks that can get started.

• The diners wait a few minutes for those drinks and appetizers to come. They look at the menu and everyone decides on something.

• The server takes the order. A group of cooks in the kitchen scramble to make everyone’s different dishes. The cooks have to quickly make a plan so that everything is ready at approximately the same time. The diners wait and talk.

• Food comes out. The servers check for additional drinks and repeat the same process for any desserts.

In Turkey, most restaurants are much more streamlined and can handle far more diners over time. The tradeoff is that menus are much smaller, but in my opinion, the experience and pricing is much better. The experience over there generally follows this flow:

• The diners sit down. A standard set of appetizers are brought to table as people are getting seated. Water bottles are already at the table.

• As soon as people are seated, they can start taking orders. The main question is generally “How many portions?” or “How many grams of meat?”.

• The food comes quickly, and there never is a waiting period where the dinners don’t have food or drink.

The video above shows one of my favorite liver places in Ankara. Yes, this big and busy place specializes in liver kebab. If you go there, there is probably a 95% chance that this will be part of your order. They have a few large locations, and they are almost always busy. The quality is consistently great and they can efficiently handle the large lines of people that show up. If you stop by with a party of 20, it is normally takes just a few minutes to get a few tables put together to get everyone seated.

I am an engineer so naturally I ask myself, “What produces the better outcome?”.

In my point of view, I much prefer the Turkish model. I think you get better foods at a better price in far less time. The people at these places specialize in their part of the process, and gain a massive amount of experience quickly. The person who is responsible for assembling hundreds of chicken skewers per day will get quick feedback from the people downstream of them who have experience cooking and serving that massive volume of chicken. The servers there had so much experience, they seemed to be able to read my mind after a few times there.

I regularly ask my friends who write could, “What would be your ideal software role?”.

Younger devs tend to value gaining experience in different functions. But does this produce the best outcome?

I think about past roles, where I have been asked to rapidly learn something or to take a sprint or two in order to help another team. My ability to quickly learn and understand things made me a target for these kinds of tasks.

In one of my roles, I was asked to write a bunch of Terraform and Kubernetes code in addition to my main tasks. This took me weeks to get up to speed and probably a month to produce something that a specialist could do in days. In hindsight, this was probably a massive waste of everyone’s time, and it pulled my focus away from the specialized signal processing that I was hired to work on (which was core to that business).

For a startup that is rapidly trying to prove the point of its existence, this kind of mistake could be existential if repeated with a few of the engineers.

Working in the somewhat nebulous “data science” space, a frequent question I ask is “build or buy?”

There is so much tooling that the last few years of funding have produced, that it is often far more effective to buy. In recent roles, I have found myself evaluating tools far more often than actually writing them.

I also gained an increased appreciation for specialists. If I were faced with the need to manage infrastructure with Terraform again, I would immediately reach out to someone like Anton, who has worked with that tool daily for years and already knows the best practices, than try to do it myself.

This is something I saw On Deck do very effectively in my time with them. They quickly hired specialized contractors to do very specific things. Rather than try to write and manage a bunch of data connectors in-house, they found tools like FiveTran, RudderStack and HighTouch to handle that. This may have had more upfront costs, but it put the burden of technical debt on those specialists, and allowed the engineers to focus on the bigger picture.

At first, I felt a bit apprehensive about using these tools. I had been contracted a few times to build these things, and now we were just buying them? I had mostly moved out of the “data science” type roles, thinking that I had much more fun writing the infrastructure that took these to scale. It was uncomfortable to think that the niche where I thought I worked best could be disappearing, but it made me step back and ask myself again “What would be your ideal software role?” and is it really gluing together a bunch of configuration code?

This industry is changing quickly, and for those who see themselves as engineers, I encourage you to regularly ask yourselves, “Does this produce the best outcome given what we have?”. As a young engineer, it is tempting to defer these questions to the manager, CTO, etc, but after experiencing a few rounds of layoffs, it becomes clear that this in another responsibility for people in the field. Plus, if you do your own retrospectives regularly, it makes doing it with your managers much easier.