I have been working as a software engineer for just over five years. Every now and then I encounter a phrase used to describe something during an engineering discussion, where its meaning is not obvious from the words themselves. These kinds of phrases are known as idioms - expressions that have a non-literal meaning attached to the phrase. “Break a leg” is a well-known idiom to wish a person good luck.
Usually, I say nothing and pretend I know what it means, or quickly look up the meaning if I am by my computer. I talked to a few other engineers and asked them if they had heard of some of these phrases - and they didn’t. I imagine there are many more of you out there. I decided to collect all of the idioms that I have come across in my job to share them with you along with a simple explanation.
Have I missed any? Let me know in the comments below.
Bikeshedding, or the Law of Triviality, describes our tendency to devote a disproportionate amount of our time to trivial topics. For example, a team might devote the majority of their time debating what colour a button on their website should be, rather than discussing what front-end framework best fits their needs.
Dogfooding, or Eating your own dog food is the practice of using your own products and projects internally. This is a good practice if you are able to do it as it means you are able to continuously validate that the product is functioning correctly. It can help to identify bugs, usability or feature gaps before being made available to your paying customers.
Boil the ocean
To “boil the ocean” is when someone tries to undertake a project or task which would be almost impossible to complete.
Rubber duck debugging
Rubber duck debugging is an analog method of code debugging, where an engineer would articulate a problem using natural human language, either spoken or written. Using an inanimate object such as a rubber duck can help with this method by providing an imaginary listener of the problem. The very act of speaking about the problem can help the engineer to identify the cause of the problem.
Drinking the Kool-Aid
When someone “drinks the Kool-Aid”, it means that they have heavily bought into something, sometimes ignoring the arguments against the thing. The “thing” is often a company or its leader, but is sometimes used when referring to software languages, frameworks or methodologies.
Skunkworks refers to a project that involves a specialist team working autonomously on an advanced or secret project, primarily for the sake of rapid innovation.
Yak shaving is when you start a task but end up having to complete a number of other tasks before you are able to complete the original task.
Technical debt is the implied cost of reworking an existing codebase or system. It is often incurred as a result of taking a quick and easy option now instead of a creating a better solution which would take longer.
The bus factor of a project is the number equal to the number of team members who, if run over by a bus, would put the project in jeopardy. If a project overly relies on the contributions or knowledge of one person, then you could say that the project’s bus factor is one.
A code smell is when any characteristic of a piece of code may be caused by a deeper problem within the system or architecture. A common code smell is a bloater, where a piece of code, which could be a component, class or method has increased to an undesirable size.