How terrible code gets written by sane people

How do you check up on that reviewer? In you system, he has power to fire people, decide all standards+code style+architecture by himself and force that upon everyone else. All that with no accountability nor responsibility.

* Giving excessive importance to estimates

Seen this one. It was used as a excuse not to do code reviews because they cause to miss estimates. "Look, the feature is done, but because of the code review requirement I cannot mark it 'done' in the project plan." Solution: abolish code reviews.

* Assuming that good process fixes bad people

This one is a big one. It's everywhere. Especially in big software development companies, such as Microsoft and Google. They tend to believe that once they institute a perfect process, everything works out perfectly. Perfect coding guidelines lead to perfect code, no matter who writes it. Perfect testing process - testing can be done by monkeys. Perfect project management process - now we can hire project managers with just basic Microsoft Excel skills. They don't understand that without actual talent the company enters a "spiral of death" which is impossible to escape.

* Ignoring proven practices such as code reviews and unit testing

This is done frequently by people who never tried such techniques as code reviews and unit testing. If you do it consistently through, say, one release cycle, you start to value those techniques and understand their importance.

Unit testing, for example, helps me to avoid painful debugging complex issues in production. All features that I unit tested usually just work when integrated into the rest of the product. In fact, the last bug I had to fix happened in code that I neglected to unit test, because the unit test setup was too complex for that component (in itself an indirect sign of a problem). Unit tests also lead to components usable independently of each other, thus reducing the overall system coupling.

* Hiring developers with no “people” skills

This is a double edged sword. On one hand a developer who can't communicate well will eventually produce code that doesn't do what's intended. On the other hand there are people with too much "people" skills who can't code shit. They just bullshit their way through. I'd say there are too many of such bullshitters. A lack of communication skills in a developer is a problem fairly isolated to that developer. A lack of coding skills in a bullshitter is much bigger problem that affect many people around him.

Pretty much this. Sometimes pushing back is needed, but way more often "negotiation" is needed. It is unreasonable to expect managers to magically see into the development details, you have to explain, made plans transparent etc etc. When you do that you often (not always) find that requirements are negotiable and not equally important, e.g. it is possible to meet the deadline without sacrificing code quality. Oftentimes the compromise is possible - you wont get two week straight of refactoring, but they are ok with using 20% of development time for cleanups.

I have seen developers "push back for the right thing" in a way that basically amounted to angry emotional outburst over things manager did not understood. The dude thought he is pushing for the right thing, but everyone else thought he does not listen to their needs, refuses to follow the company vision of the product replacing it by his own. (They wanted simplest possible functionality and fast, he was constantly adding own requirements to "make it better". When the same person pushes for yet another refactoring, management does not trust him.)

The other thing to understand is that some experienced lead remembers teams that were given time, no deadlines and all the good stuff and then produced mess anyway, procrastinated and took long time to do it. I have seen that happen and I have also seen that ended in long wars over petty differences in style and opinions. Sometimes the mess is result of people doing something knew and thus bad decisions along the way. Code review alone wont solve that, because the reviewer may be the one forcing mistake on others.

You need to communicate in the way that will ensure the manager that he or she is not in the above situation.

> When I found out I would be working on porting an old Python codebase to Node

"Out of the frying pan and into the fire" is not a programming direction I would recommend. (I don't think I've met a single Node developer who isn't bitching about it.)

There should be no need for 'wars' or even 'negotiation'.

It's the managers decision - not the developers, really.

The devs can lay out what can be done, and describe what the results will be if various paths are chosen.

'Skip the tests' - you get quality issues, but better schedule.

'Write perfect code' - you get quality, but it could take to long.

The old saying: 'fast' 'quality' or 'cheap' -> pick 2.

If your team is having problems because of bike-shedding over details, or messed up code - this is altogether another issue and needs to be addressed differently.