Why Reducing Complexity Is A Sign of Seniority
· Summarized
Key takeaways
- As engineers mature, their work naturally becomes simpler due to experience, refactoring, and a focus on core principles.
- Simplicity is a byproduct, not an explicit goal. Understanding why complexity decreases helps engineers deliberately aim for simplification.
- Refactoring to collapse abstractions and focusing on fundamentals reduces system complexity and improves maintainability.
- Developing a better risk tolerance allows engineers to avoid over-engineering and focus on what truly matters.
- A senior engineer's emphasis on core principles and fundamental understanding leads to more efficient, focused systems that are easier to maintain.
Summary
The Paradox of Growing Simplicity in Senior Engineers
As engineers advance in their careers, they tend to develop systems that are less complex rather than more. Initially, output increases rapidly with new learning and output, especially with AI tools, and the work can be quite complex. However, over time, experienced engineers tend to simplify their code and systems, often by collapsing abstractions and focusing on core principles. This paradoxical trend is driven by a desire to reduce maintenance burdens, improve understanding, and facilitate future modifications.
Why Simplicity Matters and How It Is Achieved
Simplicity in code and systems is primarily a byproduct of experience and understanding, not an explicit goal. Simpler systems are easier for others to understand and modify, which benefits both new team members and future self. The move towards simplicity is often the result of past hardships, like extensive refactoring, which teach engineers to make better trade-offs. Over time, engineers learn when to break best practices—such as over-abstraction or unnecessary use of external libraries—to maintain clarity and reduce complexity.
The Role of Risk, Principles, and Refactoring in Reducing Complexity
Senior engineers develop a better sense of risk tolerance, allowing them to accept manageable risks rather than over-engineering for every possibility. This includes collapsing unnecessary abstractions and focusing on fundamental design principles—such as understanding the core purpose of a system—to reduce the number of components and dependencies. Refactoring is a key tool here, where long chains of abstractions are collapsed into simpler, more understandable forms, often aligning with core principles like conservation of energy in physical systems.
Focus, Responsibility, and Core Principles in System Design
As engineers gain experience, they tend to focus on fewer responsibilities and reduce the surface area of their work. This refines their understanding of fundamental principles, allowing them to build more efficient and maintainable systems. The episode emphasizes that a focus on core principles—rather than surface-level tactics—enables the creation of simpler, more reliable systems. The more senior engineer recognizes the importance of reconfiguring systems around these fundamentals to avoid unnecessary complexity.
Sponsors
- Developer Tea · This episode and every other episode of this show is available as a podcast, and also on YouTube. Check out the YouTube channel for more content.
Show notes
As you grow as an engineer, something counterintuitive happens: the systems you build get simpler, not more complex. In this episode, I explore why senior engineers tend to collapse abstractions, accept certain risks, and reduce the surface area they're responsible for — and what drives that shift underneath the surface. Understanding the reasons behind the trend is what lets you get there on purpose instead of waiting a decade to arrive there accidentally.
Early in your career, output goes up fast. You're building more than ever, especially with AI in the mix, and a lot of what you build carries real complexity. But watch engineers who have been doing this a long time and you'll notice the opposite of what you'd expect: as their craft improves, their code, their architectures, and their systems get simpler. In today's episode, I dig into why that happens — and why chasing simplicity directly is less useful than understanding the underlying forces that produce it.
- Simplicity Isn't the Goal — It's the Byproduct: Trying to "make things simpler" as a directive doesn't get you very far. If you can understand the core reasons complexity tends to fall as engineers mature, you can aim at those reasons instead and arrive at simplicity organically.
- Why Simpler Code Pays Off: Simpler things are easier to understand, which means junior engineers can pick up your code, and future-you can return to a project you've long since left and still make sense of it. Adapting a simple thing is almost always easier than adapting a complex one.
- The Pain of the Refactor Teaches You: A big part of this shift is scar tissue. Once you've lived through a massive refactor of a complex system, you start making different trade-offs — not from theory, but because you don't want to do that again.
- Collapsing Vertical Abstractions: One of the most common refactors senior engineers reach for is collapsing long chains of abstraction that only ever get used in one place. It's abstraction without reuse, and it forces you to re-load enormous context just to make a small change.
- Refining Your Risk Tolerance: Early on, we hedge against every possible risk. Later, we learn some risks are acceptable. Hedging is insurance, and sometimes it's very expensive insurance — paid in velocity, in onboarding difficulty, and in only being able to hire people who can hold all that complexity in their heads.
- Knowing When to Break Best Practices: Maybe the best practice says abstract this. But if it isn't that hard to understand, and you can get most of the benefit through better naming or tighter scoping, the "correct" move might be the wrong one.
- The Library Trap (In Both Directions): Seniors often take a trip through "let's not use external packages, we don't know what's in them" — and end up maintaining a shadow version of the thing they avoided. The more experienced call is often to accept the trade-off, adopt the well-documented dependency, and shrink what you are responsible for.
- Reducing Surface Area Creates Focus: The through-line in all of these trade-offs is a shrinking surface area. Fewer things to maintain means more focus, and more focus means the things you are responsible for get done very well. It's an open question whether those behaviors follow seniority or cause it.
- Drive to the Fundamentals: Think about a machine built from a ramp, a screw, a rubber band, and a motor. A more senior craftsperson recognizes the problem is fundamentally about conservation of energy, and reconfigures it down to two parts instead of eight. Slightly less efficient, maybe — but far less to teach, maintain, and break.
- Episode Homework: Ask yourself: what am I responsible for right now that I could simplify? Where can I get away from the tactics and the surface-level stuff, get down to the core of the thing, and focus on doing that core really well?
📮 Ask a Question
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
📮 Join the Discord
If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!
🗞️ Subscribe to The Tea Break
We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.
🧡 Leave a Review
If you're enjoying the show and want to support the content head over to iTunes and leave a review!
Follow this show on AudioBrevity and new episodes get summarized for you. Create a free account