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.
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.
Move fast and break things is a motto for startups that might not be here 6 months from now. Speed is important because surviving as a business is the most important priority.
What other software is there that has to deal with such diverse user input and diverse expectations of output? Even Apple had problems with just autocorrect for the typing of messages.
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.)
I'm slowly getting folks to put more in the commit message, but leading by example is taking forever. :(
However, unless the single line is "fix typo" or some such, often I'm very interested in why code has been sent up for review. And don't just tell me what you did, but why you did it. If I get one more "increased the retry policy" style messages that doesn't expand on why a downstream component needs us to retry more, I'm going to go insane.
A sister team of mine has gone so far as to templatize this. I'm very sympathetic to the idea, but I don't support it yet. I think I'm coming around, though.
'In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile software development, calling it "yet another attempt to undermine the discipline of software engineering" and translating "Working software over comprehensive documentation" as "We want to spend all our time coding. Remember, real programmers don't write documentation."'
Having a solid infrastructure with failure mode and behaviour that is expected saves a ton of hassle and makes ops "easier".
most of the time, having everything redundant to the level that stuff doesn't break is simpely not possible, so its better to make it break reliably. (a good example of this is hard crashing applications on errors which could manipulate data, instead of trying to continue. This makes your failure behaviour consistent across the enviroment).