"often someone not being trained properly, or leadership that decided to make a deadline no matter what"
> That can be extended to the rest of the team or management around the worker(s) for not providing a guidance/help.
I indicated this isn't always/necessarily one person's fault.
re: your senior dev. he might be correct that their code sucks, but he's also being an ass in his own right.
I've told this story a few times to folks where... in 2017, I was contacted by someone who said "the system stopped working". Turns out it was something I'd built in 2002/2003. It's eye-opening and humbling to go back and fix your own mistakes from 15 years earlier.
> The less forgiving someone is the more likely that their code and architectural decisions suck even more than the people they're complaining about.
I don't disagree. It's why I tell people to document as much as they can - document the meetings behind decisions, document the rationale for cutting corners. It will help YOU later on when you have to go back and can't remember why you did XYZ. (See above reference to 2017/2002).
I fully realize my stance comes across as offensive in some situations, and I do not always project this stance. I'm fully aware people are forced in to bad choices some times - I've done it myself (on both sides of the table).
However, I'm also often coming in to situations where I have nothing more than running code and a client wanting stuff done. My scenario above about no tests, no sample data, no testing process, no documentation and no previous dev to consult with... it's probably been more than 50% of the projects I've worked on in the past 20+ years. Clients/employers also read some of the same blog posts, and will sometimes throw out the "you shouldn't just rewrite stuff!" line (often while simultaneously telling me stuff is broken but "used to work 2 years ago"). These are sometimes 'dailywtf'-level projects, and if the primary goal is to make sure data and processing works as people need and expect today, large/wholesale overhauls are often necessary.
I've been on a short term project with a team the last few months and this is 100% different from many previous projects. There's 30+ tech folks, I'm on a team of 8, a mix of jr/sr folks, decent communication, a moderately large (and up to date and growing) test suite, test data, some documentation (could be improved), but generally all good people. I've seen some evidence of the "I'm the awesomest" dev work in the code repos, and those people are no longer around.
I'm not coming in to this project saying "everyone before me sucked ass and I'm a dev god". mostly because it's nowhere near true, but the process of getting stuff done is more team oriented - there's people to help, people to review, a good culture around the project, etc. There are problems but nothing like some of the other scenarios I listed above. So... this is the sort of scenario where it's a appropriate to respect the other folks, previous code, process, etc - it's all there and there's a defined way of working and getting better. Not all projects are like that.
FWIW, to the extent I find myself complaining about "other people's code", it's usually just a prelude to complaining about the processes which led to it. Why is someone being told to do XYZ without any context? Why are they excluded from decision making meetings, but given full responsibility for hitting a deadline they can't possibly meet? These aren't questions for the dev who wrote the code, but for the project management which led to that.
Example: Was brought in on a project with horrible code a few years back. Utter garbage - everything was NIH - they'd built everything from scratch. Digging a bit further, I find out that all dev and server boxes are limited from hitting the internet. No package managers work for anyone, so they build everything from scratch. Exceptions could be made - in writing - and within a few days or week or so, you might have someone pulldown and compile resources from a 'blessed' connection, then give you that code to run yourself. Things like encryption/decryption algorithms were being written by hand because it was the only way to hit deadlines in that working environment. Yes, it's literally insane to try to work that way, but I had a team of people who all did that, and felt trapped. It wasn't their fault entirely (excepting that they should have all just quit at once, or threatened to) but day by day things just got worse. Poor management was the root, not the devs - the bad code was just a symptom.