Our Engineering Principles.
We’re a group of engineers at Dotmesh working within a distributed team, coming together to build a product that combines the expertise from the world of Operations and Software Engineering. Building scalable and resilient distributed systems is both hard and complex, and setting out to achieve that without a team that had a shared ethos is near impossible. So it was important for us to start our journey with a shared culture and a shared responsiblity for building that culture.
During one of our all-hands meetings, we set out to draft a set of Engineering Principles that reflected our culture and put us on the same page. This is a journey in progress, and we aim update our Engineering Principles from time to time. We are proud of our engineering culture at Dotmesh and we’d like to share it with the world. Here is a gist of our Engineering Principles.
Ways of working.
- We’re all adults and we trust each other.
- Let’s have regular Tech Talks, if there’s a really interesting piece of work you’ve done during the week, or something horrendous, or something that could be done better – let’s get together and talk about it
- Have a short kickoff when you start working on something if you want to, often useful to talk to the person who wrote the issue/ticket. Context gathering can be very valuable, and a kickoff can avoid comments like “didn’t you know there was a library you could have used to save you all that work” :-)
- Ask for a code review if you want it.
- Ticket closing ceremony - talk to another person about the feature you just implemented and showcase what you’ve done. Do demos! Record a video, maybe put it on the internal blog. Or talk about it and validate your solution with the issue creator.
- It’s OK to take time off when you need it :-)
- It’s OK to ask for help :-)
- Commit directly to master – when should you do it?
- Whenever you can. Use feature toggles where appropriate.
- Use branches on a case by case basis. Especially when working on something hard and scary to integrate. Eg. renaming all packages.
- Commit WIP to a branch if it’s broken though. Don’t leave code on your dev machine for more than a few hours. Accidents that involve a hot cup of tea and a laptop are unpredictable.
- Master branch - it’s not a crime to break it (although you should try not to!). Be responsible for what you push to a master branch. Try and push something to it as long as you’re not certain it’ll break everyone else’s working code base.
- If you know it’ll break everything, use a branch.
- File technical debt as “broken windows” issues, if you can’t fix them right away. Don’t let it fester!
- Unit tests could give us blazingly fast feedback. Identify candidates where unit tests are ideal and use them where appropriate.
- Write acceptance tests for things that are important to users.
- Look at areas where we can dog food dotmesh to make it faster to run our own acceptance tests.
Open Source Ethos.
- You are working on an open source project – think about how everything we say comes across to an external contributor.
- Don’t leave the build broken.
- Have working CI all the time.
- We use semantic versioning for releases.
- Stable goes on a git branch named, e.g.,
- Major & minor releases are branches, patch releases are subsequent commits on those branches. For example, the first commit on a release branch is
vX.Y, next is
- Make tags of these patch releases so they can be found easily
- Unstable versions named after branch and commit hash -