🧠 10 engineering terms that will make you think like a senior
Bridge the gap between junior & senior engineers. Learn 10 key terms for anti-patterns and pitfalls to avoid costly project and code mistakes
What separates a senior engineer from a junior one?
It isn’t just knowing more frameworks or algorithms. It’s having a mental library of mistakes to avoid. They've seen many ways projects fail, and they know what causes them to fail.
They’ve given names to those scenarios, but most engineers still don’t know this unique vocabulary. Those who learn these terms can describe common pitfalls and anti-patterns to avoid them.
Instead of learning these lessons the hard way, you can learn to recognize them by name. Let’s explore 10 more concepts that will help you think, communicate, and build like a seasoned developer.
🪤 #1 Footgun
A footgun is a feature that makes it too easy for users or developers to shoot themselves in the foot.
Why it matters: Dangerous defaults or overly flexible tools can cause big mistakes fast.
Practical explanation: A CLI deletes production data by default unless you pass a --safe flag.
Strong defaults and guardrails are needed to protect teams from themselves.
💀 #2 Death by a thousand cuts
Death by a thousand cuts is when many small issues add up to a big problem.
Why it matters: Minor inefficiencies accumulate into serious drag.
Practical explanation: Each test takes 1 second longer than needed, each deploy takes 30 seconds longer, and each bug takes a few minutes extra to investigate.
The compound effect eats into time and morale.
🧠 #3 Bike-shedding
Bike-shedding is wasting time on trivial details instead of important issues.
Why it matters: Teams avoid the hard work by focusing on irrelevant things.
Practical explanation: A meeting spends 40 minutes debating button colors and skips the actual data model discussion.
This kills momentum. It distracts from core problems.
🪵 #4 God object
A god object is a class or module that tries to do everything and knows too much.
Why it matters: It creates tight coupling and is hard to test or change.
Practical explanation: A UserManager handles login, billing, notifications, and analytics in a single file.
God objects block flexibility. They lead to bugs from unintended interactions.
💧 #5 Leaky abstraction
A leaky abstraction is when internal details of a system bleed through its interface.
Why it matters: It forces users to understand lower layers they shouldn’t need to.
Practical explanation: An ORM crashes on certain queries because it leaks SQL syntax into business logic.
Abstractions must hide complexity to save time. If they leak, they fail.
🪛 #6 Inner-platform effect
The inner-platform effect is when a system tries to recreate the functionality of the platform it's built on.
Why it matters: It adds complexity with little benefit and creates bugs the platform already solved.
Practical explanation: A CMS adds its own templating language that reimplements conditionals, loops, and variables.
Reinventing wheels distracts from delivering value.
🧊 #7 Stovepipe system
A stovepipe system is built in isolation and doesn’t integrate well with other parts.
Why it matters: It leads to duplication, missed opportunities for reuse, and poor user experience.
Practical explanation: Two teams build their own notification systems with separate APIs, UIs, and storage.
Integration becomes harder over time. It slows product development.
⛓ #8 Temporal coupling
Temporal coupling is when parts of code must be changed together because of hidden dependencies.
Why it matters: It slows development and increases the risk of bugs.
Practical explanation: A config file must be updated every time a related script changes or things break.
Decoupling logic and reducing shared state improves team velocity and confidence.
🕳 #9 Tarpit project
A tarpit project looks simple at first but becomes complex and never-ending.
Why it matters: These projects suck in resources and never ship.
Practical explanation: A team thinks building an email client will take two months. A year later, threading, spam filtering, and rich formatting still don’t work.
Recognizing tarpit traps early lets teams avoid wasted effort.
🧱 #10 Broken window theory
Broken window theory says that if we neglect things at code review, more neglect comes over time.
Why it matters: If one part of a codebase is messy, others are more likely to stay messy or get worse.
Practical explanation: A few missing tests or TODOs cause later developers to ignore structure and copy bad patterns.
Teams should fix visible issues early to set quality standards and encourage care.
🎯 Conclusion
Engineering is more than just building features; it’s about recognizing patterns of decay before they take root.
By internalizing this vocabulary, you equip yourself to move beyond just writing code and become the person who can identify risks, articulate problems clearly, and guide your team toward building more resilient, maintainable software.
How many of these anti-patterns have you encountered in the wild?
🗞️ Other articles people like
👏 Weekly applause
These are some great articles I’ve read last week:
3 Tiny Habits That Changed My Career by
. Tiny habit shifts, like pausing before responding, scheduling thinking time, and delaying immediate commitments, can transform you from merely surviving to effectively leading in your software career.- . Understanding Reddit's architecture offers valuable insights into scalability challenges and solutions that can significantly enhance your system design skills.
What happens when databases crash mid backend request? by
. Understanding the Write-Ahead Log (WAL) is crucial for maintaining database consistency and durability during crashes, as it serves as the source of truth for transactions.
🙏 One last thing before you go:
I am always working to make this newsletter even better.
Could you take one minute to answer a quick, anonymous survey?
See you in the next email,
Fran.
Nice article, it's quite educative
#6 #8 and #10 are supper relatable. 😂.
Thanks for the crisp write up!