Extends to the extreme levels of SaaS-ification of fairly basic app functionality as well.

It's often simpler to build something you know than to integrate a 3rd party service, but it's highly frowned upon by a lot of devs and management.

Auth and analytics are things I'm thinking of - we have good tools to build these in-house. Also just running a database - never seen so many people afraid of installing postgres and a cronjob to back it up.

Ah, but it's worse than this. The truly ambitious ladder climber creates not just unnecessarily complicated abstractions, but organizations. Processes for people to follow. Infrastructure for people to maintain. Committees to vet changes. Standing meetings.

Simplicity can be a powerful defence against complexity. When there are many ways something can go wrong.

Rather than trying to anticipate all the different failure modes one tries at first just to handle fact of failure itself, assuming there's no remediation.

If there's a way to make sure the worst case isn't terrible in some simple way then you do that first - like making a backup file or tr4ying to keep APIs idempotent so you can recover from issues and so on.

FAANGs are notorious for promoting complexity, and the results are there for all to see.

One thing engineers can do to fight this, and I think it's mentioned in the article, is to write extensive documentation. Bosses in these companies are too lazy to dig into solutions and figure out for themselves; so they resort to proxies like the number of lines of code, number of pages in the design doc, etc.

Unfortunately, some of us who aim for simplicity are also averse to writing long docs; but with the advent of LLMs, there is some relief in sight.

My career has suffered a lot in terms of promos, etc. because I hate complexity.

The problem can be complex, which sometimes means the solution needs to be complex. Often, you can solve a complex problem in simple ways. There’s many ways to do that:

a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way

b) finding ways to use existing abstractions, that others may not have been able to find

c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements,

The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”.

In some orgs, this is hopeless, as they really do reward complexity of implementation.

Maybe not promoted, but certainly hired, as a consultant.

Most of my engagements consisted of replacing politics-driven complications with simple solutions.

The bigger problem was first quietly showing all the affected people other interesting things that needed doing so they would let go.

And TBH, the simple stuff lasted the longest because it harder to misunderstand or misrepresent.

The incentive misalignment gets worse when you factor in hiring pipelines. A team that keeps their stack simple has fewer "impressive" bullet points for resumes, which makes it harder to hire senior engineers who want to work with "interesting" technology. So there's pressure from both ends — management rewards complexity, and talent acquisition inadvertently selects for it. The orgs that consistently reward simplicity seem to be those where senior engineers have enough credibility to push back and say "we already solved this with three lines of SQL."

This resonates so hard with me. I was self-employed for over eight years, since I was the one who had to deal with all messes I always made sure that things were as simple as sensible (but not simpler). I made a good career out of it. Then I went back to being employed by a company, and I was completely befuddled but the over-complication of designs. Engineers aren't trying to help the business or solve a problem, they're trying to prove how good they are. It's just the completely wrong set of incentives. If you only get promoted by solving complex cases and there are no complex cases to solve, then you'll make them up.

The push for simplicity can't be at the time of recognition. It has to be during the building, so that by the time the thing gets built, it's the simplest thing that met the need.

Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."

Absolutely not! That discussion happens in RFCs, in architecture reviews, in hallway meetings, and a dozen other places.

If you want simplicity, you need to encourage mentorship, peer review, and meaningful participation in consensus-building. You need to reward team-first behavior and discourage lone-wolf brilliance. This is primarily a leadership job, but everybody contributes.

But that's harder than complaining that everything seems complicated.

Sad but true. I'm very strict with my developers and extremely cautious of introducing new "moving parts" to existing systems. I try to keep a single deployment-unit if possible. I like monoliths.