Engineering teams that value high quality code

Safety is top of mind in everything we do.

Reversing diabetes is complex and people’s lives depend on it. We write meaningful and automated tests that are as close to real-world scenarios as possible in order to ensure our code is safe and keep sensitive data secure. Similarly, we choose tools that enforce safety and catch errors before they ever become a problem, such as typed languages, linters, static analyzers, and database constraints.

To stay ahead of the competition, we adopt DevOps methodologies such as maintaining our infrastructure as code, incorporating feedback from users into multi-day deployments, and having a robust fault tolerance via monitoring systems that alert us when necessary. Engineers at Virta are familiar and stay up-to-date with bleeding-edge technologies such as Google Cloud Platform, Linux, Golang, Python, Docker, Kubernetes, Helm, and Terraform. We also avoid creating technical debt by enforcing test coverage and code reviews for every code addition. Ultimately, maintaining a high-quality code base allows us to scale and support the company’s hockey stick growth.

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.

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 that adding incidental complexity by taking on too much technical debt would cripple our velocity much sooner than a company with a more straightforward, boilerplate product.

Additionally, we have a product that stands in a well-differentiated category of its own. This gives us breathing room to build durable competitive advantage by innovating, rather than constantly racing to eke out a razor-thin marginal advantage over similar competitor products. 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 do better, 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 in advance of implementing them. 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 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 relatively 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. 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.)

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. It’s an exciting time to join, too, since we recently raised a $85M Series C. 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.

We keep our quality bar high and sweat the small stuff.

As a still-small-and-nimble organization, speed is our greatest advantage over the incumbents in our industry. But, if we don't execute extremely well and deliver extremely high-quality products consistently, we won’t have any staying power. Because of that, we're obsessed with breaking large problems into small, meaningful chunks. Our quality bar is exceptionally high and we are willing to sweat the minor details.

We are conscious of our technical debt and regularly invest time and energy into the foundations of our codebase. We design extensible, solid, foundations. We make strong use of TypeScript’s type system to prevent bugs.

Our platform is supported by different layers of automated testing via continuous integration, such as unit testing, functional testing, integration testing, smoke testing, and thorough linting and formatting. We rely on this automated tooling to keep codebases consistent, so we can focus on the foundation and mechanics of each feature during code reviews.

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.

No code base is perfect, ours included, but we dedicate bandwidth to continually improve our code base and engineering practices.

This starts with review for all new code that’s written and early discussions about major changes in architecture to incorporate feedback from the team. We invest time and energy to refactor places in the codebase that need improvement, including prioritizing these efforts in our team and company goals. We use strategies like refactoring-in-place where we add comprehensive test coverage for a complex, hard-to-maintain piece of code, and then rewrite a simpler version using the tests as guardrails for correctness. We also opt for tools that support safety and help catch issues before they arise, such as feature flags, linters, static analyzers, and database constraints. Ultimately, these investments return bigger dividends by helping us go faster and make changes more confidently.

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 have well defined optimization principles that are part of every engineer's onboarding experience.

They cover code consistency, using data to make decisions, technical leadership, learning from our mistakes, focusing on automation and developer productivity, writing safe, well tested and monitored code, and shipping small changes quickly and continuously.

Additionally, we have an org-wide proportional investment policy that provides the opportunity to prioritize work that helps improve the codebase and developer productivity. While we value urgency and moving quickly, we also favor doing things the right way as opposed to the fast way.

We don't write throw-away code.

Every day, more and more patients, clinicians, and researchers rely on our data APIs being available, our algorithms processing continuously, and every point in between being 100% secure.

We measure thrice, and cut once. We require an architectural design document for every feature we build, together with a risk matrix to help predict things that can go wrong. We also require code leaving a branch to be production ready, which means it comes with tests and a monitoring strategy. It's more work, and it does mean it takes a little longer until we write that first line of code, but when we do, there are no surprises and it more than makes up for the time spent up-front.

In terms of the staples, our team actively uses and gate merges on peer-reviewed pull requests, lint and static analysis checks, unit tests, and integration tests. We invest heavily in CI/CD automation, 100% of our infrastructure is peer-reviewed code, and we <3 observability!

All this isn't to say that we don't have tech debt. However, our team's approach is to have tech debt that we choose consciously and strategically as we design each feature. Each quarter, we allocate 70% of engineering hours to new feature development and 30% to our internal needs.

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. Not only does a high quality code base keep 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 codebase we:

• Review all code changes, at a default by two peers.
• Have a mature product lifecycle where larger projects have a scoping, design, user feedback, and implementation phase – 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.

Code should be an enjoyable place to spend most of your day.

As an engineer at HumanFirst, you will spend most of your time writing and interacting with code. Because of this, we spend a lot of time making the code an enjoyable place to be. We understand that a code base is more than the raw bytes that do the work; we place a strong emphasis on documentation, testing, readability, tooling, and extensibility. We have a full set of unit, integration, and end-to-end tests that give us an average of 90% coverage, with some projects reaching 100%. Our APIs have fully interactive documentation (from endpoints to parameters to responses) and our frontend components are documented both in their appearance and behavior using Storybook.

Additionally, we regularly examine pain points and work toward refactoring for better usability. We keep an account of any tech debt we acquire, and make sure to allocate regular time to pay it off. Our ultimate goal is to make sure the structures we have in place help, rather than hinder, both you as an engineer and our ability to serve our customers’ needs.

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.

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. Simple, Correct, and Fast – to achieve big things efficiently, design for simplicity first.
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.