BigCommerce Employee Spotlight: Shaun McCormick

Welcome to the BigCommerce Employee Spotlight. Each month, we’ll chat with an employee who works on the BigCommerce product. These are the folks behind the scenes who are crafting the BigCommerce developer experience, from SDKs and APIs to themes and documentation. Discover what they’re building, their tools of the trade, and learn about the technologies they’re passionate about.

We sat down with Shaun McCormick, Senior Staff Engineer at BigCommerce, to talk about leading a large engineering team, automating development, his views on open-source software, and more.

Hi Shaun, Tell me about your path to BigCommerce.

When I was in 5th grade, my parents bought me a C++ book, and let me get on CompuServe a few times a week. As the internet opened up, I discovered HTML, and later PHP, and pretty much from there spent a ton of time building websites and applications. I loved the infinite possibilities that the web presented, and how quickly you could build things that people could use to make their lives better. There really was nothing like it at the time. I continued programming, doing engineering work on the side for a while before going off to college.

During school at The University of Texas at Austin, I started in Computer Science but eventually majored in Religious Studies with a minor in Creative Writing. It surprises people when I tell them that. When I was in college, I had a good engineering mentor who advised me that if I was bored with school, I should instead major in something that taught me how to understand and talk to people with different world views instead. Turns out, he was right — being able to understand people with totally different mindsets and approaches to solving a problem has been invaluable in my career. It also taught me how writing and communication matters, and that’s given me a huge leg up.

Before BigCommerce, I worked for a startup called MODX Systems, and helped build MODX, a PHP open source CMS, along with their cloud-based lifecycle management solution, MODX Cloud. I learned a lot about open source working there, and really cherished my time building a product that millions of users used, seeing it grow and mature, and learning a bunch of new things along the way.

Finally, I moved on to BigCommerce, where I was initially hired as an Engineering Manager to start up the Austin Engineering office. I was enticed by BC’s rapid growth and can-do culture, along with their rabid transparency and honesty about what they needed to grow. It was a great challenge. I later moved into an individual contributor (or non-management) role, as I felt I could make a larger impact working on the technical foundations of the platform as it scaled, and have been enjoying that since. BigCommerce offers its engineers lots of mobility to find a place they can thrive in, and gives them lots of opportunities to make a difference. It’s nice to work at a company that values its people in that way. It’s been a fun ride.

What do you work on?

I’m a Senior Staff Engineer at BigCommerce, which means a lot of things, but my main focus is on two initiatives:

1. Making sure the direction we’re taking our software is scalable, stable, and observable now and in the years to come.

2. Educating and mentoring our senior engineers to help them grow.

With a large engineering team, we have many moving parts. Making sure that our engineers have the context they need to build software well — both individually and together — is often my day-to-day. This means I wear a lot of hats. I’ll generally start my day with 1 or 2 major things I want to accomplish, but otherwise I’ll leave a lot of blank space open. This gives me dedicated time to work on some of the deeper-dive problems and also gives me flexibility to assist and coach others on their solutions. Being a Staff Engineer at BigCommerce means a lot of your job is vision casting, directional, and informational. You quickly realize that you’re only as effective as you communicate and educate.

You also set the culture — people will follow your lead, regardless of whether you directly interact with them or not. Be defensive? The organization will silo. Want to be the decision maker for everything? People won’t grow, as they’ll just rely on you. Don’t proactively communicate? Other engineers won’t either when you need them to.

That doesn’t mean I’m not working on longer-term technical initiatives. The Austin Platform team generally governs the Google Cloud-based development environment we are over, the observability tooling for services (such as distributed tracing and exception monitoring), and other more product-centric areas, such as the authorization and authentication domains of our platform. I’m also one of the top subject-matter experts for the Ruby side of our platform.

I’ll also try to devote at least a fourth of my week to documentation writing, open source work, or what I call “grease.” These are tasks specifically targeted to make our Engineering organization faster and more efficient. I’ll also spend a lot of time reviewing pull requests and our RFCs ( Requests for Comment), which are proposals for services and architectural changes at BigCommerce. These are golden education opportunities, and provide a great way to inform others of context they may not have known before.

Describe BigCommerce in three words.

Tenacious, committed, and democratic.

BigCommerce has always had a large challenge in front of it - — to go and democratize e-commerce in the face of rising large competitors and established systems. We’ve thrived based on a tenacious belief that offering more functionality at better pricing is the key to our success. We don’t charge transaction fees, instead basing our pricing on growth, which incentivizes our business to be aligned with the growth of your business. This is a much healthier model, making sure every day that we can ask the question, “Does this help our merchants?” If it doesn’t, not only is it not good for them, it’s not financially good for us as a company either. There’s an implicit, intentional, coupled bias in favor of our merchants, that I believe is key to BigCommerce’s success.

