Our Engineering Principles

As a new team comes together, common ground is really important. The principles you all consistently care about.

For an engineering team, this normally falls into three categories

• How we function as a team
• How we build things
• How we run things

In past roles I’ve waited for the newly formed team to gel before running a workshop on the subject. With Mind Gym we’ve tried something a little different

Photo by bady abbas on Unsplash

There is a simple Confluence page that is linked from our Day One Engineer section with the headings above and two instructions

1. Add two engineering principles that you really care about
2. Challenge any principles that you think either don’t hold water or should be refined (this is a safe space)

This gives us an easy way to accumulate principles from day one (making important decisions without the need for a meeting is really important in distributed teams but that’s a topic for another post).

We’ve agreed on some foundational principles and we think they are worth broadcasting outwards. If you’re considering joining the Mind Gym Engineering team, expect to see yours incorporated here too.

How We Function As A Team

• Blameless Culture — Assume people are doing the best they can with the information they have. People can explain why the action made sense to them at the time, without feeling insecure or judged. Focus on the system, rather than the person. Dig deeper into what caused the problem. Organisations can only improve by constantly seeking out their systematic vulnerabilities.
• Understand that everyone has different levels of knowledge — Engineering is an enormous field; every one of us knows something that others don’t, and every one of us doesn’t know something that others do. Understanding this means never asking “How don’t you know that?”, and instead being happy to explain any knowledge gaps that come up. This also means understanding that other people don’t know what you do/don’t know. If you need more information on something, ask! Otherwise everyone will assume you know and it’ll be more difficult for you to ask later.

How We Build Things

• If it is difficult, do it more often, earlier and automate it — Automate builds. Automate tests throughout the pyramid (including static analysis). Automate provisioning. Automate deployment & configuration. Put feedback from all of the above in the eye-line of engineers
• Don’t build it unless necessary- If there is a great open-source version don’t build it. If it isn’t a real requirement don’t build it If you don’t need it yet don’t built it
• Languages & Tools — We currently use [HTML, SASS and Vue on the front end, NodeJS on the back end, Typescript in both, Python for data engineering, Storybook for UI components]. We’re still open to new things. Here is our stack share by the way
• Think of the next engineer — Think about your code from a “What would this be like if I was seeing it for the first time” perspective. Everyone who sees it after you will be seeing it for the first time, and after a couple of weeks it’ll feel that way to you too! If you’re having to do something weird because of some constraint that you found out whilst writing your code, put an explanation in! (But, if your comments can be coded instead, prefer that)

How We Run Things

• You Build it, You Run It. Assume every commit will go to Production shortly. Don’t rely on someone else to do the testing — don’t throw things over the wall to a QA team. If something breaks, the person who wrote it will most likely be asked to fix it. Don’t let things break at 2am on a Sunday morning.
• Write down what we’ve done — If you’re investigating an operational issue, don’t just write in the ticket that you discovered X. Write down the command you ran and the output you got that made you deduce X. You’ll thank yourself six months later when the issue reoccurs.
• Running workloads — Workload goes in Kubernetes by default. Out of the box this gives us 👍 mutual TLS between workloads, Good observability, Telemetry in Grafana, Logs in Loki. Let’s have a discussion about trade offs for anything outside of this
• GitOps — Git is our source of truth. We don’t hack workloads/deployments manually to fix anything. Every change is in git and deployed through our tooling.

This is everything we have so far. I really like that it has grown organically and is a reflection of the team’s composition at this point in time. As the team grows even more, we will likely find that it becomes too large and unwieldy. We will then need to find a way to refine and keep things succinct.

This is a future problem though. For now these are our principles.