As a manager, I preferred engineers that delivered simpler code, but I also ran a team of experienced, high-functioning coders. I suspect teams with many less-experienced people get The Parable of The Toaster[0].

[0] https://www.danielsen.com/jokes/objecttoaster.txt

Simplicity is worth recognizing only when the person started with a complex problem and ended up with a relatively simpler solution.

For a straightforward ask you will have people who will just build a hut and another will build a campus, who is right really depends on many factors and time.

Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.

You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.

Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.

P.S. I know this sounds obvious, but I was a slow learner.

I had to stop trying to prove myself to the company. I have already done that when y'all interviewed me. Now I do what's best for everyone, and I want the company to prove to me that it deserves people who do the right thing despite the processes not valuing it. If it does not, I have enough resources to spend some time on the projects I cared about most.

This mentality gave me peace of mind and helped many people in partner teams go faster and with higher quality.

Management still does not openly appreciate it, but it shows in how they interact with me. Like when you learn to talk to your parents as equals. It's unexpected for them, but they quickly embrace the new interaction and they love it much more than the one before.

In fact, simplicity often is the best future-proofing. Complex designs come with maintenance costs, so simple designs are inherently more robust to reorgs, shifted priorities, and team downsizing.

It's not just the most "elaborate system". The same thing happens in so many other ways. For example a good/simple solution is one and done. Whereas a complex one will be an interminable cause of indirect issued down the road. With the second engineer being the one fixing them.

Then there's another pattern of the 10x (not the case with all 10x-ers) seeding or asked to "fix" other projects, then moving on to the next, leaving all the debt to the team.

It's really an amazing dynamic that can be studied from a game theoretical perspective. It's perhaps one of the adjacent behaviors that support the Gervais principle.

It's also likely going to be over soon, now that AI is normalizing a lot of this work.

I built a showback model at a prior org. Re-used shelfware for the POC, did the research on granular costs for storage, compute, real estate, electricity, HVAC maintenance, hardware amortization, the whole deal. Could tell you down to the penny how much a given estate cost on-prem.

Simple. Elegant. $0 in spend to get running in production, modest spend to expand into public cloud (licensing, mainly). Went absolutely nowhere.

Got RIFed. On the way out the door, I hear a whole-ass team did the same thing, using additional budget, with lower confidence results. The biggest difference of all? My model gave you the actual cost in local currency, theirs gave you an imagined score.

The complexity (cost of a team, unnecessary scoring) was rewarded, not the simplicity.

Rarely have I seen an actually straightforward, simple feature that can be done in a day used as the basis to spin up a 3-week mini-project with a complicated new architecure.

What happens is a complicated-sounding feature is requested, and some devs will just take it literally and implement it, maybe along with some amount of "future-proofing" that logically follows because the spec is poorly scoped.

Other devs will spend some time thinking about it, realize that there is a really a simple requirement at the core of the request, and it only sounds complex because it was vaguely specified (or maybe these days an LLM was used to write the spec, and its vomit was copy-pasted verbatim). They just implement the simple thing that is the actual need.

This is one place where the agile/scrum practice of planning poker can help. You get a few smart people in a room, and discuss the story and its requirements. Hopefully someone will throw out a low number of points and say "isn't this simply asking for..."

Over my career, most of the complicated code I have written is no longer running. What is still running after 10 years? Postgres (or more broadly, a relational database). Fad frameworks or architectures come and go pretty quickly, they don't end up working as advertised, and it's on to the next thing. I no longer want to spend time in this hamster wheel churning out complicated code that will only end up as next year's tech debt.

I got emotional reading this. This is way too real.

As a consultant/contractor I always evangelise simplification and modelling problems from first principles. I jump between companies every 6-12 months, cleaning up after years of complexity-driven development, or outright designing robust systems that anybody (not just the author) can maintain and extend.

This level of honesty helps you build a reputation. I am never short for work. I also bill more than I could ever as a full-time engineer based in Europe.

More than once I have seen the same project yield two separate promotions, for creating it and deleting it. In particular this happens when the timescale of projects is longer than a single engineer's tenure on a given team.

