Engineering teams that value high quality code

As a small, nimble team, having a high-quality code base is key to operating effectively.

At CareMessage, we’re building a platform that helps millions of underserved patients improve their health with preventive care and appointment reminders, local resources, and health coaching through text messaging. Given the real-world implications, writing high-quality code that we can ship quickly and sustainably is paramount. Starting with the technical interview process, we require engineers to code. Similarly, we expect them to write tests to cover their code. We have between 95-100% code coverage on our repositories and are thoughtful about how we maintain tech debt, reviewing it regularly and following a defined process to pay it down. Last but not least, we use Ansible and Terraform to maintain our infrastructure as code to minimize misconfiguration issues and have a CI/CD build pipeline that runs in under 20 minutes upon merge. All engineers participate in an on-call schedule, but since we have such a high-quality code base, that means there are rarely major issues.

We’re software engineers building products for software teams.

One of the things we love about working at LaunchDarkly is that we are making life better for software teams around the globe. Our “Product Delivery” Team is made up of engineers, product managers, and designers. We have four Product Delivery values:

1. Always Be Flagging – be exemplary users of Feature Management to ship faster with less risk.
2. Think Incrementally – embrace the cumulative impact of small changes.
3. Simple, Correct, and Fast – to achieve big things efficiently, design for simplicity first.
4. Invest in the Team – be generous with your time, because we succeed or fail as a team.

We approach hard problems with an engineering mindset. And we're not afraid of big challenges.

Our engineering team is composed of veterans from the top technology companies in the industry. We built our system right the first time and it has scaled for years as a result. We have been able to meet the challenges that exponential growth of our product has brought with it, and much of this has rested on our foundational decisions.

We invested heavily in a modern, distributed flag delivery network – even when the company was small. We handle our infrastructure as code. We build and deploy on AWS and have made extensive use of platform capabilities (AWS Lambda, Kinesis). We want our team to focus on high-value problems and leave the undifferentiated heavy lifting to others.

All of our core services are written in Go, which strikes a great balance between performance and ease of development. All of this gives our customers the ability to control their software in product and make critical changes in situations when milliseconds matter. We work every day to give engineering teams just like ours new super-powers.

All new code has to have tests.

Increasing code quality is a high priority for us. We are given the capacity to do things right, even if it takes longer. Everything is a trade-off: if we can spend a week fixing technical debt now to save us time in the future, then we’ll do it.

By using feature flags inside of the product, we can ensure that new customers use the latest and greatest features, while leaving older customers on stable grounds without changing things. Our Product Experience team actively works to migrate customers to the latest version of features so they can be deprecated and removed from the code. We’ve done this in the past implementing our new Markdown parser, Cloudflare SSL, and one of the biggest projects, our new React-based documentation design.

We avoid indirection.

We value quality over speed – we won’t rush to fix problems but rather take the time to do it right. For instance, we chose to write on our in-house real-time collaborative database rather than simply using an off-the-shelf solution. While its semantics and operations are still being developed three years later, it underscores our desire to understand what’s happening when any button gets pressed, and to trust our own work instead of importing libraries that are poorly suited to the particulars of our needs: we have a culture that strongly opposes compromising the quality of the product for the convenience of implementation with ready-made parts.

We try to keep our code as simple, coherent, and straightforward as possible, which allows us to pair more easily and have a shared context. By maintaining a “gem” of a system, we can hold the entire technical design in our heads and make radical changes shockingly quickly.

Two of our three founders are engineers.

Fun fact: they are still the #1 and #2 top contributors to our monorepo (as of this writing) even though they’ve largely stopped writing code circa 2020. If Facebook’s operating ethos is “Move fast and break things” then Modern Treasury’s is to “Do it right the first time.” In practice, that means we don’t have a deadline-driven culture; we’re willing to trade off speed of shipping for correctness. We stress this point because we are entrusted with monitoring and moving our customers’ most valuable assets—their money. They trust us to be an infrastructure provider, so we are unwilling to compromise on reliability and security.

One memorable example of this is how our Co-Founder and CTO, Sam, spent the company’s first few weeks encoding our AWS configuration in YAML files. This enabled us to use CloudFormation to provision our infrastructure and ensured every change is version controlled and goes through code review. Considering how many incidents are caused by accidental changes in the AWS UI, it’s proven to be a wise upfront investment. We’ve had 100% infrastructure-as-code coverage since day one, which many larger companies’ infra teams can spend years trying to achieve.

