Principled Speed

Monday, February 15, 2021

I joined Sigstr fairly early on its journey, and for the first time, I was at a place early enough to help set the philosophy and direction of the engineering group.

We had a VP at the time who was very big on principles, and forced us to stop and think about them from time to time.

Looking back, those principles I helped set and wrote down are one of the prouder moments of my career.

And I wouldn’t have done this with Robert’s guidance and push.

These principles also accurately reflect where we were at Sigstr at the time - geared around speed of delivery, experimentation, and trying to build a learning culture.

I also remember some painful scars around a few of these principles …

Here’s what I wrote down at the time, feel free to use it yourself.

I fully intend to copy-and-paste it as a starter kit should I be in that position again.

Team Engineering Principles

This is a living document. More will be added over time. Last updated: 8/27/18

• Prefer boring over novel or clever.
• Assume code is broken until proven otherwise.
• Assume all input is malicious.
• Premature optimization is the root of all evil.
• When choosing a technology, pick the one you’re most comfortable with delivering business value in a timely fashion. When in doubt, or when needing to break tie, pick ones that more than one person on the team knows.
• Don’t write your own logger. Concentrate on building things that deliver core business value and rely on libraries and third parties for commodity items as much as possible.
• Everything should be able to be rolled back - whether through API versions, or more regularly, through feature flagging.
• Once code has been reviewed, it is every team member’s job to get that code deployed into production as fast as possible.
• Smaller is better - in tickets, in pull requests, in deployments, in services (maybe: Use bounded contexts and #team-platform principles as your guide here).
• Smaller, more frequent deploys are encouraged.
• One way or another, you’re going to be testing your code - either manually locally, in staging and in production, or through automated tests. It’s better for everybody involved - you, your coworkers, the business, our customers - if that testing is automated.
• That said, automated tests do not replace actual confirmation that our work is correct.
• Related to the above, when fixing a bug, write a failing test case first.
• What we hand off to QA or UAT or customers is - to the best of our knowledge and efforts to confirm - correct and ready to be in production.
• If a PR has no tests, a reviewer has every right to reject said PR at their discretion.
• Work with empathy - for your coworkers, for your future self and for our customers.
• First you make it work, then you make it fast, then you make it pretty.