The most carefully-constructed, architecturally-pure piece of code will still break in the face of future requirements. And in a surprising number of cases, it

The most carefully-constructed, architecturally-pure piece of code will still break in the face of future requirements. And in a surprising number of cases, it will break on the very first new requirement. Keep it straightforward and get it done. You will almost never be working on something so performance-critical that it truly needs cleverness and super-optimization. And you will rarely have time to properly measure a particular thing anyway. You will be expected to frequently change things and super-optimal code is a pain to modify. You will work with programmers with a variety of skills and it will often be impossible for them to maintain things of moderate complexity. Or, your team will be using ancient tool versions that can’t reliably do the spiffy new thing in the language. Again, straightforward code wins. When you write a test, first set up a case that fails to make sure your test can actually catch a failure. Too much time is spent debugging things because tests “pass” when the tests themselves just weren’t doing what they meant to do. The code is king: put everything you possibly can in there (comments, etc.). Don’t let people set up external documentation that no one reads, because it becomes wrong/misleading within a day. If you must have things outside the code, they need to be revision-controlled alongside the code, in the same repository.