Our Strange Engineering Principles

These are a set of principles that guide how we build software at Strange Loop. You will see examples of these all throughout our codebase, and in the way we work with customers. We reserve the right to change them as we find better ways of working.

Always Be Learning

Software and customers are changing constantly, as technologies improve and markets change. Therefore, the only sustainable competitive advantage is the ability to learn.

We continually discover better ways to leverage technology and serve customers. We also continually learn about how our customers work and the challenges they face, so that we can build them better solutions.

Build Quality In

We define a high-quality product as one that works the way customers expect it to and is easy to modify in the future. Adding quality in after a product has been released can be difficult: customers will be using it and finding bugs, which creates support load that steals time away from everything else. Therefore, we build quality in from the start, even if doing so means that a feature takes a little longer to build. The time is paid back quickly.

Always Be Shipping

When we’re building a product, we make a long list of assumptions about how we think customers will use it. Naturally, some of those assumptions are wrong, but we only find out which ones when our product is in the hands of real customers. We therefore try to ship small increments of a product sooner to customers, and seek their feedback as quickly as possible.

Make Incremental Improvements

Our products are never perfect. There is an infinite list of features we could add, and bugs we could fix, and latencies we could optimize to make them better. Unfortunately, though, we don’t have an infinite amount of time to do them all!

Occasionally we will schedule time to make a large improvement, but most of the time we focus on making small, incremental improvements as we go. These small improvements compound over time: each one makes the system easier to develop and operate, which frees up more time, which allows more improvements to be made.

Fail Better Next Time

We will fail sometimes. Our services will go down, or our accuracy will be poor, or our features will be too difficult to use. This is a natural part of product development. When it happens, no blame will be apportioned, because everyone involved was already trying to do their best. Instead, in these moments of failure, our focus is on what we can gain from it. We dissect what went wrong, possibly come up with some action items, but above all else learn.

Create Leverage

We deeply embed our engineers with customers, so that we can understand their problems inside and out. Unlike a consulting firm though, we have no intention of hiring thousands of engineers to scale. This means we find ways to create more with less. We do this by building levers into every system we touch so that we can move mountains.

Think About The System

The success of our company is the result of a large, interconnected, network of “things”. There are customers, and engineers, and a CEO, and a CTO, and services, and databases, and machine-learned models, and public clouds, and many more things.

All of these interact in unpredictable ways to create a complex system. When we’re doing our work, though, we only operate on one tiny part at a time. This makes it hard to see the forest for the trees. When making decisions, we do our best to think at the level of the system, and do things that will benefit it as a whole.