Code to live by — product engineering philosophies by a successful studio

While many engineering philosophies remain true no matter where you work, we have learned some new truths over the past two years as we go about the business of engineering a product at Magnopus. In this article, Technical Director of Product, Sam Birley, talks about the values we've come to embrace as a team and how they're helping us build rapidly, and at scale.

The ‘Rubber Duck Method’ is a way of debugging code by articulating a problem in spoken or written natural language. It’s something the Magnopus engineering team swear by, and therefore rubber ducks find their way into nearly every piece of content they produce…

Back in August 2020, we published an article that articulated our philosophies and values as an engineering team. Today, we still hold ourselves to the same values. They’re referenced a lot both internally and externally.

But a great deal has happened since then – a pandemic, Magnopus going global with offices in the UK and US, and the building of a product engineering team across both locations. You see, we’re working on something seriously awesome.

And that’s what this article is really about. We have been and still are, evolving from a client-driven, agency-style organization to a product organization. The changes go deep.

Here are some of the philosophies and values we’ve come to embrace along the way within the engineering team.

Take care of your environment

The concept of service environments is part of any service-based product’s infrastructure worth its salt. If you plan to deliver a feature, you need to protect users from being affected by the change until you’re well and truly sure, at all levels (engineering, QA, and product management) that the feature is stable and doing what it’s supposed to do.

For us, that means maintaining three types of environments:

• Development – where developers can roam free, land changes incrementally, and experiment with ideas.

• Staging – where QA gets to vet new changes that have landed extensively and exhaustively, away from the hustle and bustle of the development environment. Only when everything looks rock-solid does it go to…

• Production – where users experience a rock-solid application that only includes features that have been battle-tested.

Embrace continuous delivery

The nature of the product we’re building - we’re navigating uncharted territory - means that we often don’t know what will work or won’t work. A lot of what we do is explorative educated guesswork based on the significant talent and experience we’re lucky enough to have at Magnopus. 

Of course, we don’t always get things right. That’s the human condition right there.

So the healthy thing to do is to embrace it – it’s ok to be wrong. We just need to figure that out as quickly as possible and adapt. The way we do that is through iterative development.

That means leaning into our values around Atomic Commits – rapidly and iteratively landing commits that continue to evolve a feature over time. That way, QA gets their hands on the feature faster, our product management team gets it faster, which means users can ultimately get their hands on it faster too.

If things aren’t panning out at any point, or we realize there was this amazing opportunity that the work has now revealed, we can pivot the feature fast.

We are one team

This one is true in many ways. Since 2020, we’ve grown to be an international organization and now are composed of multiple engineering teams working on different tech stacks within the UK and US.

We’re all one team though. We have to be. We all have a part to play in whether we’re successful on our journey to make this seriously epic product.

Whether we’re working with someone in our team, helping them fill a knowledge gap (No Egos), or working with an entirely different team on the other side of the planet, we need to have each others’ backs to get there. 

How do we do that? Every team is different, but these two values are particularly helpful.

Empathy

Empathy is such a vital part of healthy communication – understanding where someone else is coming from and what they’re trying to achieve is the first step in being able to help them. And if we’re not helping each other, then we’re not acting as one team. There's always a real person on the other end of the line, and they care just as deeply about the success of the work, even if their perspective is divergent.

Communication

If you’ve bought into empathy, the next value is communication, because if you can’t effectively communicate a problem or a solution to someone else, you can’t function as a team. Whether your team is located on-site or fully remote, fragmentation of communication can and will happen and you absolutely have to build a culture of regular, frequent redundant communication to manage that. Overcommunicate. Crosspost. It’s on all of us, at all levels, to ensure that the right people can’t miss the thing we’re sharing.

It’s OK to waste a bit of time

It’s controversial. Also not related to evolving into a product software engineering team. But that isn’t the only major change for Magnopus in the past two years. The pandemic has caused us, like many others, to evolve into a hybrid workplace, with some staff fully remote, some in the office, and some a mix of the two.

Continual Zooms/Google Meets/MS Teams Calls/carrier pigeons are exhausting, and worse, they can reduce all interactions with your team to be very functional. Meetings are booked with the intent to discuss a matter, so people come to the call with that topic exclusively in mind for conversation.

As a result, it can become easy for people to feel disconnected, siloed away without any means to just be humans together. 

So, to try and bring a bit of that humanity back, we’re actively encouraging people to spend a few minutes at the top of the call just chilling, having a catch up. Let’s be honest, there’s always a few stragglers to a meeting in any case, so you might as well fill the time and connect.

We all own our code

If you were to show the application you were making to your friends, would you be proud to show it off? That’s a question that’s often asked at Magnopus, with the answer ideally being a resounding ‘yes’. We should be proud and excited about what we’re building. And honestly, with what we’re building, it’s pretty easy to be.

But more importantly, if every individual feels proud of the work they have accomplished, then as a whole, it means we’re invested. We care, and will work to ensure our applications are polished, robust, and offer a really great user experience.

How can we feel pride in our work? Well, it’s a lot easier when we feel we have a degree of control over what we’re making and can be responsible for the choices made along the way. What we’re building is the product of many incredibly talented individuals across many teams working on many features – they deserve to own their work, and they’re likely able to navigate the many choices required along the way better than anyone else. So we encourage everyone to speak up and speak out. We welcome everyone’s input.

Embracing that, understanding that we all own this together – across an uncountable number of decisions, features, applications – lets us take pride in our work. And with pride comes kickass applications.

Build for forever 

Possibly the biggest difference between product and project, is that the lifetime of a project is finite. It has a start and end. Building a product, you have to assume that there is no end – because if we do our jobs right, we’ll have built things people will love and use forever. And who doesn’t want to aim for that?

Building for forever changes your approach to designing software. You have to think holistically about the software you’re building and how it relates to the health of the overall product architecture.

Sure, you can only design knowing so much about the future. We’re not mystics, and there’s a lot about the future of our product that we don’t know. That then just becomes another variable in the fun architectural design equation you need to solve. Make it last, make it flexible, and more than anything, make it extensible.

It’s worth noting that this is as true as much for the teams that you’re building as it is for the architecture. You have to approach building product teams with the expectation that the people you hire will want to keep working here forever. It’s certainly the kind of place I want to work. That means considering the same things: build teams that will last, are flexible, and of course, are set up to scale gracefully.

We think it’s about fearlessly thinking about the whole. Step back occasionally and take a look at what everyone is building together. Take time to consider what you're working on in the context of the entire product. 

Here at Magnopus, we really are making something amazing, and we're doing it together. Every voice and every contribution matters.

And if we do our jobs right, everyone will want to join us on our mission.