So.. I kinda feel like I was invited to read this post ;). I think it understates the human dimension of software code quality problems. For example, I wholeheartedly agree with the unit testing recommendation, but I'd add that if you do it test-first you start by asking the question "what result would this code have to produce in order to fulfill the requirement," which to me is more useful than "does the code do what I think I just built it to do?" It also has some other benefits, like if you have to represent the answer to the question of what your code should do in code, a lot of times you have to have a really in-depth knowledge of the code your code interfaces with (which makes better engineers). And then there's the one where engineers actually don't know if their stories are finished, accidentally (?) kicking the can down the road to other engineers, while management thinks it's the later engineers that are underperforming. Assuming the engineers are marking stories done when the code doesn't accomplish the purpose (either because some criteria are missed or the code is just wrong and no one knows it yet) inadvertently, writing unit tests can help them think through what the code _should_ do so they know when they've done it. That's a basic skill that you'd think all engineers would have, but too many just don't.
The big problem with static analysis tools is they can point out the error, but if an engineer doesn't understand why the error is bad or how to fix it, he's just going to ignore it. I spent two weeks asking the nominal lead of a team I was on (where basically I just stole leadership in order to get the work out) to clear certain Typescript errors. When I finally went in to clear them myself, I realized he didn't know what the errors meant or what change to make to fix them. So I held a meeting that day to train the organization (of which my team was a small part) on those types of errors and how to fix/avoid them. And I think that's the biggest piece your post is missing--technological tools can only do so much to fix skills gaps. And I think the trick is figuring out how to address these in a way that keeps the team heading in the right direction (doesn't cause personal conflict and addresses legitimate concerns without getting off in the weeds with any stray idea someone has).