Modern Treasury is a great example of an “earned secret.” In some sense, it’s a small miracle that the company was able to get started at all. Banks are highly regulated entities and tend to be extremely selective when partnering with established tech companies, let alone young startups. So how did an early Modern Treasury consisting of just the founders convince a bank to give them both read and write access to a client’s account?

For one, Sam, Dimitri, and Matt worked together at LendingHome to build bank integrations for handling billions of dollars of mortgage volume. There, they realized that the problem of integrating directly with banks extends to any company trying to move money at scale. They earned a deep understanding of banks, from their incentive structures to their technical architecture. Early bank partners like Silicon Valley Bank found them credible because they knew exactly what to ask for and who to ask.

Today, our team hails from companies like Stripe, Flexport, Affirm, Brex, Square, ClassPass, Segment, Microsoft, and Twilio, with a few YC founders as well. Shruthi, our Head of Engineering, recently joined the team and brings a wealth of knowledge from her time at WhatsApp, where she led the payments engineering team and built the product from scratch.

While we’re humbled to work with smart, talented people, we don’t look for a certain company name or university on your resume. In fact, some engineers like Ariel, have non-traditional backgrounds (in Ariel’s case, working in IT before being a software engineer). Ultimately, we’re looking for motivated, hard-working people to join our team who bring diverse experiences and viewpoints. We raised a $85M Series C in October 2021 and are continuing to grow the team. If any of this sounds interesting, we’d love to hear from you!

While tech debt normally has a very negative connotation, we embrace it.

We know we have a strong product-market fit, so rather than throwing many things at the wall to see what sticks, we focus on well-architected solutions at the cost of limiting functionality. This means we’re very intentional about our practices. The team doesn’t shy away from tech debt. In fact, we believe that if we’re prioritizing effectively and iterating, there’s going to be debt. We keep an eye on it and actively pay it down strategically.

To ensure a high-quality codebase, we have regular code reviews that focus on functionality as a starting point and architecture. We also invest heavily into shortening our feedback loops with a focus on observability and domain ownership.

Airtable takes a long-term view.

We intend to build a company that will last decades. Our product, funding, and market position make a long-term orientation for our engineering team not only possible but also necessary. For one thing, our product has enough fundamental complexity. Adding incidental complexity by taking on too much technical debt would cripple our velocity sooner than a company with a more straightforward, boilerplate product. Our focus on code quality grows from deep roots in the nature of our business; it’s not just a pet preoccupation of some engineers on our team.

To this end, we embrace the usual repertoire of quality software development practices: code review, linting and static type checking, unit and integration testing, continuous integration, manual and automated QA, deployment automation, issue tracking, and a thorough style guide that focuses on practices that improve code clarity without too much bikeshedding. These practices aren't set in stone; we're always discussing how to improve, and ideas can be raised by anyone from our newest hire to our CTO.

At a higher level, we have a culture of circulating ideas in design documents well before implementing them. We do what’s best for Airtable: we’re one team working towards one mission. We’re collaborative and share our work openly. We’re invested in each other’s success. When done right, a design review process does not slow down development. Good teams are perpetually bursting with ideas. If people are encouraged to share those ideas early, then features or changes can be proposed, discussed, and refined long before the team has the bandwidth to implement them. Reflecting on design or implementation approaches as a team leads to greater simplicity and clarity. Building the simpler, clearer thing nearly always leads to greater development velocity, even in the short-term.

That said, we recognize that there are times when fast turnaround is imperative. Sometimes a defect that affects users must be fixed urgently, and the fix is clear, and in such cases, we prioritize appropriately. We prioritize progress over perfection and operate with urgency. We move fast to deliver ambitious goals but know that sometimes getting the right results demands more time. And sometimes, the best way to deliver quality in the long-term is to put early iterations of a feature in contact with users so we can learn from their feedback. In these cases, we strategically deploy well-contained technical debt. (One tactic for containing debt in these situations is to ensure that decisions made in this mode are highly reversible. For example, exposing a feature behind a flag to a small audience constrains future development much less than a public UI or API in the core product.)

That said, we recognize that there are times when fast turnaround is imperative. Sometimes a defect that affects users must be fixed urgently, and the fix is clear, and in such cases we prioritize appropriately. And sometimes the best way to deliver quality in the long term is to put early iterations of a feature in contact with users so we can learn from their feedback. In these cases, we strategically deploy well-contained technical debt. (One tactic for containing debt in these situations is to ensure that decisions made in this mode are highly reversible. For example, exposing a feature behind a flag to a small audience constrains future development much less than a public UI or API in the core product.)

