It's often a source of tension when someone joins a new team to have them racing in to fix all the "technical debt" whose origins the new engineer really doesn't understand. Little is gained by assuming that technical debt stemmed from bad engineers, and a lot can be lost if you misjudge.
I shit you not I once saw the following in an actual codebase.
var len = Int32.Parse(myString.Length.ToString());
I can maybe understand that code evolving to that over time, no way in hell is it a good engineer who put the final adjustment in and thought that was fine. Don't even get me started on systems that are overly stringly typed.
What the other poster said is absolutely true, a good design can turn bad if it doesn't adjust as the business changes. Too many developers think the point is that the initial design should survive first contact or it was bad code, but that thinking is too static. As Mike Tyson likes to say, everyone has a plan until they get punched in the mouth. There's nothing wrong with evolving a design over time, and doing so helps others to be able to recognize good code from bad code.
Easy to solve debt tends to be about "bad code". Fun debt is usually about code design. Real fun, grown-up technical debt is mostly (but no always) about architectural characteristics. Code evolving has to go hand in hand with an evolving architecture, otherwise you're just cleaning the kitchen floor while everything's on fire.
All problem code is not technical debt.
https://www.castsoftware.com/blog/ward-cunningham-capers-jon...
One day every two weeks is not enough. Better a week every 2 months.
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"