Maintaining Code Quality on Remote Teams

I was recently asked my thoughts about how remote teams can maintain code quality. Before answering, it's worth noting that the question implies maintaining quality is somehow different on remote teams than in-person. Having worked extensively in both environments, I can confidently say this isn't the case.

Regardless of where you work, the core conditions that drive code quality are the same:

1. Reduce complexity
2. Pair
3. Review code
4. Write tests
5. Deploy often

Bias for Simpler

Code quality begins long before any code is written. Early in the shaping process, keep the definition of "done" simple. Identify the underlying problem you're trying to solve by building the feature (e.g., reducing user confusion on a specific page), and describe the smallest change that addresses it. Vigorously defend this core idea from scope creep.

Once you've identified the simplest what, it's time to shape the simplest how. Do you need to invest in new UI patterns, or will existing ones do? Must you engineer a wildly complex client-side solution, or will a simple server-driven one work just fine? Interrogate each step in the implementation and ask whether it needs to be so complex. Where reasonable, simplify it.

Start with Pairing

For non-trivial features, or where the path forward isn't immediately clear, prefer pairing at the beginning. Use this time to focus on high-level implementation alignment: how will we build this thing? Once clarity on the path forward has been achieved, the engineers can divide up the work in whatever way makes sense (ideally shipping independent vertical slices).

This keeps architectural quality high and avoids extensive rework in code review.

Review Code

All code should be reviewed by at least one other developer. The goal of a code review isn't merely procedural—it's to get the highest quality feedback possible so the quality of the system is maintained.

Use reviews to focus on improving the design of the code, abstractions, and interfaces. Leave anything that can be enforced with a linter to a linter.

Write Tests

Every PR should include tests that prove the feature works or that the bug is fixed. These tests also serve to demonstrate how the code works and make it much easier to extend or refactor the system in the future.

I'm not concerned with code coverage or the ratio of test to production lines of code. My goal is simply that any engineer on the project feels confident that if CI is green, it's safe to deploy.

Deploy Often

Deployments can be scary, so do them more. They will become less scary. They will become routine.

Our goal with deployments should be, in the context of web development, to do them multiple times a day. As we deploy each day, we familiarize ourselves with the process (and what can go wrong). We invest in the process so each deploy becomes faster, easier, less risky, and less painful.

Here, There, Anywhere

Following these guidelines will, in my experience, tend to result in high-quality code being produced and velocity maintained over time.

It doesn't matter if that team is distributed around the world or sitting next to each other in a cubicle farm.