A famous project without Engineering Principles

Engineering Principles

I’ve been building software since 1997 (even earlier if you’ll allow Pascal and Basic). I’ve built alone. I’ve built on teams of thousands. Those years of toil have taught several lessons. I’m going to share them with you, dear reader. You’re going to take them to heart.

The three chief virtues of a programmer are: Laziness, Impatience and Hubris.
-Larry Wall

Check out that hubris in the first paragraph! My laziness guided the creation of this list, so I could link engineers to my organizational thoughts. It has had many incarnations: a .txt file, a markdown file, a wiki page, and now a blog post. All incarnations until now have been private to the development team I was running at the time. There’s a lot of content on the web for engineering leaders, but most of it is aimed at the leader or the developer, not the entire team. This is aimed at the whole team.

Stating your principles as a team allows an amazing optimization: high-coherence decision making, sans hierarchy. In other words, if your team knows and follows the same guiding principles, they will make the same decisions you would. This means I (the lazy manager) don’t have to micro-manage things. It means I’ve communicated what is important to me as the manager, and those things were ratified by the team.

These principles are alive. While they are a snapshot in this blog post, their true home is a git repository, where pull requests are welcome. We even have a slack plugin that lets us reference them via number or full-text search.

They have changed at every company to which I have introduced them. Without further ado, I present our engineering principles. May they serve you well!

1. Build what matters Engineering effort is a scarce commodity. It should only be applied to problems that “move the needle” for the company.
2. 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.
3. 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.
4. Don’t live with broken windows Fix bad designs, wrong decisions, and poor code when you see them.
5. Don’t repeat yourself Every piece of knowledge/process must have a single, unambiguous, authoritative representation within a system.
6. 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.
7. 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.
8. Be a craftsman 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 lunch-talks on things you’ve made.
9. Protect your culture A diversity of opinions is a good thing. 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.
10. 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.
11. 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.

Each of these principles probably deserves its own blog post, but I’ve seen good results come from simply stating the following: “These principles as laid out are a starting foundation to what’s important to this team. What has been important in the past, if still relevant, can be added to this list. This is what we value, this is how we make decisions.”

In my experience, what follows that statement is a discussion of values that every team member has but have never been codified in such a way. Introducing principles (these or otherwise) always leads to higher coherence.

If you’re not enjoying your particular tower of babel, come work with me! I’m the CTO of Handwriting.io and I approve this message.