Firstly, simple design places higher demands on developers than complex design. You need sufficient experience and a deep understanding of the business to create a design that is just right. Otherwise, after several iterations, your code is likely to become bloated—for example, a single file exceeding 2,000 lines or a function stretching over 500 lines.

Secondly, I strongly agree with a statement I once read (though I can’t recall the exact source): "Good code isn’t written perfectly from the start—it’s shaped through continuous refactoring. You need to refactor it at the right time." However, most companies simply don’t allocate time for such refactoring, as new requirements keep pouring in.

Under these constraints, it becomes clear that most companies tend to favor complex design as an engineering trade-off. We have a range of tools for complex design, such as SOLID principles, design patterns, and DDD. But there’s little guidance on simplifying design. I rarely see blogs discussing how developers should judge whether a design is over-engineered or what constitutes a just-right design. In such cases, having some design is better than having none at all—after all, many companies truly operate without any design, relying solely on copying existing solutions.

> But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words.

To me, this is the main problem. Engineer A is unable to describe the impact of their work, how the work affected the business. Your manager isn't responsible for promoting your own work, you are.

> Engineer B’s work practically writes itself into a promotion packet: “Designed and implemented a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and built a configuration framework enabling future extensibility.” That practically screams Staff+.

Maybe it's just the narrow of the article, but if promotion only looks at complexity and not quality of delivery and impact on the business then this isn't a good engineering team to be in.

There are many cases where simplicity is celebrated and recognized. It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.

As a practicing architect (of buildings) I had a special fondness of working on minimalist projects. Buildings are a complex problem space. You typically can't design out unnecessary complexity entirely. So you have to work backward from goals (the finished condition) to infrastructure (the building structure) to figure out how to make the end product look like almost nothing (Mies's "beinahe nichts").

That's all to say that "complexity impresses" as the article says, but the discerning understand that simplicity can be even more impressive.

It also puts me in the frame of mind of another famous one - Fred Brooks's "No Silver Bullet" [1] and the idea of essential vs. accidental complexity. Or as I like to think of it in a slightly more nuanced way - not necessarily "accidental" but at least "incidental."

[0] https://www.folklore.org/Negative_2000_Lines_Of_Code.html

[1] https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring people along.

Often perceived impact is correlated with complexity, sadly.

This isn't an engineering problem, it's a sales problem.

Also, you don't even have to be good at this stuff anymore. Any management nitwit would eat that up on a performance eval, and I had GPT write it for me.

Prompt: "Write up the most corporate self eval possible for someone who identified a simple solution in only 50 lines of code, instead of creating an over architecture mess. Keep it to just three sentences"

  If you have 10 teams working on the same product, you probably need service boundaries.