And BigCommerce is committed to that. Over the course of my time at BC, I’ve seen it grow, move upward, and embrace new technologies, but the one thing that has stayed is our commitment to our merchants. We spend a lot of time thinking, caring for, and supporting our merchants in their business endeavors.

Finally, one of the things I love about the BigCommerce Engineering culture is that we’ve structured it to be ruthlessly democratic. We don’t believe in “ivory-tower” architecture, where a small group of individuals dominates the conversation around our platform. Instead, we have a robust RFC process where any major new initiative gets publicly put into a comment period that anyone in Engineering can be involved with.

This creates a healthy, vibrant culture around cooperation and encourages people to speak up and share knowledge. We do a lot to defend this culture, encouraging new engineers to contribute to it, and making sure that comments in our RFCs are always constructive, positive, and supportive — especially during disagreements. Basing our process on the foundations of Internet Engineering Task Force’s RFC, it gives engineers more context than they would have had from only their local teams, and helps establish comity between our distributed offices.

What is an important problem that BigCommerce is solving?

Simply put, our biggest initiative is offering enterprise-grade functionality without charging enterprise-level prices. We want to provide a model of partnership with merchants that emphasizes “growth together,” that doesn’t try to nickel-and-dime you on hidden fees or apps. Providing an eccommerce platform means offering high-grade ecommerce functionality as a part of a unified, complete product. We want to make it easy for a $1k revenue a year business to grow to a $1M/year business, and for that firm to feel that like platform fits them well the whole way.

Part of this means we have to stay relevant by offering the core functionality our merchants require. For a lot of merchants, scalable and flexible catalog management is key. For others, having a fast, SEO-optimized storefront is. For our highest revenue merchants? They care a lot about security, stability, and integrations.

In order for us to achieve all those goals, we take hard-line focus on making sure we’re building a scalable service-oriented architecture at BigCommerce. We’re focusing on API contracts above all, allowing us to rapidly open up our platform and provide more and more functionality to our merchants without having to rebuild constantly. We have a robust API layer at the platform level that can handle huge amounts of traffic, including bursts from large flash sales, for example, and resiliently handle failures downstream.

What projects are you most passionate about building at BigCommerce?

As an engineer that works on Platform-level initiatives at BC, I’m constantly asking myself a single question:

Does this make our Engineers faster and better?

I’m really passionate about removing friction. In a large engineering organization, there can be a lot of friction, as there’s simply so much for newer engineers to learn. There also can be a lot of boilerplate to setting up new services, or making them observable, that I spend a lot of time on making as simple and easy as possible.

This is probably my favorite thing to do: it’s an immensely joyful feeling to see someone take a tool you’ve built and realize how it helps them move faster and get more insight into what they’re building. “That’s all I have to do? That’s it?” is one of my favorite phrases to hear.

This also means focusing work on an often-neglected part of an engineering platform: the development environment. A lot of companies will just rely on engineers to hack together something on docker, or put everything in a large computer/monolith/mash that doesn’t really match production but kind of works in a slim majority of cases.

We wanted to do better. Our development environment at BC is designed to make development as “like production” as possible (containers run in virtually the same setup as production) and has tons of tooling to make life easy. You run most of your environment in Google Cloud Platform, only using the services you’re actively developing on locally. And we have tooling that “hooks up” your local services via DNS to simulate them running in GCP via a simple YAML file you can edit. This makes for a seamless process when developing software — no manually editing environment variables or settings. Just run “bcloud dev” and your laptop is now “in the cloud”, as our engineers like to say.

Secondly, in Platform Engineering, we believe a lot in observability. Observability is far more than instrumentation, or monitoring, or alerting. It’s a whole mindset: when an incident happens (which they do!), you want to know far more than just what is affected. You want to know how and why it was affected, and where that’s coming from. You want to be able to dive straight in to important metrics, and understand exact points of failure.

Getting a system that allows engineers to do this — in a PCI Level 1 environment to boot! — requires a lot of work. Using tools like LightStep, Sentry, and Prometheus gives us a lot of this. On any given day, we can tell you the p9X’s of any endpoint or storefront for any given store on the platform. It also requires a lot of education — just building neat tools isn’t enough; you have to give people the knowledge and mindset they need to understand them. We do a lot of educational sessions across BigCommerce to help keep our engineers equipped and informed.