But yes, avoiding complexity is rarely rewarded. The only way in which it helps you get promoted is that each simple thing takes less time and breaks less often, so you actually get more done.

At core, complexity is derived from discovery of demand within those pesky complex humans.

Simplicity is the mechanism of finding common pathways within the mess of complexity of a product.

the tragedy is that simplicity is very expensive and beyond most organizations ability to support (especially since it can slow down demand discovery), and this is one of the allures of big tech for me. I was greatly rewarded and promoted for achieving simplicity within infrastructure.

I'm currently building a full-blown OpenAPI toolchain at work, where the OpenAPI document itself is the AST. It contains passes for reference inlining, document merging, JSON Schema validation, C++ code generation and has further plans for data model bindings, HTML5 UI...

Why? Because I'm working on a new embedded system which has a data model so complex, it blew past 10k lines of OpenAPI specifications with no end in sight. I said "ain't no way we're implementing this by hand" and embarked on the mother of all yak shavings.

I want all of the boilerplate/glue code derived from a single source of truth: base C++ data classes, data model bindings, configuration management, change notifications, REST API, state replication for device twins and more. That way we can focus on the domain logic instead, which is already plenty complex on its own.

I'm not designing all of this to be simple to develop. I'm designing it so that it's simple for the developers. Even with the incomplete prototype I have currently, the team is already sold ("you mean I just write the REST API specification and it generates all of the C++ classes for me to inherit?"). The roadmap of features for that toolchain is defined, clear and purposeful: to delete mountains of menial, bug-prone source code before it is ever written by hand.

Sometimes, it takes complexity to deliver simplicity. The trick is to nail the abstractions in-between.

BUT, at least very occasionally I have seen people get promoted for simplicity, I've even successfully made the case myself. With a problem that was itself so complex that it was causing fires on a regular basis, and staff & principal engineers didn't want to touch it with a ten foot pole. When a senior eng spent a couple of weeks thinking about the problem and eventually figured out a way to reframe it and simplify the solution, melting away months of work, making the promo case was actually quite easy.

The problem is, the opportunities to burn down complexity like that don't present themselves nearly as often as the opportunities to overcomplicate a thing, which are pretty much unbounded.

The irony is that the elaborate design usually handles those hypotheticals incorrectly anyway, because you can't predict real requirements from imagination. The simple version gets modified when real feedback arrives, and the modifications are cheaper because there's less architecture to work around.

The sad thing is that it is common to get fired when you make things better bc then your work is perceived as "done" and your skills are no longer necessary. There are countless IT job stories where someone delivers a technical solution that saves a company a ton of money or generates revenue, then they get fired bc the solution has been delivered and an off shore team has been hired to maintain the work.

Big corps suck.

Edit -- reading some the responses here on this topic and they are...eye-opening and depressing.

Also survivorship bias is a very real thing (problem prevented is ignored, while problem solved is appreciated regardless of who and why caused it).

Instead I went to the hardware store across the street and bought the biggest (and cheapest) screwdriver I could find and attached it with some cord to the HSM. They never lost it afterwards.

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.

I've noticed the incentive breaks down even further when you consider that simplicity often means saying no upfront, which requires correctly predicting future maintenance costs that nobody has experienced yet. Complexity requires no such foresight. You just build the thing someone asked for.

The orgs where I've seen this actually work had explicit "deleted lines" culture, where removing code was celebrated as loudly as shipping features. Not many places do that. Most treat a 2000-line deletion PR with the same energy as taking out the trash.

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.

It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion.

Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back.

There's failure modes in any of these but the one I see most often is overreaching concern for any single one.

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.

> Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this.

So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change).

Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized.

You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed.

Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions.

Go for the middle path.

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.

It's hard to keep things simple. Management should be mindful of that and encourage engineers to follow YAGNI, to do refactorings that remove more code than they add, etc.

And complexity doesn't always sell better. A lot of times it might look like the whole thing is messy, or too hard to maintain, tech burden nightmare. Things that are simple might look complex and vice versa too, I think anyone who had to implement requirements from people who don't understand the implementation complexities will know this very well.

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.

