Engineering Tenets: Character
In our new 4-part series, Director of Engineering Spencer Norman explores the ways in which Reaction Commerce’s engineering tenets lay the foundation for a successful technology-first organization. Each week, Spencer will dive into one of our four overarching themes—communication, character, competence, and care—along with the core values that drive each principle.
Being a great software engineer involves much more than understanding design patterns, parsing data structures, and knowing when to use binary search. Are these “hard skills” important? Yes! But without having certain other “soft skills,” computer science principles—no matter how sophisticated—will be limited in their usefulness. Just as it’s difficult to develop great software without great communication, we believe that being a great software engineer requires strong character.
While we each have our own specific roles at Reaction, every engineer is expected to empathize with customers, community, and coworkers. Empathy may come naturally to some and it may be hard work for others, but at the end of the day, we expect all engineers to practice empathy by maintaining a platform mindset, whether they’re writing code, creating or responding to issues or pull requests, or contributing to documentation.
What is a platform mindset? At its core, it’s the understanding that what we’re building is not the final product. It means engineering with the expectation that others will extend the software we’re writing in ways we can’t even anticipate right now. It means recognizing that what we’re building is a layer that will have many more layers on top of it, and even more layers on top of that. The platform mindset requires empathy towards the developer who will be building those future layers.
In practice, this means that we architect in services, interfaces, and components. We engineer with composability and scalability in mind, and we make sure our code is well-documented, including both proper jsdoc as well as inline comments. Overall, we don’t want to make any assumptions over how future devs might use our software. We also don’t want to make any assumptions over who our future devs might be, what language they speak, or how they access our content. This is why all code is i18n and a11y-ready, which we enforce through automated checks via linting and peer code reviews. This is also why, out of the box, Reaction ships with support for 11 languages and 9 currencies, including languages written right-to-left.
In order to constantly learn from each other and from our community, it’s incredibly important to acknowledge that what we don’t know matters enormously. Once we’ve acknowledged that the set of knowledge we don’t possess is far larger than the set of knowledge that we do possess, then it becomes far more likely for us to hear feedback and grow from it. While this acknowledgement does not exempt a person from having an opinion—in fact, strong opinions shape what we build and how we build it—it does encourage open-mindedness.
Being open-minded means that we hold on loosely to our opinions while constantly considering other perspectives with empathy, not with argument. We can always change our opinion as we learn new insights or consider better ways to do things. And with a company full of opinionated, open-minded people constantly questioning the best way to do things, we’re bound to have some disagreements from time to time—it’s an expected outcome. To handle disagreements, we have a framework in place, which is similar to Amazon’s Disagree and Commit principle: challenge decisions, let things go, support what’s next.
And of course, while everyone is entitled to have an opinion, not everyone is entitled to make a decision. When it comes down to decision-making, we try to make the best one possible based off of qualifications, timing, and the information provided. Once a decision has been made, everyone is expected to commit that decision as if it were their own. This doesn’t mean they have to give up their opinion, but it does mean their efforts should now get channeled toward the agreed upon direction.
As engineers at Reaction, our responsibility is toward the organizational goal we’ve set out to achieve—our north star. Whatever we’re working on should be evaluated in light of that north star. In practice, this means thinking critically about any assignment we’re given. It means getting clarity on the objectives before starting to work on it. It also means taking on the responsibility of getting this part of the project done. As with any issue, it’s the assigned individual’s responsibility to either solve or escalate that issue.
In a sense, we don’t really have engineers work on tasks. Occasionally there are little chores, such as updating plugin dependencies or updating docs, but simply getting these things done without considering where we’re going isn’t necessarily demonstrating responsibility as an engineer. Achieve the goal, don’t finish the task.
The best software engineers are the ones who continually learn new things. On some days, this may mean learning new patterns, frameworks, and libraries, while other days, it may involve listening to customers and learning about their particular workarounds. When we’re able to be better today than yesterday, that’s when we consider what we do here a success. How do we do this? By getting things wrong.
We expect engineers to help identify problems in our processes. When we encounter errors, either in our software, our docs, or our process, we attempt to identify what led to that error. Then, we try new ways to improve the process, so we don’t make the same error a second time. In this way, we learn together, as an organization. In this way, we grow together as well.
The Merriam-Webster dictionary defines the word ‘character’ as “the mental and moral qualities distinctive to an individual.” I would also add that character is what makes up the difference between a ‘coworker’ and a ‘teammate.' When you think of it this way, it's hardly a soft skill at all.
I hope you learned a little more about the guiding principles of our engineering team. Next week, we'll cover competence. Stay tuned.