What is your philosophy on open source? How do you see BigCommerce becoming a more open platform?

I’ve spent a lot of my career in or around Open Source - — the company I worked for prior to BC was a fully open-source company. I truly believe OSS is the most reliable way toward scalable, sustainable systems. A good portion of my early time at BC was focused on moving it toward an OSS model, and establishing a clear process for open sourcing software at BigCommerce (we do so on the MIT license, and open source tons of libraries each year). This also means training engineers to know how to both find quality OSS work, and also to understand what it means to steward an OSS project. Hint: it’s more than just typing “git push”!

OSS engagement and contribution is vital toward scaling a large organization in a competitive industry. There’s simply so much to build, and we have to have a culture of utilizing the wonderful tools that people around the world have built. Furthermore, OSS improves not only our security but the security and performance of e-commerce as a whole. Many companies use and develop on similar tooling, and us contributing to those helps lift up the security and stability of the industry.

We take pride in our OSS work and try to uphold a culture of high quality in our offerings. For example, Gruf, our open-sourced Ruby gRPC framework, hit 100,000 downloads last month, but more importantly to me is it’s 97% test coverage and comprehensive code documentation. Participating in OSS also means involving yourself in the community. From hosting Ruby/Scala/PHP meetups to sponsoring local conferences, BC is committed to growing the larger engineering community however we can.

BigCommerce is committed to opening up as much of our platform as we can, while still keeping our merchants secure. Because of this, we proactively scan any and all libraries that are added to our platform, and do regular penetration testing over our service boundaries. This gives us the confidence to open up as much of our platform as we can. For example, we’ve recently been at work in developing a GraphQL API for our storefronts, making it easier to query data and provide a more seamless headless commerce experience.

Do you have any side projects you’re working on?

I’m a huge fan of automation and also a big board gamer. So I’ve spent some time hooking up Slack bots into boardgamegeek.com’s API, and adding all kinds of functionality for my board gaming group’s Slack so we can game harder. Other than that, I’ve been spending time diving into Rust (I’m really excited about its future), and continuing work on Gruf and other gRPC tooling.

Are there any tools that you use as a developer that have changed the way you work for the better or made you more productive?

I may sound like a broken record, but I really feel gRPC/Protobuf has completely changed the way we work with APIs at BigCommerce, and me personally. It’s really hard for me to want to work on a REST-based internal API now in any context, given the success I’ve found working with gRPC.

At BC, we use a myriad of languages for our services, and gRPC and Protobuf have made it easy to communicate between systems without having to write API clients all the time. It also has centralized our API definition into our Interfaces Definition Library (IDL), which houses all the internal API contracts for our platform. The IDL automatically generates the client/server stubs for us on pull requests and merges, making APIs extremely easy to build at BC. From there I can test on a service or with a GUI like BloomRPC to easily diagnose things. I just really can’t imagine working any other way nowadays.

I’d also say LightStep has transformed how I diagnose latency and performance issues. Before OpenTracing, it was often very difficult to diagnose performance errors without effusive logging or graphite metrics scattered everywhere. And even then challenging and time-consuming to piece it all together into a narrative. LightStep has transformed the way our teams view and adhere to performance, whether by getting immediate visibility into infrastructure or service-level performance across a distributed trace, or proactive monitoring based on latency bands or burst levels, it has given us the tooling to quickly understand the health of our platform.

How do you approach learning something new?

Number one: Be relentlessly curious. Every day I learn something new, and I’ve been in the industry for twenty years now. Don’t be scared of new systems, or codebases, or areas that you don’t have any expertise or familiarity with. No one starts an expert! The best way to learn is to assume you know nothing, and ask a bunch of questions along the way.

Tying into that, you should never be afraid of being wrong. The best engineers I know are wrong all the time. However, the difference is that those engineers learn and adapt from their mistakes, and use those opportunities to learn and grow from them. And they have a relentless belief that being wrong isn’t a moral judgement on them (or anyone else), but simply a knowledge gap that can be bridged.

Finally, try, try, try. Don’t let analysis paralysis get in the way. I’m constantly iterating and testing and prodding at systems to get them to be better. I’m experimenting with things on the side in feature branches. Instead of dismissing ideas, or saying “that’s too hard.” I timebox a bit of time each day to “go spelunking,” so to speak. If the crazy-impossible problem ends up being crazy-impossible, then at least I know that. If not, I’ve just solved a problem a lot faster than I thought I could!

We’d like to thank Shaun for sharing his time with us and giving us a look into his day-to-day at BigCommerce. Follow Shaun on Twitter @splittingred.