This was the model at my last job. The "director" of software had strong opinions about the most random topics and talked about them like they would be revolutionary. His team was so far from the product teams they would just build random crap that was unhelpful but technically demo'ed well. Never put into practice. Promoted for 4 years, then fired.

So the way we write software piecemeal today is fundamentally broken. Rather than starting with frameworks and adding individual packages, we should be starting with everything and let the compiler do tree shaking/dead code elimination.

Of course nobody does it that way, so we don't know what we're missing out on. But I can tell you that early in my programming journey, I started with stuff like HyperCard that gave you everything, and I was never more productive than that down the road. Also early C/C++ projects in the 80s and 90s often used a globals.h header that gave you everything so you rarely had to write glue code. Contrast that with today, where nearly everything is just glue code (a REST API is basically a collection of headers).

A good middle ground is to write all necessary scaffolding up front, waterfall style, which is just exactly what the article argues against doing. Because it's 10 times harder to add it to an existing codebase. And 100 times harder to add it once customers start asking for use cases that should have been found during discovery and planning. This is the 1-10-100 rule of the cost of bugs, applied to conceptual flaws in a program's design.

I do miss seeing articles with clarity like this on HN though, even if I slightly disagree with this one's conclusions after working in the field for quite some time.

- CV-driven development. Adding {buzzword} with {in production} sounds better than saying I managed to make simple solutions faster.

- Job security. Those who wish to stay longer make things complicated, unsupportable, and unmaintainable, so they become irreplaceable.

Adding extra things can always help, specially like in the UI side of things, since higher ups will probably just notice that part.

Your job is to deliver value. If you can get stuff done quicker and without it breaking, you did great. Some one who spent more time doing the same thing except took longer and has a more brittle solution they have to keep going back and fixing doesn't look good.

And simple solutions are easier to explain and convince people.

In smaller companies it's a lot easier to express the distinctions and values of simplicity to ears that might actually appreciate it (so long as you can translate it into what they value - simple example is pointing out that you produced the same result in much less time, and that you can get more done on overall feature/task level as a result).

Essentially, there are two parallel teams, one is seen constantly huddling together, working late, fixing their (broken) service. The other team is quiet, leaves on time, their service never has serious issues. Which do you think looks better from the outside?

It can even happen that the tag "very smart" gets attached to those sidelined engineers. That's not necessarily a compliment.

In my (limited) experience as an engineer and manager, leadership (e.g., a VP) didn’t like (or reward) simplicity. Simple solutions often meant smaller teams, which wasn’t something they were pushing for, especially pre-2024. I do think this is slowly evolving, and that the best leaders now focus on removing unnecessary complexity and improving velocity.

The obvious outcome will be that the most skilled pretenders optimizing for their selfish profit narrow view, no matter what the consequences will be for the collectivity on large scale and at long terms.

> The interviewer is like: “What about scalability? What if you have ten million users?”

This reminded me of how much more fun I find it to work on software that always only has one user, and where scaling problems are related solely to the data and GUI interaction design.

When a scientist says "simplicity" they mean "elegance". This is very different from "easy to understand". There's a reason that quote says simplicity is difficult to achieve. This doesn't seem in line with the author's examples. But it's easy to see what Dijkstra was talking about. Have you ever derived an equation in math or physics? You start one place, do a whole lot of work, and then you get out this "simple" thing. You could write pages of math to come up with an equation that uses only a few symbols. E=mc^2 is simple but getting there was very hard and took a lot of time, thinking, and abstraction.

The author conflates simplicity with speed, not with what the end result is and how well it solves the problem.

Why are CS people against abstraction? All we do is abstraction? We act like all abstraction is the same, and it's evil.

We have to be more nuanced. I could see the entire blog post written in the exact other way where engineer A gets promoted because they complete more tickets and engineer B doesn't because they take too long. But the reality is that from such a high level we can't determine which solution is right. Sometimes A's method is the best and sometimes B's is the best. But we don't know the impact. B's solution could create more problems, like the author suggests, but also it could solve many problems that don't end up appearing. Same for A's solution!

