[that_guy_iain]

Yea. There are some people who love to sit there and think everything out and draw on whiteboards during meetings for hours, have multiple test envs, have QA run over everthing, make sure their commit messages are all the same format and have lots of information, roll out a feature slowly to find bugs before it hits everyone.

Then there are people who want to get a feature done so they can see if it has any value. They would rather build something and then redo it later if it turns out it's not correct. They never read the commit messages so don't care about how they're formatted.

One is make sure everything you do is really good and the other is move quickly and break things. One side is "We don't need to rush bug fixes because we never release anything majorly broken" and the other side is "It's faster to rush a quick bug fix than it is to spend 6 weeks rolling out a feature." Both have their pros and cons. And depending where the company you're working for is in their lifecycle depends on what sort of development team they should have. Facbook for example should be spending large amount of time ensuring things work properly. While the 6-month startup with 18 months runway should be moving as quickly as possible to figure out what works and what doesn't.

Some people prefer one method over the other. Some like the middle ground between the two. Everyone is different. If a developer is one a team and doesn't like where the team is and how they act is normally better to just get another job. Very rarely is a company going to get rid of an entire dev team which is what would be required to change the culture quickly. And from experience, there isn't much worse team wise than having someone go on and on about commit message standards, code style, etc when half the system is basically on fire.