Document everything over time, so you can show why you did "X" before you were told about "Y". Also document that you offered to do a rewrite but were rejected. Don't be afraid of naming names--not in a vindictive way, but very matter-of-factly.

Engineers love to whine about other engineers' code, especially when they don't understand it, regardless of how well or poorly it was written. Ignore the haters. Ironically, it's the ones who complain the most who usually know the least.

If your code works, there's probably little chance anyone will authorize any kind of incremental rewrite since a) it costs money (your time), and b) it will require testing (again, more money/time). Don't sweat it. Your code will join the huge, largely unseen iceberg of substandard code that underpins just about every project in the world. Welcome to the club!

Also worth thinking less about how it affects you, and more about how the customer/client/users feel about the work done. Do they appreciate your efforts? Are they happy with the work you've done? If so, you can look on the positive side there and say that you made someone else's life better, even if you're disappointed in the specifics of the way you achieved that.

Plus if you keep thinking this way, you're gonna get more and more depressed in future, since there will always be code you're not proud of and feel could have been written in a better way. You shouldn't be treating this as a reflection on yourself, especially not when it's likely a product of the circumstances and appreciated by those you work for/with.

As for what you can do going forward... I guess all of that stuff? Gradually refactoring small parts can work, though you may want to leave it a bit and come back in future. Documentation will always be useful, especially if you explain why you made the decisions you did, and how it could be improved. And therapy is probably important here for sure, if you're tying your self worth so heavily to your work.

> Is it genuinely bad code, or code written under limitations? Plenty of great developers and engineers code things poorly when either under a time crunch/stretched for time, with a limited budget, with dozens of other things on their plate, based on manager suggestions, when tired/burnout, etc. Maybe it's just the best that was practical within the current situation or based on what you knew at the time. No need to beat yourself up about that, everyone ends up in those situations.

Definitely written under a lot of limitations. It was a large feature with a difficult time crunch, and very limited dev resources. I did make some poor decisions early on, too, but I do feel that I did the best I could.

I think the major part of my current anxiety is really the "feeling stupid and incompetent around other developers on the team" thing. Especially the ones who will have to build on this thing in the future. So I can forgive myself for not being perfect, but I'm still sitting with a feeling of shame and incompetence.

When I talk with other devs and they mention how we should have done things a different way and that the current pattern is bad, I get two major thoughts / feelings:

* "They're totally right, and I really am fucking stupid"

* "They don't understand the pressure I was under or the context in which those decisions were made, and it makes me a bit angry to have my work judged harshly without knowing what it was like to be put through this"

> and more about how the customer/client/users feel about the work done. Do they appreciate your efforts? Are they happy with the work you've done?

Thanks for the reminder, they are happy with it! That's something to be proud of.

> You shouldn't be treating this as a reflection on yourself, especially not when it's likely a product of the circumstances and appreciated by those you work for/with.

Thanks for this reminder as well. I know I shouldn't treat it as a reflection on myself, but it's hard to convince my brain not to. Something to get help with in therapy I guess.

Why? Ask. Maybe it solves problems well enough and maintenance costs are low enough that they'd rather you were contributing to Y instead of reworking X to be better for programmers but not have a noticeable impact on the bottom line. Understanding where that functionality fits into the business model will probably help you understand the development constraints better and worry less about the issue. It might also indicate that the management are being shortsighted or not really listening to feedback from their engineering people.

If you hear a negative comment from someone else, it's good that you realize it's about the problematic code rather than you. You could (again) ask how they'd approach the issue, given that you can't get resources to cover the cost of a refactor. Maybe they can team up to persuade management? Or maybe they can suggest a way to get it done faster. Maybe you can prototype the better version and then use that to change the suits' mind. Meantime, if your fellow team members don't have a full understanding and they are not the ones who had to land the plane, then you should discount the weight you assign to their approval.

- Everybody writes bad code, and you learn and get better as you go along. If something is bad and you can see that and take responsibility, that sounds good, and it sounds like you have learnt and become better. You don't need excuses like "personal issues".

- You aren't always going to be as smart or good as your colleagues, sometimes you just have to come to terms with that.

- Major refactors of a product are rarely the right way to go. If you can do it progressively and gradually that is almost certainly the better approach.

- Almost zero percent chance you will find a "fresh" codebase in any new job. A change can be helpful, but it doesn't change yourself.

Good luck with it. Happy New Year.

For what it's worth, that was not an excuse I would give to anybody on the team, but just an honest look at one of the underpinning factors that I can more easily bring up in an anonymous forum. I can do better than I did, but I was barely keeping it together mentally for large portions of this year.

> Almost zero percent chance you will find a "fresh" codebase in any new job

I mainly meant fresh as in "fresh / new to me", rather than "fresh / pristine" codebase (which doesn't really exist).

> Good luck with it. Happy New Year.

Thank you!