Engineering Tenets: All About Cooperation
In our new 4-part series, Director of Engineering Spencer Norman explores the ways in which Reaction Commerce’s engineering tenets lay the foundation for a successful technology-first organization. Each week, Spencer will dive into one of our four overarching themes—communication, character, competence, and cooperation—along with the core values that drive each principle.
We’re a distributed first team, and while it can be challenging at times to collaborate or jam on things, the need to schedule our time together means that in order to make sure we’re engaging with each other, we have to be intentional. It means documenting all of our brainstorm sessions and decisions on architecture. It also means putting time aside to pair program, review code, and write issue reports.
While pairing programming isn’t necessarily a requirement at Reaction, we encourage teammates to do it frequently. Outside of our biannual all hands week, it’s one of the best ways we can bond as a remote team. That’s why we schedule a Pair:30 session after our daily stand-ups. Pairing allows us to cooperate with each other on a daily basis, spend time reviewing each other’s code, and seek the best way to solve a given problem.
Cooperation is a key ingredient of open source, and because of that, it’s a vital part of our health. The codebase for Reaction improves when people who use our code report bugs and submit PRs. We encourage our teammates to do the same, to give back to the open source projects we’ve benefited from.
Who protects and owns the codebase? Everyone and anyone. In fact, anyone on the engineering team can block a PR by requesting changes or asking for clarity. When a team consists of people who care deeply about the product, who aim to build the best software for commerce in the world, protectivity comes naturally. Everyone who touches the product understands what we’re building, and what other companies might build in the future.
The review process is a basic example of how we protect our codebase. All code is reviewed by at least one person—a pair partner, a third-party, or a peer—before it hits our master branch. We review for style and readability, along with making sure that the code is performant, secure, and well-documented. We measure the complexity of each commit and aim for having small PRs that focus on a single change. By keeping PRs simple and as small as possible, we reduce the amount of time that a PR will take to review and QA, as well as the amount of time that code spends in review.
Our goal is to improve the experience of the next developer. In developing open source software, a teammate is rarely the last person to look at any particular piece of code, nor are they the next person. There’s no guarantee that the developers reading their code are from the same organization, that they speak the same language, or have similar patterns or tendencies. By keeping all of these future users in mind, we can do a better job of protecting our codebase and improving developer experience for everyone.
While we’re a growing engineering team, we’re still small enough so that everyone has to be willing to wear multiple hats, to contribute outside their primary area of expertise. For some engineers, this may mean jumping into the Meteor app to debug some code that hasn’t been touched in several years, while for others, it might mean crossing over from working on a React component to working on GraphQL API resolvers. Ultimately, it means that everyone must maintain some knowledge of how all the parts fit together. Over the course of a single sprint, each person on the team may contribute to multiple areas of the app across several repositories.
Engineers at Reaction Commerce are encouraged to act as owners of the codebase, docs, and every release. We have an engineer who owns our docs project and an engineer who owns our QA efforts. However, instead of these domain owners relieving the need for the rest of the team to write docs or perform QA, they act like multipliers. We have an incredible engineer who owns our docs project, and as a result, the expectation is that every engineer on the team will be empowered to write better docs more frequently. Having a domain owner helps us set standards and patterns. It empowers the rest of the team to act as owners and to raise questions when they see docs that are aberrant when performing code reviews.
Our policy of leave it better than you found it, means that whenever you’re touching old code for any reason, your goal is to fix the issue that you set out to fix, while improving any other issues aside from the original issue. Are you fixing code that’s inside a lodash map method? Probably time to use the Array.prototype map instead. Sometimes it’s more about adding docs to make the files that you had to splunk through more navigable and understandable for the next developer. This policy goes hand-in-hand with our work to improve the experience for the next developer.
We believe that each of these four values make our developers better, more productive teammates. The fact that we’re a distributed team building open source software makes these types of characteristics all the more important.
This is the final post of my Engineering Tenants series, which I hope you've enjoyed. If you’ve got any questions or comments, please drop us a note in the comments below.