I've been feeling a lot of anxiety from this. It's affected my sleep, even during vacation. I'm waking up in the middle of the night thinking about it. I've been nearing burnout for a lot of reasons recently, and I worry this could push me over the edge.
I think the main anxieties stem from:
* Not being able to have pride in my work, which is undermining my confidence. It's always been important to me to feel good about my work.
* Fear of how this code will bite us in the future.
* Feeling shame around my peers. It makes me feel really dumb around smart devs that I like and respect. (I almost feel like crying while writing this out.) I have already heard rumblings from team members about how bad certain things are, and it makes me feel stupid and incompetent. It hasn't been their intention to shame, but it still hurts because I agree with them. But they don't have a full understanding of all the many factors that led to this.
There are a lot of reasons this happened (including some poor early decisions that I'll take full credit for, a complex and changing feature set, pressure to hit a hard deadline, building on top of an existing codebase with many legacy issues, team politics, and concurrent personal issues), but those are the things nobody sees when they look at a git blame.
I've got 10+ years of professional experience, so I've shipped plenty of substandard code and been through all of this before. I know a huge portion of code in the world is bad, and this should all be old hat by now. But it's still never caused as much internal angst as this.
Some possible paths forward I've been thinking of:
* Just make the code better - I can do small bits progressively, but a major refactor has been shot down by leadership at this point in time. And the undermining of my confidence is filling me with the fear that I'm not even capable of this. Maybe if I can just slowly keep getting small wins over time I can build my confidence back up.
* Documentation - for the things I can't fix, at least document what the current state is, to provide help and background for future developers.
* Therapy - I'm already in therapy, and will bring this up. There are some obvious "self worth" issues tied into this, with me attaching my worth as a person to the quality of my code. Maybe my therapist can help with this.
* Stoic exercises - I can't change what others think about me or my work, so I can try to not let it bother me. (Easier said than done. Stoicism has never worked super well for me.)
* Find a new job - maybe I just need a new perspective and a fresh codebase. (This would be a challenge right now.)
Would love any advice or similar experiences HNers might have!
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.
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.