I generally agree with most of the ideas and recommendations in this article with a few exceptions. I agree that resisting the urge to rewrite bad legacy code is difficult, especially if you are the one inheriting the code. Not only do you have to maintain it, it is now your name at the top of the blame game. You must however resist that urge! Having said that, there is a right and wrong way to approach legacy code. Do fix formatting. Do add logging. Do refactor obvious abuses of good practices when fixing a bug. Do document what you can. Do add TODOs. Do run a linter to identify issues ( but tread lightly "fixing" anything). Don't change logical constructions. Don't untangle complicated code (yet). Don't throw new exceptions, but try to identlfy places where exceptions are not handled properly for later refactoring.

I'd also say that the advice to "not complain", while not wrong isn't sufficient advice to someone who is tasked with the pressure of having to descend down a labyrinth of rabbit holes unraveling mystery after mystery. Complaining can be cathartic and some slack needs to be given depending on the sitaution. Limited complaining is ok in my book as long as it is accompanied by some positive action and recommendations. As the author mentions, you should point out deficiencies - do a gap analysis between the current state and a better state - publish it - update it. That is a positive, productive way to "complain" that helps you (and everyone that hears your complaints) deal with the burden of adopting really bad legacy code. It also can buffer you from unfair criticism or potential "blame". Your recommendations and findings are now on the record and you and your boss or team can decide how to address the backlog.

Lastly, I don't agree that "everyone writes the best code they can at that point in time". It's a nice sentiment. I agree that the majority of people really want to do a good job but that's not always possible. You should never assume that bad code is just bad for no reason - there are many compromises and situations where what might look the correct approach is just not possible. In other words, reserve judgment or just don't judge. My disagreement on this point is based on my experience - there are programmers that don't study their craft, seek guidance or believe in "best practices". There are many "write and forget" folks out there just itching to create what will eventually become the proverbial BHBOW (big hairy ball of wax). Unfortunately a lot of these people are prolific, smart, effective in creating something that solves the immediate business problem and almost always very self-confident. Bosses tend to leave them alone to do their thing so they are not recognized for what they are (purveyors of unmaintainable code) until they decide to take another job.

I'd also tell people that maintaining legacy code can be rewarding, educational, satisfying and yes lucrative.

Don't think you've been handed a big steaming pile of poo when what you've been handed is an opportunity.