"Go fast and break things" works for companies for Facebook for a lot of reasons. First: $, which they have a lot of. You can literally afford mistakes. Second: Monopoly, which they have a lot of. You can figuratively afford mistakes because your user base won't go anywhere.<p>If you're not operating at FB scale, quality is often your best asset. People tend to choose things that "just work". Getting things to the "just work" phase takes discipline in developing and testing.<p>If I could add one thing to the list, it'd be "stop writing clever code". Rather than finding a unique solution that shows your technical prowess, write code that's boring but clear in its intent.
The point on commit messages is mind boggling to me. I have yet to join a team where I am not the first one that uses non single line commit messages.<p>It is even crazier when they do write some about their commit, but only in some stupid review tool where I then have to follow a bloody link to get to it from the commit itself. (I'm curious if some jerk thought referral links would help them know when reviews were useful later... Please let that remain the idle joke that it is, btw.)<p>I'm slowly getting folks to put more in the commit message, but leading by example is taking forever. :(
I subconsciously read that title as: "From Code Cowboy to Architecture Astronaut".
Realistically you want to be somewhere in the middle, DRY and all, but ship your product often, first of all.
If you don’t want nightmare operations scenarios, you have to document things. This doesn’t reconcile well with Agile/DevOps/Scrum mentality.