In 2016, we put down our 10 (base 10) Engineering Commandments, the values that our Engineering Team uses to guide its work. We didn’t use a long, complex process to create them. One of our first engineers sat down and took some time to articulate the ideas that we should use to guide our decisions, all based on industry best practices. He published them on Slack for feedback, and they took off from there.
Two years later, these commandments are the backbone of our engineering culture. They’re nothing fancy, just a set of basic expectations that we all try to follow. But we’ve found that the list helps all of us — no matter how young or old, new or senior — build better solutions faster.
We use our 10 Engineering Commandments to onboard new team members and help them avoid common engineering traps. They help us communicate better and make tough team decisions, all based on a common set of guiding principles. They even help inspire and guide us when we’re stuck or in doubt.
We hope they help you too, whether you’re an engineer interested in working with us or you’re forming your own team’s engineering commandments!
0. Coder != engineer
Jumping directly to writing code more often than not leads to bad code and bad engineering. Most battles are won in the mind and on pen and paper before they have even begun.
Coders focus just on writing code to make something work. Engineers take a much wider view, focusing on both the problem and every aspect of the solution. They break the solution down into smaller components, all with the larger picture in mind, and figure out how they’ll all come together in the end. Engineers build for scale and sustainability, rather than just creating a short-term solution.
1. “Import lib”
Life is too short to reinvent the wheel. Don’t waste time building your own tools or libraries if there’s already something that does the same job. Wherever possible, extend existing libraries and contribute back. This helps you get a clear picture of what other people’s work does and how it fits into what you’re building. It also lets others benefit from your work, just like you benefited from theirs.
2. With great power comes greater responsibility
“As a programmer, never underestimate your ability to come up with ridiculously complex solutions for simple problems.” – Thomas Fuchs (@thomasfuchs)
— Programming Wisdom (@CodeWisdom) March 23, 2018
From the Prime Minister of India to farmers in the heart of rural Zambia, hundreds of data teams around the world use our platform to democratize data an bring about real change for millions of people. Every choice we make on our platform, and every feature we build has to stand up to this responsibility.
It’s important to question every choice, since it will affect millions of people. Make sure you know what to use, when to use it, and even why you’re using it in the first place. Sometimes the toughest problems have the simplest solutions. (And no, machine learning is not the answer to everything.)
3. Fail fast and keep learning
We have lots of big problems to tackle, and lots of possible ways to solve each problem. The best way to figure out which solution is best is to move fast and test lots of possible solutions.
Failing fast is about doing lots of fast iterations and learning from each, rather than getting stuck on one solution or decision. (However, it’s not about building things without knowing their limitations or problems!) Whenever you’re stuck, talk to other people — they might have a quicker or better workaround.
4. Know thy build
Knowing your build inside and out is a crucial part of engineering. It’s not enough to know what will work and when it’ll work. It’s just as important to know what won’t work and when it won’t work.
5. #ItIsNotMagic
If something is breaking, there’s a problem in the code. It’s never a magical problem or a random occurrence, because that’s just not how code works.
We expect our engineers to figure out what caused the break, not throw their hands in the air and proclaim that it’s just broken. Think about what is happening under the hood.
This idea is also important for choosing technologies or tools. Think why something is better, and what under the hood makes it better. Tool A may be good at solving problem B, but that doesn’t mean that transitioning to tool A will magically solve all of your problems. Generally there’s a trade-off involved.
6. Measure whatever is measurable
Measuring what you’ve built may not seem like a good use of time, given that it could be spent on building the next new thing. However, setting up systems to measure a product gives you actual data to work with.
Measurements are also crucial once you start building for scale. If you don’t measure how your product is responding to more users or requests, it’s easy to miss hidden problems that’ll cause it to break in the future.
Once you have data, you can use it for anything — maybe it’ll help you decide on the next feature for your product or show you how to optimize a certain section of the product. No matter what you do with the data, having it brings you one step closer to making better data-driven decisions.
7. Automate whatever is repetitive
Our base tendency should be to automate wherever possible, rather than doing tasks manually. Automation gives us more time to work on building the actual product. We want systems to do our repetitive, tedious jobs, rather than having humans spend their evenings doing these tasks. Beware of spending too much time on optimization though!
8. Premature optimization is the root of all evil
“Rules of Optimization: Rule 1: Don’t do it. Rule 2 (for experts only): Don’t do it yet.” – Michael A. Jackson
— Programming Wisdom (@CodeWisdom) April 22, 2016
Optimization is important, but it shouldn’t be done too early. Pick the right battles to fight at the right time. If you optimize too early, you’ll spend and re-spend lots of time and still come out with not the most optimized solution. Wait until your product is fully baked, then optimize what needs to be optimized. Check out this StackExchange discussion for more context.
9. When in doubt, ask!
Stuck or confused? Just ask your fellow engineers! Someone will have a solution, or at least an idea to get you started on the right path.
Just remember, make sure to do your research beforehand, and choose your next steps thoughtfully. Never opt for an approach that you or someone else surely thinks will work without knowing why it’ll work or without any data or objective facts to support it.
1 Comment
> Life is too short to reinvent the wheel. Don’t waste time building your own tools or libraries if there’s already something that does the same job. Wherever possible, extend existing libraries and contribute back. This helps you get a clear picture of what other people’s work does and how it fits into what you’re building. It also lets others benefit from your work, just like you benefited from theirs.
It might not be a very bad thing to build your libraries or tools. And it is wrong to generalise this is a bad thing. At times, the library author looses interest in the project. Sometimes, the goal do not align and you need to fork it. At the same time, sometime an off-shelf solution is too much for your requirements. In short, it depends on the situation and wrong to say something as bad without going deep in it.