I don't like this over simplification and the author's conclusion is naïve. If we make everything understandable to everybody then it's a race to the bottom Who does it need to be understandable to? The senior? An experienced developer? A junior? A manager?

Don't get me wrong, there's tons of unnecessary complexity out there and that's bad too. But for that I'll reference Knuth's famous and misunderstood quote where he says "get a fucking profiler before optimizing things". He too is talking about elegance, but a balance of how we should prioritize things.

[0] Concern for Correctness as a Guiding Principle for Program Composition https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...

A lot of this boils down to promo system being so systematized. I've never heard of people in any other field min/max their promotions as hard along with all of the expert jargon in any other field I've worked in. Packets, peers, comp, other co comps, what your boss thinks of you, what your boss thinks of your peers (nee: competitors), and the inevitable crash out when they don't get the promotion. All part of the bigco experience! I feel like when we systematized comp into ranks Lx, Ly we gave up our leverage a little bit.

> It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it.

$100 says the "clean, simple" approach is the one which directly couples the frontend to the backend to the database. Dependencies follow the control flow exactly, so that if you want to test the frontend, you must have the backend running. If you want to test the backend, you must have the database running.

The "abstractions for problems that might never materialize" are your harnesses for running real business logic under unit-test conditions, that is, instantly and deterministically.

If you do the "simple" thing now, and push away pesky "future-proofing" like architecting for testing, then "I will test this" becomes "I will test this later" becomes "You can't test this" becomes "You shouldn't test this."

Problem is in big tech -- the incentives are all aligned towards complex stuff

you wanna get promoted - do complex stuff that doesn't make sense. If you get promoted, then it also boosts the performance of your manager.

the only way to escape this nonsense is to work at smaller companies

right now you've people advocating for A.I coded solutions yet never realizing that A.I solutions result in a convoluted mess since A.I never possesses the ART of software engineering i.e knowing what to cut out

Good leaders perceive workhorse vs showhorse spectrum, critical toil vs needless flash (and vice versa).

It’s hard. Most fail at hard things. The industry in the aggregate will fail at hard things

So you get articles like this.

For example, person A implements the simple solution, gets the project done faster while person B over engineers, has seemingly impressive stuff to talk about but at the end of the day doesn't ship.

* You can have a bunch of simple code for a latent or implicit concept that is complex; and that making the code more complex might make the reflect principle simpler.

* You have trade-offs: If one aspect is simple, other aspects must become more complex to accommodate.

* There is no consensus over what constitutes complex vs simple code.

as a manager its constant fighting the pressure to build "Great software" that is way above what the company needs instead building working software that addresses customer needs in a timely manner.

My dude we are s startup with two servers and 20 customers, we do not need infinite scalability.

In case you ask “how can simple solutions be hard to understand and test?”

Lets just say you use single line bash scripts with multiple pipes, loops and very niche cmds.

It will work, it will look like nightmare, it will be simple -> one line.

This extends to suggesting huge licenses like from Salesforce. The Marketing and HR teams are ecstatic that they can purchase another license of their favorite software, they can go shopping! If I had implemented a free and more efficient CRM, there would be no networking effect.

This all builds systems that are vastly more expensive (to the tune of hundreds of thousands of dollars), slower, and much harder to fix. YCombinator financially benefits from this and it's all very corrupt. Most of the time, I have to really gain the "soft skills" to activate the networking (nepotism) effects.

It's not about what you know, it's about who you know.

Be the change you want to see in the world. If you are in management, promote those that see the value in simplicity.

And long before performance review time, I'd have mentioned further up that A was looking like a 5X engineer - best if we keep her happy.

What happened?

I once hacked a spreadsheet in a week that was good enough to not embark on a multiple-months 3-devs project.

In the same team, I tweaked a configuration file for distributed calculations that shaved 2 minutes of calculation on an action that the user would run thirty times a day.

I got paid all right.

People don't give a shit about complexity or simplicity. They care about two things:

1. Does it work

2. How soon can you ship

There is a third thing that stakeholders really like: when you tell them what they should be building, or not building.