That's good, because it's developers that make it in the first place. If you need to talk to your manager about getting time to fix it - same with e.g. unit tests - something went really wrong somewhere.
> because it's developers that make it in the first place
I've inherited quite a few projects riddled with novice code; and code by developers who just fundamentally didn't understand critical concepts.
Especially as a newcomer, this is a topic that needs to be handled gently. Sometimes this requires correlating known flakiness with problem areas.
One word of caution: If the developers who made the debt are still in the organization, and oblivious to the problems they created, assume that your manager is also oblivious to the problem. It may be best to leave quickly, or feel out upper management to see if they agree with your assessment of problems.
I don’t know how common the following is, but I have more than once created tech debt under duress from management. It seems to happen more frequently with a system already deeply in debt: slapping on another band-aid or bolting on another sidecar are both faster to do right now, and right now is when the fix or feature is ”needed.” We could always circle back and pay down the debt in the mysterious future “when we have time,” which never seemed to materialize.
Not disagreeing that that means something went really wrong somewhere, just wondering how common the situation is.
I've inherited quite a few projects riddled with novice code; and code by developers who just fundamentally didn't understand critical concepts.
Especially as a newcomer, this is a topic that needs to be handled gently. Sometimes this requires correlating known flakiness with problem areas.
One word of caution: If the developers who made the debt are still in the organization, and oblivious to the problems they created, assume that your manager is also oblivious to the problem. It may be best to leave quickly, or feel out upper management to see if they agree with your assessment of problems.