The 10 Commandments of Code Reviews
Code reviews are one of the most important parts of an engineering team’s workflow. The benefits of code reviews include: creating visibility for new changes, preventing bugs, improving code quality, and creating cohesive patterns. Despite the benefits, code reviews can sometimes create tension in the team: some developers are stricter than others, some take a long time to review, etc.. Often, these tensions come from a lack of agreement of how code reviews should be conducted and what the roles of a reviewer and a submitter should be.
I wrote the 10 commandments for code reviews, to create a common understanding for reviewers and submitters about how code reviews should be conducted. By following them, teams share a common understanding of their responsibilities, reduce the tension between teammates, and deploy their code faster. Since reviewers and submitters have very different responsibilities, I split the 10 commandments in 2—5 commandments for each role. Each set of commandments were written with the other set in mind, which means that both sides need to obey the commandments to reap the benefits.
Rethinking Our Development Pipeline
While building two products over the past four years, our team has grown in both headcount and dev speed. Adopting a process to improve our speed of development took us a while to get right. As we all reflect and make resolutions at the start of the new year, we think other teams might benefit from how we identified our slowdowns and improved our dev speed.
Common Promise Anti-Patterns and How to Avoid Them
Engineers making the move from callbacks to promises make common mistakes and introduce anti-patterns into their codebase. During my time working with promises at Runnable, I’ve identified a few common anti-patterns people use that cause issues maintaining the codebase. As I go through these anti-patterns I’ll explain what the pattern is, how to avoid it, and then take it a step further using Bluebird to make the code cleaner.
How We Pre-Bake Docker Images to Reduce Infrastructure Spin-Up Time
I previously outlined the methods I used to speed up our AWS infrastructure spin-up time. The method covered in this post further reduced that time by about 50% by pre-baking all of the services we needed to run an application.
Our microservice applications are hosted in Docker containers and can be pulled from the Docker registry and our own private registry. Rather than install and configure services on an Ubuntu server using bash scripts, the individual Docker images for each application can be copied onto every instance that we need. This allows us to add instances much faster if we need to quickly scale to handle a heavy load, and is a practice that most organizations should adopt if it can be implemented.
Embracing Event-Driven Microservices
A few months ago, Anand discussed the benefits of transitioning from traditional HTTP communication to event-driven microservices. He noted how this transition decoupled our services, forced scalable patterns, and increased our resilience. Here, we’ll detail the lessons we learned when we re-implemented our Cron-esque scheduler service, Khronos.
3 Ways We Improved Our Developer Hiring Process
Developer hiring. For both parties, it’s a stress-inducing and potentially life-changing decision. And yet, they each have around 4 hours to gather enough info to make that decision. How do you use that time? Are you asking questions that prove the competency you need? How do you compare candidates?
How We Saved 98% on Infrastructure Monitoring Costs
It’s important that we provide users with the best experience. Part of that means that our service is available through hardware failures. And when things do go wrong, we need systems in place to monitor key metrics and send alerts to services and our team. Initially, we chose Datadog as our monitoring solution because it was easy to set up, and it provided integrations to services that we used. Then we started scaling our customers’ infrastructure to keep up with demand and saw our infrastructure go from 5 to 500+ servers. This didn’t jive with Datadog’s per-server cost model, as it increased our bill from $75 to $7,500+ per month. In order for us to move away we needed something that provided auto-discovery of new servers, collected host and container metrics, alerted us on abnormal conditions, and had an easy way to visualize data. We turned to the open-source world and discovered Prometheus, a monitoring solution built by SoundCloud.
New ES6 Features in Node LTS
A couple of weeks ago, Node.js released its latest LTS: version 6.9.0. I realized this was the case because one of our services broke. It used the
nodejs:lts image and got upgraded by mistake. Inspired by this breaking of one of our services, I decided to dig into what was new in this version of Node. In this blog post, I’ll walk you through some of the new ES6 additions to Node and how they will change the code you write.