hmmm, this is true definitely on the face of it. Less skilled engineers don't see whether they are implementing functionality that couples a bunch of logic together that will be difficult to entangle, or duplicating logic, or adding a bunch of very specific logic that will be hard to abstract etc.
Very good engineers are actually those that have come to understand how and why they have done that in the past and what options there are, or those that are shown through mentoring or code review or seeking out instruction on their own what different patterns and tradeoffs there are.
--
But that means nothing on the face of it, since every amazing engineer did those things at one point, there are plenty of things for "less skilled engineers" to do that need to be done and they can do very well while also being helped to grow and learn, and for all of us, even 10/20/30 years in, we are still facing not only the limitations of what we didn't know we didn't know in the past, but even the limitations of the languages and frameworks we are using, and trying to make those better.
--
I could also say that technical debt is the result of non-engineers prioritizing short-term features and bugs over long-term code quality and eventually everyone suffering for all the corners cut over the way - that's a popular one for the dev team, but what does that mean other than the people keeping the business going need this thing to happen and they don't care about where you put the logic, and if you want perfect code, please find someone to pay you to write it...
--
This conversation happens so often in so many ways, and I'm actually in a situation right now as a technical lead where my very real ask and complaint is - we don't actually have enough deeply competent coders that have done this enough times that can make this work. We need a few more people with those deep architecture eyes, and we need to trust that what they see as priorities actually are, not for this feature, but for every feature we might create 2/3/4 years down the road as we scale.
There is value in the simple truth that inexperienced or lazy or crappy coders write bad code. But if we take it out of the realm where that means those people are the problem, all that means is that to collaborate on a large codebase that is doing something in the world, we all need to figure out ways to put soft fences around people's weak spots, help them grow, and try to keep the balance of business requirements and technical debt and scaling and growing a team and hero coders and lazy coders and great product people and unreasonable product people etc etc etc in some sort of productive tension that never collapses under its own weight.
--
The most beautiful code I've ever seen didn't last beyond the MVP. The worst and the best code I've ever written happened in the past, and I don't understand how I could write such things.
--
Personally I think all teams could benefit from one day a week/sprint/month where every eng on the team just goes and makes something better than they know could be better. Cause everyone sees something ugly, but no one sees the same things, and we'll never agree on the priority. Regular time to go do things that are just "this is kindy sketchy and hacky or causes me pain every day, Ima go fix it"