Note that I'm not saying we shouldn't do as best as we can with documentation, clean code, etc, BUT:
In the open source world, I've developed a large low quality codebase that is very complex from when I was less experienced. This project has gotten plenty of contributions over the years, some from less experienced and some from more experienced.
The experienced developers know how to get around the codebase, but the lesser experienced ones tend to complain about quality. I see this in the workplace as well.
I had this exact same issue when I was less experienced. New codebases was very difficult to understand, but now that I've been through a lot of them in various languages and quality, it's not as bad as it used to be.
I guess the argument here from the business point of view is that we write code for the less experienced? In a way this makes sense, but paradoxically some complex codebases that I thought was messy in the past have become more elegant today as I've gained more experience.
It could be that the more experienced developers are just burnt out in trying to give that kind of feedback, and instead just grit their teeth and get through the code base as they need.
Meanwhile the newer, less experienced developers probably still have a bit of... let's say naive optimism, and try to give feedback more.
That could be the case for a job you get paid to do, but for open source there are people coming in to help because they like the solution and have ideas for new features or refactoring.
The inexperienced developers in my case have not contributed much, but rather complained in other channels. (it's game related, the community is on discord, in game, etc)
it is probably because the new devs know so much more and are able to identify and communicate problems in code that others have written.
write code for the center of the bell curve (at your organization). the bottom will never understand anything, the top understands it all. You need to make the majority in the middle be comfortable.
that means slowly bringing in new language features, as they become widely known and practiced.
That's an interesting point of view to explore. Is it worth more to attract a few highly capable developers or a lot of middle capable ones?
Your code practices will probably resonate differently on each of those groups, so you will probably have to choose. And I don't think there's a generic correct choice like you imply.
Also, by how much are people even capable of choosing the (required) expertise level of the code they create? I'm not sure we can deviate a lot from our natural level.
In the open source world, I've developed a large low quality codebase that is very complex from when I was less experienced. This project has gotten plenty of contributions over the years, some from less experienced and some from more experienced.
The experienced developers know how to get around the codebase, but the lesser experienced ones tend to complain about quality. I see this in the workplace as well.
I had this exact same issue when I was less experienced. New codebases was very difficult to understand, but now that I've been through a lot of them in various languages and quality, it's not as bad as it used to be.
I guess the argument here from the business point of view is that we write code for the less experienced? In a way this makes sense, but paradoxically some complex codebases that I thought was messy in the past have become more elegant today as I've gained more experience.