Build what matters Engineering effort is a scarce commodity. It should only be applied to problems that "move the needle" for the company.

Be a scientist Science is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe. We should base our decisions on objective data obtained through research rather than hunches or superstition. To improve is to change.

Know your enemies Conway's Law, sleep deprivation, subjective beliefs, lax validation, crappy dependencies, unreliable networks, scope creep etc... Know them and have a plan to beat them.

Always leave it better than you found it Fix bad designs, wrong decisions, and poor code when you see them. Broken windows lead to more broken windows.

Don’t repeat yourself Every piece of knowledge/process must have a single, unambiguous, authoritative representation within a system.

Clear Code Beats Clever Code Don't write code you can't debug at 3AM while drunk. Never name a variable 'data' or 'info'. If the implementation is hard to explain, it's a bad idea.

It’s Both What You Say and the Way You Say It There’s no point in having great ideas if you don’t communicate them effectively. Be conscious of both your words and your tone.

Be a Craftsperson Craftspeople of an earlier age were proud to sign their work. We should be, too. A product's quality is only as good as its weakest part. This can manifest itself as well documented modules, open-sourcing our tools, or just giving brown-bags on things you've made.

Protect your Culture A diversity of opinions is a good thing. An objective respect for the scientific approach to finding the best answers to organizational problems leads to a stronger bond between all of us. Only hire people we would want in the office tomorrow.

Collaborate, Don't Corroborate Asking for input on 80% done work isn't fair to the reviewer. Don't get peer support just to make yourself feel better. Encourage peer support when you're 20% done, to allow for more meaningful collaboration.

Don’t Gather Requirements, Dig for Them Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics. To think like a user, work with a user.