Our Engineering Principles

1. Release fast and iterate.

The only way to find out if and how customers will use what we ship is to see how they engage with it. The sooner we get something out in the wild, the sooner we find out if we’re building the right thing or not and the sooner we find out what they need next.

2. Own what you create.

We are not Engineers bashing out code to spec, we are stakeholders in what we create. Finding a problem, finding a solution, building a concept and owning a product or future after release are at the core of how we operate.

3. Take initiative, think about the business.

When we start looking at a product or feature, we always think “is there a quicker thing we could do which would get nearly the same thing in the hands of the customer”. We will never start work on the anything without first having a full understanding of exactly what the business reasons behind it are.

4. Make small changes, often.

Small things tend to break in small ways, big things tend to break in big ways. If we can come up with a way to release something as lots of small pieces, we should. The “big unveil” should be avoided.

5. Create technical debt with care.

We understand that we incur tech debt for the good of the business by building products faster. We also understand that tech debt left unchecked will be the ruin of a codebase and exponentially slow down new features to a crawl. When we create technical debt for the sake of speed, we should do it mindfully and knowing that we will need to either remove / refactor that code or pay back the technical debt in the near future.

6. Don't optimise for the sake of it.

We should always try to make time for optimising and refactoring code. But, we should not optimise or refactor for the sake of it. We should always quantify the impact first. If it’s performance related, this should be done with appropriate instrumentation, if it’s code quality we should consider the importance of the code and its impact on other features.

7. Be clear, not clever

Your code is your legacy to the next developer, who could be the future you. You should assume they are a knife wielding psychopath who's having a bad day. When we write code, we should make it as clear as possible. Ideally this should be in the form of readable code, not comments. Other developers need to understand what it’s doing and comments degrade with time. It may well be you who needs to understand it in six months time, if it is, you’ll thank yourself, if it’s not, someone else will thank you.

8. Be a good gardener.

Moving quickly doesn’t mean we compromise on code quality, readability and maintainability. When we touch a piece of code, we should leave it in at least as good a condition as we found it, ideally we improve it. If we see something that’s in need of a refactor, it doesn’t matter who wrote it originally, a refactor is always on the cards, no part of the codebase or stack is sacred.