Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible.
Their second decade they learn that simplicity and readability is always better, even if it does require more code.
It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the same code that's difficult to understand, and difficult to debug.
Always code for your future-self and future-others who really don't want to spend an hour figuring out what the hell you did in that awesome looking 30 lines of entropy.
IME it's about time spent maintaining code rather than an age/experience thing, devs that flock like locusts from green field to green field will never learn, devs that maintain "clever" code will learn pretty quickly.
Sometimes you're lucky enough to have this expedited; my first CL at my first job was beautiful and elegant and concise and needlessly complex, and I was told to unroll it to make it more readable. The lesson sunk in the minute I had to start reading other people's code.
"Expedited" haha. yep. I mean there are times when something is going to cause just totally complex code to be required, but in those cases there should almost always be a full paragraph of "explanation" (documentation) for about every 10 or so lines of code.
Ends up with actually more documentation text than code itself, which is a good thing. But for the majority of code it an be kept simple and self-documenting.
Sure, but the converse is that when you have a 10k+ LOC project, you can't read that program linearly anymore. I find that sometimes proponents of "straight-forward code" strive for code to be immediately understandable line-by-line, but in big projects, this is not how you navigate a project; you have to create the right modules and abstractions, otherwise you will get lost.
I've worked mostly on massive apps with 400K to 1 or 2 million lines of code, in many projects, so the concept of linearly reading thru the code is something that just never happens.
But with a "keep it simple" philosophy the number of lines of actual code never really matters that much, while code where the developers were clever and complex at every opportunity (often just showing off) the code is quicksand and a quagmire every every single line of the way, and is a nightmare.
Their second decade they learn that simplicity and readability is always better, even if it does require more code.
It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the same code that's difficult to understand, and difficult to debug.
Always code for your future-self and future-others who really don't want to spend an hour figuring out what the hell you did in that awesome looking 30 lines of entropy.