Making things simpler is always our goal – for ourselves and our customers.

We strive for simplicity. When contributing code, Asana engineers always ask the question, “Could this be simpler?” Striving for the simplest, most viable solution requires time and effort up front, but it always pays off in the long-run.

Simple solutions are easier to understand, especially as our codebase grows, and engineers often spend more time reading than writing code. Having code that’s easy to reason about enables them to spot bugs faster and make modifications with confidence.

By reducing complexity, our team is able to create a more reliable, maintainable, and testable application, and therefore a better experience for our users.

Having a high-quality codebase means faster deployments and a more enjoyable engineer experience.

As soon as you join the team, you’ll be able to push your first commits by Friday. This holds true for everyone – whether you’re an intern on the team for a month or a more senior engineer. We pride ourselves on having a high-quality codebase, which means we can deploy often. All team members are free to create pull requests and push code into our development branch in our staging branch. There are two sets of eyes for all code and all code reviews follow the same blameless mentality. For us, it’s always about learning and making something better, which is why comments remain focused on the technical problem at hand. We all bring something different to the table. For example, one of our interns didn’t know our backend framework, but she shared a couple of really great shortcuts that our team didn’t have before.

We also have high unit test coverage over the critical pieces of our infrastructure and are well on our way to a complete CI/CD pipeline that allows rapid, high-quality deployments. Ultimately, we believe that shipping often not only boosts overall morale, but it also makes us happier engineers since we can see the immediate impact our code has on our customers’ lives.

We take pride in maintaining a high quality code base.

Central to our values of high integrity and a sustainable work culture, we invest in keeping tech debt to a minimum and maintaining a high quality code base from the beginning. Doing so not only keeps our on-call rotation reasonable, but it also limits the time we spend fixing broken or flaky parts. This means we can focus the majority of our time on feature development for our customers. To ensure a high quality code base we:

• Review all code changes, at a minimum by two peers.
• Have a mature product lifecycle where larger projects have scoping, design, user feedback, and implementation phases – each of which requires peer feedback.
• Continuously triage and prioritize our feature and bug backlogs.
• Implement a blameless but thorough and educational incident review process.

We actively emphasize style consistency on both the frontend and backend.

As a team, we embrace automation, consistency, and simplicity:

• Automation – We rely heavily on automation to make our code and processes better. We use linting tools for styling automation, CD/CI for deployment automation, and Kubernetes for resiliency and host automation.
• Consistency – We have a documented style guide and component library that advises frontend development. Similarly, we have consistent styles and patterns we align and adopt on the backend. These are constantly iterated on, never stagnant.
• Simplicity – We’re a big believer in KISS and the principle of least astonishment. We treat our code like a product, with engineers being its users. As such, we try to optimize the design to match the user's experience, expectations, and mental models.

Our tech stack is optimized to be modern and easy to pick up, but not excessively flashy. We value new technologies when the benefits are clear, but being pragmatic is our number one priority. Some of the tools we use include:

• React because of its huge developer community and ease of use
• Rails because of its longstanding resiliency and friendly developer experience
• Typescript as a means to embrace type safety and keep sanity in check
• GraphQL because of its friendly developer experience

We turn OR operations into AND operations.

First and foremost, having a high quality code base enables us to write new code faster. We utilize controllers in our codebase, which allow us to do operations in Doppler, and each controller has baked in permissioning, security, analytics, bug reporting, and other features so we are secure by default.

While there are many advantages to having quality code, it also isn’t a choice for us. We store incredibly sensitive data for customers, so having high quality code is really a necessity for our business. We’ve gone through multiple penetration tests, conduct rigorous code reviews, ensure all core flows have end to end tests, and use a dedicated staging environment for QA.

Perhaps this is somewhat unique to Doppler, but we don’t have to compromise between speed and quality. We’re a productivity tool that makes you more secure, and generally speaking, if you’re more secure, you’re more productive. By prioritizing reusability, we’re able to turn OR operations into AND operations.

Quality ∧ (Scope ⊕ Speed)

Angaza engineers have a strong bias towards clarity over complexity and simplicity over cleverness. We deliver deep, constructive code reviews; employ continuous integration and blue/green deploys; and prefer care over speed when it comes to production. Our platform is essential to our customers. As a result, we strive to build our engineering culture on a bedrock of quality.

Engineers have wide latitude to work across the entire codebase. We attempt to fix entire classes of bugs at a time. When mistakes do occur, we practice a no-blame postmortem culture.