Learning to deal with "unmaintanable" codebases is a pretty good skill. It taught me good documentation and refactoring manners. It's only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.

Code should scream it's intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don't). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today's version). Tests are documentation. Often the only up to date one?

[–] corytheboyd@kbin.social 11 points 10 months ago

This right here. Get good at navigating code of questionable quality that you didn’t write. If you can’t do it, start questioning your tools, and mastery of those tools. For the big boy jobs, you should be working with existing code much more than writing new code. Learn to get excited by tweaking existing systems with a few well placed, well researched changes, instead of being The Asshole that adds a new abstraction wart.

[–] Smoogs@lemmy.world 4 points 10 months ago

I’ve known influential assholes who poopood commentating as if it’s only a superficial job.

I hate those people.