The other day I was in a 1-1 with an awesome mentee and the topic of Kool-Aid came up. I said, not everyone who gives out Kool-Aid drinks it, sometimes people just make it for others. Then I went in a design review for another team and when we left our product manager said “I hate cookie lickers”. It was a great summary to the problem, that team has been talking about the same thing for at least 3 years so no one had done anything. I ended the day in a design review for a component in our team and I asked the engineer, why are you redesigning the wheel? He is a smart engineer that just got lost in the details, but a simple phrase got us back on track. After the third idiom in a given a day, I realized just how silly some of our phrases are.

Idioms refer to concise and widely recognized expressions that convey complex concepts or patterns in a compact and easily understandable manner. They serve as powerful communication tools, allowing us to convey intricate ideas or approaches succinctly, without the need for lengthy explanations. Here are my top 10 idioms that we use in software engineering.

• Cookie licking: This idiom refers to the act of saying that you will do something so that others do not do it. For example, when you lick a cookie and put it back on the plate so that others do not want to eat it. Some teams will claim they are going to do a project so that others do not do something, but then never actually do it.
• Bike shedding: This idiom describes the tendency to focus on trivial or minor details while neglecting more important or complex issues. It originates from a story where a committee spent an inordinate amount of time discussing the design of a bike shed, ignoring the more significant design of the nuclear reactor. You will see this is some design reviews where people will spend more time debating trivial details like which compute engine to use instead of focusing on the complex algorithm.
• Boiling the ocean: This phrase describes attempting to solve a complex problem or achieve an overly ambitious goal that is practically impossible or requires an unrealistic amount of effort. For instance, trying to rewrite an entire legacy system from scratch could be considered “boiling the ocean.”
• Yak shaving: This idiom refers to the process of completing a series of seemingly unrelated tasks to accomplish a larger goal. It originated from a programmer’s joke about having to shave a yak to get some work done. This frequently happens to me when I am oncall. I go to write a simple block of code in a legacy codebase, but then I need to deploy the code but deployments are broken, so I go to fix the deployment, but I cant deploy because the ops tool is outdated, but I can’t fix the ops tool until I upgrade a deprecated dependency, but the upgrade is not backwards compatible, … you know how this goes.
• Lipstick on a pig: This phrase is used to describe attempts to cosmetically improve or enhance something that is fundamentally flawed or problematic. For example, adding a modern user interface to a poorly designed application would be considered “putting lipstick on a pig.” I see this sometimes when teams who forget who their customers are, which is part of why amazon recommends working backwards. I watched a team completely rewrite their UX 3 times blaming the adoption on the poor UX(s), rather than asking customers what was wrong (hint - it wasn’t the UX).
• Eating your own dog food: This idiom refers to the practice of using the products or tools that a company develops internally. It encourages developers to be users of their own software, which can help identify and address issues before releasing to customers. Amazon loves to eat its own dog food, that’s a large part of how AWS is/was built - so it works.
• Low-hanging fruit: This phrase is used to describe tasks or problems that are easy to solve or implement, often providing quick wins or early gains. Addressing low-hanging fruit can be a good starting point before tackling more complex challenges.
• Reinvent the wheel: This idiom refers to the unnecessary duplication of effort by recreating something that already exists, instead of utilizing existing solutions or libraries. It cautions against wasting time and resources on problems that have already been solved. I will note this isn’t always negative, sometimes it stems from our inclinations to learn and be curious and dive deep. I can’t tell you the number of times I have written a really complex block of code only to look at it in a CR and say “there is a standard library function for that - I am stupid”.
• Drinking the Kool-Aid: This phrase is used to describe someone who has become an ardent follower or believer in a particular technology, methodology, or philosophy, often to an extreme or irrational degree. Kool-Aid is good because it helps build common ground and culture. When people stop looking at data and stop delivering value losing sight of reality, that’s when too much Kool-Aid becomes a bad thing.
• Shooting the messenger: This idiom refers to the act of blaming or attacking the person who delivers bad news or highlights a problem, instead of addressing the issue itself. You commonly see people who are hesitant to point out defects or design flaws in a system or in a design review because they do not want to face backlash or “lose trust” with those people.