Engineering at Replicated

Writing code is just the beginning

Your instincts matter.

We’re not building photo filters for 14-year-olds. We’re building a technical product that will be used by your peers (some of the best software engineers in the world). As a result, engineers at Replicated step up to take responsibility for more than writing code. Our engineers focus on delivering a product that they’d love using themselves.

Security is foundational.

It's not possible to add security to a product after it's built. Everyone on the team (product, engineering, automation) understands what it takes to build, support and maintain a secure product from the ground up.

All hands on docs.

Although we try our best to hide the inherent complexity of the Replicated platform behind an intuitive UI, that really only covers a third of the use cases. Just about everything at Replicated can be used via UI, API and CLI. That’s why we place a premium on informative, well-written documentation that aids our customers when they need it. We treat documentation as part of the product.

Functioning as a team

It’s everybody’s code.

Even for complex products, the best code looks like it came from a single person rather than a collection of unique pieces stitched together. We share a unified approach to coding so it’s easier for any developer to jump into unfamiliar parts of the product and immediately add value.

Avoid continuous refactoring.

Continuously adding small and unplanned refactoring means everybody is continuously relearning the codebase. We carefully consider and plan refactoring, and only pull the trigger when we all believe it’s the right decision.

Use Replicated to build Replicated.

Whenever possible, we use Replicated to build and deliver enterprise features into our products—no shortcuts allowed. This is a great opportunity to see what it's like to be a Replicated customer.

Software engineering in a startup

There’s no law against copy and pasting… sometimes.

Abstractions aren't obvious until there's at least 3 implementations. Creating shared libraries and abstractions around a block of code that's used twice should be carefully considered. Testability or 3+ implementations are both valid reasons to create abstractions.

Choose simplicity over extensibility.

Creating abstractions and modularity "just in case" can result in a bad case of technical debt. We try to avoid predicting the future, and instead focus on writing code that just works.

Size the solution appropriately.

When planning a solution, we consider all constraints when deciding what to deliver. Every project comes at an opportunity cost of the things we’re not working on, so flexibility is fundamental for both depth and speed of delivery.

Don’t look to build when you can buy.

Just because we can build something, that doesn't mean we should. When possible, we opt for existing solutions that let us focus our valuable time on building differentiation into the core product.

Everything is production-grade

Observability is critical.

You never know when you'll need this to troubleshoot or review performance of a system. Every service should expose some metrics. We instrument everything, but have created dashboards to view the important data.

Test the right things.

We love automated testing as much as the next software company, but we don’t test just for the sake of it. Unit tests and integration tests serve different purposes, so we test what we need to depending on the project.

Automation isn't a nice-to-have, it's required.

We automate everything. Period. In fact, there aren't even SSH keys on our servers—the only way to get code running at Replicated is to build into our automation pipeline.