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.
