What we don't teach or reward today is the behaviors and engineering process to write high quality code.
A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it.
When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I love to work with folks who put good effort into trying to make high quality changes. Personal initiative and ethics are how high quality software gets written.
Agreed, this has been one of the habits I've had to break during my computer engineering PhD at a scientific research lab. Initially I was just submitting the first solution I came up with without much additional thought.
My senior developer mentors ended up having to effectively rewrite all of it because while it was technically correct and efficient, it broke all sorts of other good practices (eg didn't fit the existing coding style), or added in additional library dependencies without much thought towards long term maintainability and backwards compatibility.
It was taking so much time for the handful of already busy developers to go through my work that I had to learn to slow down, properly study the existing code and think about writing high quality code that fits the existing codebase. They didn't have the time to put down all their other work just to spend hours walking me through improving.
As you mention, it was like with learning art, it's impractical for a teacher to walk you through everything, you have to learn to identify errors and things you need to improve through your own meticulous study, relying on the teacher to give you hints when you're stuck.
You’re right and it’s even worse. Much of the content on “engineering” especially on YouTube teaches resource intensive and overly complex practices sold as good programming. Moving more work to runtime. Increasing dependencies. Relying increasingly on blocking RPC. Wasting memory, cpu and storage.
A rejection of performance and compatibility as the core principles of software engineering in favor of “syntactic sugar” and “idiomatic Haskell”
> folks who put good effort into trying to make high quality changes.
In my 13 years in the industry, I’ve never worked at a place that valued that. More features faster, how many points this sprint is all that mattered. It’s put me off software engineering altogether.
The process you're describing is the exact thing you want to happen: junior developers are trying to learn to write better code. Why should they waste their time researching not their code base when they can instead learn off their code base from people experienced with it?
Because that's what everyone does? You learn by studying other's people work and try to apply it to your own. Painters, musicians, architects, etc … all do it. Why not developers? Instead everyone's rushing to learn React without even knowing the DOM api. Or build a web app with 1000s of dependencies that could be done with a few PHP files. And then they say they need docker and k8s.
The entire debate is over which qualities count as "better". Even "readable" is subjective. Some people love Java with sentence-long variable names. Some love 1-letter vars. Some love 100-deep call stacks, some love flat code. Some love microservices, some love resident call-stacks.
A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it.
When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I love to work with folks who put good effort into trying to make high quality changes. Personal initiative and ethics are how high quality software gets written.