A programmer saying they love coffee must be a cliché at this point, but I am guilty as charged: I love coffee.
As Ireland started to ease its lockdown and things are opening up, I finally had a chance to take a barista course. That was something I’d wanted to do for many years.
After gaining insight into the processes that happen at a coffee shop, I couldn’t help but trace parallels to what we do as software engineers. That’s what I want to talk about today.
Prep work
We started our session going over what needs to happen before you start making coffee.
You start by calibrating the grinders, trying to find the coarseness that will let you pull an espresso shot to perfect. Once you have it, you move to to set the grinders with the correct timing to give you the right amount of coffee for a double shot.
Skip all that and you’ll get (at best) subpar coffee that won’t make your customers happy.
I find this similar to the work we do before embarking on a project. Gathering the requirements, sketching out what the system should look like, defining service-level indicators (SLIs) and objectives (SLOs), etc, are all part of the prep work we do as engineers.
Planning before starting the work enables us to assess the risks and put our projects in a better position to succeed.
Balance
After we learn about the prep work, our instructor went over the espresso brewing process. If you brew it for too short a period, the coffee comes out too acidic. Brew it for too long and it comes out too bitter. There’s a fine balance between those two extremes that gives you perfect coffee.
The same applies to software.
If you under-engineer a system, you might find yourself in trouble when requirements change or demand increases. The lack of planning will result in pain points when it’s time to make the project scale.
On the other hand, an over-engineered system can become a nightmare to understand and maintain. Changes become difficult and sometimes (most of the time?) lead to unexpected results.
Finding balance is not easy, but it’s needed to achieve great software.
Clean up
One of the things our instructor mentioned was clean up.
As you go about making lattes, spillage will happen. Too much of that and your workspace becomes a mess, you become less effective at preparing the orders and everything feels terrible.
That’s why clean up is important. From time to time, he said, you have to stop and clean up the area so you can keep working.
I relate this to what we call tech debt in software development. As projects go on and deadlines grow tighter, we cut corners and sometimes make poor decisions that leave our code base in a bad state.
Tech debt is not inherently bad. Just like a coffee shop has to accept some untidiness to get the orders going, so does software development. Sometimes it’s needed and the right thing to do.
That untidiness only becomes a real problem when we take too long to clean it up. When the debt is not repaid, work becomes difficult. Tasks that should be simple take longer to complete.
Just like the coffee shop needs periodic cleaning, so do our code bases.
Conclusion
Although this posts draws parallels to software engineering topics, I’m sure you can see similarities to other areas as well.
I hope you found this post interesting, and that it helped you stop and think deeper about our craft. Or, if anything, I hope it makes you appreciate the work that’s put into your lattes a bit more!
Top comments (0)