Sharing Our Best Practices

by Paul Hallett on Wednesday, 11 Nov 2015

Similarly to modern web services, best practices constantly iterate and improve. Here at Lyst we’ve taken many of our favourite practices and tried to adopt them. As we’ve grown our team and started to follow the practices, we’ve been tweaking them to make them better suited based on how we work. We’ve also been asking new team members to share their previous experiences and opinions on what works well for various aspects in our team. This has been really good for us and we’ve been wondering how we could get more of this outside influence.

Fascinated by hackertyper
Before you ask: yes, that is hacker typer.

Today we’re open sourcing many of our best practices in an effort to learn from the outside world, and share some of the things that work well for us. This is part of an ongoing effort to establish a transparent and equal engineering team at Lyst.

A lot of our best practices have a pragmatic and aspiritational approach: they are things we try to do well, but they’re not strict guidelines. Despite this, we’ve been very consistent in their adoption and the whole engineering team have felt the improvement over time.

We’re not releasing eveything in one go (we’ve got quite a few) but today we’re shipping some of our favourite best practices.

iOS Coding Standards

Our mobile application development follows a lean approach, and our iOS Coding Standards relects this, as a living document that focuses on the best way to write code and build features, right now. Recent updates focus on how we bridge between Objective-C and Swift.

Code Review Guidelines

A big part of the team’s work is reviewing code from other engineers. Anyone can review anyone else’s code, and we believe this helps us to share knowledge of the systems in our architecture. We’ve written guidelines for how to make good pull requests and do good code reviews. It is one of the newest best practices we’ve written down and we’d love to learn how other teams do their code reviews.

working at lyst

API Best Practices

Lyst is building more and more microservices. In the space of the last six months we’ve developed 8 of them. Most of them communicate using HTTP. Building APIs is something we’ve talked about before and as we have been creating more and more HTTP based API services, we decided to take the best practices from the web and adapt them based on what we’ve learned. Our HTTP API Best Practices are quite extensive and are inspired by some of the most recent conversations and ideas in the Web API world.

Javascript styling guides

Our Javascript style guide first started out as the Google JS Style Guide with a few extra agreements we made amongst ourselves. Recently we moved over to using ES2015, but the Google style guide hasn’t updated in a while. We quite liked what the Airbnb style guide had to offer in this space. So, we forked it. After a few months of internal debates and tweaks, we’re giving our fork back. Once again, we’ve added the Lyst “pragmatic and pratical” twist to these guidelines to produce an iteration that works really well for us.

You can find the Javascript style guide on our GitHub.

Moving Forward

Over the next few months we’re going to be sharing more and more of our best practices. We want your suggestions on how we can improve our processes. So checkout the repository and make some pull requests! If you’re interested in learning more about us, then follow us on Twitter.

comments powered by Disqus