[baobabKoodaa]

> But where do we draw the line?

Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you think mediocre developers can't understand streams, then don't use streams. (Personally I think your examples of interfaces, exception handling, and streams, are all things that have their time and place, so it would be fine to use them when needed, and just expect that developers after you will know/learn that stuff.)

[908B64B197]

> If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers.

There's a secret third option: The organization could just hire good devs.

[baobabKoodaa]

> There's a secret third option: The organization could just hire good devs.

That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.

[pojzon]

The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.

[baobabKoodaa]

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

[pojzon]

I dont know a corporation in IT that doesnt have evaluation programs. All management expects you to get better over time.

So using the opportunity to learn from a better dev is a great objective that positively will impact not only you but also the company you work for.

On the other hand if developers stagnate and dont improve -> this is a red flag for company growth. And each corporation wants to grow. Such dev is just a bad hire and will tank the company.

[baobabKoodaa]

Of course developers should learn and improve. Nobody is arguing otherwise. Yes, people can improve, that doesn't change the fact that the average company employs average developers. If your company hires average developers, then you need to maintain your codebase complexity at a level that is manageable by average developers. All this talk about "bad hires" and such is really missing the mark here.

[908B64B197]

It doesn't: The average startup goes bankrupt.

[baobabKoodaa]

The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave?