A lot of these look like Goldilocks problems, e.g. > "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design wil

A lot of these look like Goldilocks problems, e.g. > "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses." A complex project with many people working on it in different teams calls for modularization and well-defined interfaces, so working out the architecture up-front does matter, and changing it down the line will have huge costs. Staged progession is the answer, probably, which is why you'd want to have a meeting where everyone agrees, "this is the architecture we're going with, now everyone go build the modularized widgets that fit into this architecture, here are the stable interfaces to build to." Screw that up and you end up with tons of wasted effort, but dithering around and never making a decision is no better. Some of the other stuff relates to the 'build team spirit' corporate mentality which is kind of culturally variable - some people love it and some people hate it. Minimal is better, IMO. Then there's the 'basic technical proficiency' category of problems, e.g. recompliling the entire collection of source code every time you make a lttle change because the build configuration in the makefiles is incorrect etc. That's probably the easiest category to fix, some people just have holes in their knowledge and those can be filled. Here is where the company jerk is a major liability, though - you want people who can teach others how to improve their workflows without engaging in any condescending / egomaniacal / prima donna behavior.