How we work: Backend Engineering

Have you ever pushed code to production and had that feeling of existential dread that you missed something? Or have you spent weeks working on a project only to find out in code review that you missed an obviously simpler and better solution? Of course! 

Maybe there are perfect immortal programmers out there somewhere, but we need a strategy for the rest of us. Here at StrongDM, we have a set of practices in backend engineering that help mitigate the human in the middle of the development process.

Pair Programming

Most engineering teams believe in the four eyes principle these days. Anything that goes into production needs to have at least two humans reviewing it. It’s a great way to catch mistakes, and it’s a simple principle. Code reviews are the most common way to accomplish this, but at StrongDM we do pair programming. Like real 6 hours a day pair programming on one machine. We operate in pairs as atomic programming units. We do our pair programming over Zoom, and we all have near identical hardware and software setups so that we can take over anyone’s machine to jot down an idea or explain some code.

This is totally weird at first and exhausting if you aren’t used to it. During my first week here, my wife was annoyed because I’d finish programming for the day and then go immediately to bed. But like anything, it gets so much easier with practice. After a few months, it has become my default mode of working, and it’s weird when I’m programming without a pair. We have this idea internally of a phantom pair, where you hear the voice and opinions of your pairing partner when they’re not really there, and it’s totally true. 

It’s a lot, so why do it?  That’s a hard question to answer. We move a little slower than if we were programming alone. It takes a lot of energy to constantly be expressing your thoughts and ideas and exploring alternatives. Yet I’ve written some of the best code in my life over the past year. We still make mistakes and miss things, but the conversations that we have really elevate our programming.

Finding Consensus

The nature of pair programming is by consensus, and we apply that to the overall engineering organization as well. When we want to make changes to how we work or to the architecture of our applications, we pull in all relevant parties. We take the time to have good discussions and come to the best conclusions. We can do this because we treat each other with enormous respect and know that everyone here is a capable engineer. This really showed when I interviewed with StrongDM and was one of the main factors in my joining the company. Consensus means that anyone can bring ideas to the group, and everyone is excited to explore them.

Project Management

How do we actually do work? We first look at projects as either product or engineering-focused. 

• Engineering projects are generally promoted by the engineers, and time then gets allocated to accomplish them. (We have a whole philosophy around technical debt, but that’s another post entirely. Short version—if we see something we can reasonably fix, we just do it.) 
• Product projects, though, are far more complex, and there is an entire process based around identifying them, building them, releasing them, and launching them. 

I’m going to focus on how we build them, but I hope we get a post out about launching them in the future.

How We Build

Our approach to project management has evolved since StrongDM was founded, and it’s constantly evolving. Right now, one of the teams is investigating how to apply some of the principles of agile development to reduce miscommunication. However, backend is currently based around establishing the product requirements and objectives and then iteratively building out the software to meet those requirements. We have a kickoff meeting with a broad group of stakeholders where we explore the request from product and identify any questions that need to be addressed before we begin. Then the pair assigned to the project begins to scope out the project and explore the ideas around the project. They may have some throwaway spikes, and often they will pull in the rest of backend engineering to discuss their findings. 

Once an approach is decided upon, they begin to implement, with weekly check-ins with Product. Most aspects of the project are negotiated as the project progresses, including understanding the timeline. We don’t obsess over deadlines, rather we try to make good estimates but don’t compromise engineering quality to meet them. 

Along the way, we try to make small releases into the production systems rather than having one big day where we release everything. There is a huge topic about how we build and release software, but the simple version is we have a CI pipeline that builds assets and runs tests against them. We don’t have a ton of procedure in place. Instead, we offer guidelines that give engineers the autonomy to build good software and go as far as necessary.

StrongDM is built around the people, and engineering is no exception. We want developers to enjoy working on software here. So, hopefully, this gives you a little glimpse into the day of a life of the backend engineering team at StrongDM. We’re hiring and growing like crazy! We’ve got the numbers and funding to back it up. 

Thanks for reading. If you’d like to learn more about working at StrongDM, come check us out!