I have some issues with this. Say 5 years ago I would have fully agreed with you on this topic. Clean code for me was defined:
1) does what it says without surprises (mostly surprising side-effects)
2) is easy to read for everyone fluent in the language
3) is careful with used ressources ~ "efficient"
I think so far we are on the same page.
But I changed my attitude towards (2).
The code should be understandable by the most junior dev in the team
I agree upon that is not the goal to have. But today I would say
2) is easy to read for everyone in the audience
Which is a small change, but with an interesting impact:
Say you are working with a high skilled team there is no reason to hold back some knowledge. You are fluent in x so use it up to its full potential.
If you are publishing your code for your own behalf there is no reason anyway to hold back knowledge.
But if you are working on a team where others have to read your code the mentality of "when you do not understand quality code you are a low quality developer" does help nobody it only feeds your ego. The problem is not having a low quality team but you being a blocker in the team, because you cause extra work. I changed my perspective due to an experience where I supported another senior developer getting his project out of the door. The project was overdue. I knew newer language features the other did not at the time. So it was natural for me to put my knowledge to work. But what happened? I wasn't there when my code broke and he had to fix it. Instead of fixing the code right away he was forced to learn the new language features.
Of course you could argue with educational debt on the companies side - and you would be quite right with that - but this is of no help, when you are in a hurry to to fix just a simple bug.
So: Yes, it would be easy to blame "low quality developers", but it doesn't help the team. Sometimes there is even no time or money to educate your team.
Write for your audience - and if you are the only senior then it would be better for the team you write junior level code than to foce every other developer to adapt to your level. If that feels wrong, maybe you are in the wrong team?
I have some issues with this. Say 5 years ago I would have fully agreed with you on this topic. Clean code for me was defined:
1) does what it says without surprises (mostly surprising side-effects)
2) is easy to read for everyone fluent in the language
3) is careful with used ressources ~ "efficient"
I think so far we are on the same page.
But I changed my attitude towards (2).
I agree upon that is not the goal to have. But today I would say
2) is easy to read for everyone in the audience
Which is a small change, but with an interesting impact:
Say you are working with a high skilled team there is no reason to hold back some knowledge. You are fluent in x so use it up to its full potential.
If you are publishing your code for your own behalf there is no reason anyway to hold back knowledge.
But if you are working on a team where others have to read your code the mentality of "when you do not understand quality code you are a low quality developer" does help nobody it only feeds your ego. The problem is not having a low quality team but you being a blocker in the team, because you cause extra work. I changed my perspective due to an experience where I supported another senior developer getting his project out of the door. The project was overdue. I knew newer language features the other did not at the time. So it was natural for me to put my knowledge to work. But what happened? I wasn't there when my code broke and he had to fix it. Instead of fixing the code right away he was forced to learn the new language features.
Of course you could argue with educational debt on the companies side - and you would be quite right with that - but this is of no help, when you are in a hurry to to fix just a simple bug.
So: Yes, it would be easy to blame "low quality developers", but it doesn't help the team. Sometimes there is even no time or money to educate your team.
Write for your audience - and if you are the only senior then it would be better for the team you write junior level code than to foce every other developer to adapt to your level. If that feels wrong, maybe you are in the wrong team?
Yup, it's a fine balance... but in recent years I do feel the balance is being lost - at least in places where I've worked