My point is exactly that "the simplest thing can be very difficult to do". You need to be an experienced engineer to apply this advice.

But an experienced engineer already knows this!

I just think it's ironic that this advice is useless to junior engineers but unneeded by senior engineers.

> I just think it's ironic that this advice is useless to junior engineers but unneeded by senior engineers.

That's a good way of putting it. The advice essentially boils down to "do the right thing, don't do the wrong thing". Which is good (if common sense) advice, but doesn't practically really help with making decisions.

I currently have one concept stuck in my mind, which I would call "Complexity distribution".

For example, at work, the simplest solution across the whole organization was to adopt the most complex PostgreSQL deployment structure and backup solutions.

This sounds counter-intuitive at first. But this way, the company can invest ~3 full time employees on having an HA, PITR capable PostgreSQL clutser with properly archived backups around ~25 other development teams can rely on. This stack solves so many B2B problems of business continuity, security, backups, availability.

And on the other hand, for the dev-teams, the PostgreSQL is suddenly very simple. Inject ~8 variables into a container and you can claim all of these good things for your application without ever thinking about those.

Yes, but this is meaningless advice.

The best solution is the simplest.

The quickest? No the simplest; sometimes thats longer.

So definitely not a complex solution? No, sometimes complexity is required, its the simplest solution possible given your constraints.

Soo… basically, the advice is “pick the right solution”.

Sometimes that will be quick. Sometimes slow. Sometimes complex. Sometimes config, Sometimes distributed.

It depends.

But the correct solution will be the simplest one.

Its just: “solve your problems using good solutions not bad ones”

…and that indeed both good, and totally useless advice.

The article responds to this.

Really?

We both read the article; you know as well as I do that the advice in it is to build simple reliable system that focus on actual problems not imagined ones.

…but does not say how to do that; and offers no meaningful value for someone trying to pick the “right” thing in the entire solution space that is both sufficiently complex and scalable to solve the requirements, but not too scalable, or too complex.

There’s just some vague hand waving about over engineering things at Big Corp, where, ironically, scale is an issue that mandates a certain degree of complexity in many cases.

Here’s some thing that works better than meaningless generic advice: specific detailed examples.

You will note the total lack of them in this article, and others like it.

Real articles with real advice are a mix of practical examples that illustrate the generic advice they’re giving.

You know why?

…because you can argue with a specific example. Generic advice with no examples is not falsifiable.

You can agree with the examples, or disagree with them; you can argue that examples support or do not support the generic advice. People can take the specific examples and adapt them as appropriate.

…but, generic advice on its own is just an opinion.

I can arbitrarily assert “100% code coverage is meaningless; there are hot paths that need heavy testing and irrelevant paths that do not require code coverage. 100% code coverage is a fools game that masks a lack of a deeper understanding of what you should be testing”; it may sound reasonable, it may not. That’s your opinion vs mine.

…but with some specific examples of where it is true, and perhaps, not true, you could specifically respond to it, and challenge it with counter examples.

(And indeed, you’ll see that specific examples turn up here in this comment thread as arguments against it; notably not picked up to be addressed by the OP in their hacker news feedback section)