Nobody gets promoted for simplicity

Well you do get promoted for simplicity if you outperform others, who do things too complicated.

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.

It's not just that it looks good, there is constant pressure from other Engineers that we should "Do it right" and "Plan for the future" even if the future is murky and every design choice we take for scalability is probably just constraints that will hinder us if the requirements change.

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.

I promote people for simplicity

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

This is definitely a "known problem". At my company we call it "promotion-driven development". The promotion guidelines call out that knowing when _not_ to build something is important, but how do you put that in a body of work? "Decided not to build A". Nobody cares.

I feel this. I once worked for this manager, and whenever we finished a sprint, the first question he ALWAYS asked was "What tool(s) did you use/implement?" Many times, the answer was "No tools, I just banged out a bit of code to do the job.", only to get looked at for several seconds before he looked disappointed, and moved on. It was infuriating!

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.

Being able to solve problems with true simplicity is a master’s skill. The skill to recognize simplicity and its value is a skill as well.

You can try to explain this OP’s concept to a stakeholder in a 1000 different sensible ways and you’ll get blinking deer-in-headlight eyes back at you.

This skill is hard-earned and, so, rare.

Therefore, many hierarchies are built on sufficient mediocrity top to bottom.

Which works because bottom line doesn’t often matter in software dev anyway.

And even when it does matter it’s multiplicatively rare to have a hierarchy or even the market that it tries to serve who can build, comprehend, handle high power::complexity systems, products, tools.

I'm trying to sell simplicity to my target market, who I would call "semi-tech literate". Maybe it's stupid and I should sell whatever Forbes thinks is cool, but I just can't shake this feeling that I should be solving actual business problems.

Is it just me or could this apply to commentary as well? Sometimes, I set out to comment with all my thoughts and their intricacies related to the subject, but sometimes the simplest one contributes far more to the conversation. In my experience, simplicity enables others to more freely participate and contribute.

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.

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.

It's great to choose simple solutions to avoid over-engineering, but at the same time you need to be able to talk about them in a way that proves making that choice was much more complex than picking the complex path directly. Listing both the complex solution and the simple one shows others that you reasoned about both and deliberately chose simplicity. It's all about framing the story behind the decision.

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.

I hate clickbait titles like this. Of course, some organizations appreciate and reward simplicity. Mine does.

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.

This was already a post 6 hours ago which is now [dead].

What happened?

Not my experience.

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.

what a pub/sub hater

"less is more"

[dead]

[dead]

[dead]