Article seems to suggest that simplicity vs complexity is a sort of a binary, or at least a spectrum. In fact, it's very often the case that:

* 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.

Yep people get promoted for bullshit throwaway projects that are built in the fastest & dirtiest way possible so that management can dance & clap about how brilliant everyone is about every 2-4 weeks.

What in case engineer picks a simple solution that is hard to understand, cant be tested and next person that comes looks at it and says “wth is that?”

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 is so weird to read given the quote at the top. The kind of simplicity Dijkstra is talking about is a form of abstraction. He's talking about elegance. While the author is talking about a different type of abstraction, more like the image or a Jackson Pollock painting. Look at how Dijkstra talks here [0].

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.

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

When I'm on a team and there are multiple engineers and data scientists, many of them come from Big Tech: Google, Microsoft, Apple, etc. I don't get any points with them for implementing a one-liner that does whatever Google implemented but they get very excited if I did. I get a "Oh wow, I know someone who worked on that at Google, I am really glad it's useful!"

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.

All this is game theory top to bottom. The only way to really quantify productivity is to look at "how much" of a thing has been created. In this case, lines of code, features, files, etc... So of course people who want to maximize their own income through promotions will also be incentivized to maximize the only quantifiable thing that they're judged on.

We all know this, but no one is willing to fix it.

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

Earlier discussion: https://news.ycombinator.com/item?id=47242765

Steve Jobs

If I was an engineering manager in an org which actually valued getting sh*t done - vs. bragging rights, head counts, and PHB politics - then I'd notice within a month that Engineer A (who the article has shipping in a couple days) got far more done then Engineer B (who needed 3 weeks).

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.