The Constitution of Engineering

Eight principles my team uses to guide our decision-making, enabling us to move fast with quality and integrity.

Note: As we originally wrote these principles for a team of iOS engineers, some of the language has been modified to suit a broader audience.

1. Champion the Customer Experience

The customer experience takes priority over any technical or product limitations. Each developer is a champion of the customer experience and uses the application regularly to understand the customer experience. The customer experience is not compromised for any reason. The application delivers a high-quality, native experience that customers expect from any well-made application, and developers advocate for an everyday customer experience.

2. Build from Knowledge (not Assumptions)

Your system makes no assumptions and is built on knowledge and understanding. An assumption is turned into knowledge and understanding through research and investigation. If you cannot reasonably confirm an assumption, your system ingests ambiguity and outputs well-defined behavior.

3. Exercise Every Line

You can execute every line of code during the execution lifetime of the application. No code exists to handle a theoretical scenario. Your system is designed to fulfill the requirements of the feature, and nothing more.

4. Build Resilience for Unknowables

Your code runs under suboptimal or exceptional conditions. Under these conditions, a good customer experience is maintained and meets our quality standards.

5. Be Accountable

You have personally tested your system. You have written automated tests to show that every piece of your system works as intended at all times. You seek feedback from your reviewers, testers, and customers. Your system is monitored for crashes, warnings, poor customer experience, and other unexpected metrics from day one, and you closely follow those metrics. You know the health of your system better than anybody else at the company.

6. Move Code Upstream

There is no logic in the client application that can be done on the server. There is no logic in the client application that isn’t specific to that client. Or you have done everything in your power to avoid these scenarios. Where any of these scenarios is unavoidable due to limitations outside of your control, you have made a plan to rectify the infraction.

7. Build for Each Other

Your system uses pre-established and accepted patterns and idioms. Your system is decoupled from other systems; As the application evolves with the team and the organization, your system, or parts of it, can be deleted with minimal effect. There is only one way to use your system, and it is documented. You follow best practices defined by the team and the developer community. Your code is well-documented, and decisions are clearly explained for the next developer.

8. Solicit Feedback

You’re proud of your work but not protective. You actively and frequently solicit feedback from your colleagues, including (but not limited to) designers, product managers, and engineers of all levels. You understand that a review of your work is an opportunity to collaborate and gain insights from the diverse experiences of your team members.