The Making of a skutie

Prior to the start of my first term, a mentor of mine asked what I’d be doing at the company, and if I was excited. I replied with something vague about workflow software, and quietly hoped she wouldn’t ask a follow-up question.

In my defense, I’m a computing student and commonsku would have been my first proper software internship. I’d never heard of the promotional products industry before I got the offer. I knew commonsku made software, I knew it was a real company, with real customers, and that was roughly the extent of it. I’d also never done a traditional software internship, not with a full team, or a production codebase. I was excited about the opportunity, yes, but that didn’t take away the underlying worry that was attached: what if it’s boring? What if I was going to spend the next four months sitting next to work without actually touching it?

Eight months later I can report it was not boring.

A Warm Welcome

commonsku is fully remote, but that doesn’t stop the team from getting together in person now and then. My first day was one of those in person days. Walking into that office for the first time, I was nervous, not sure what to expect. Luckily, there were a handful of other new hires that had started the same day, so that took the pressure off pretty fast. At some point that day, Mark Graham and Catherine Graham (the founders) sat down with the other new hires and me, and walked us through the promotional products industry from the ground up. I remember being struck, less by the industry lesson (though it was interesting) and more so by how plainly they adored the business, and how they tried to share that adoration with us.

That was the first surprise. How open everybody was. commonsku is small enough for everyone to know everyone if they wish, and organized enough that this actually means something. You can Slack these same founders in the morning, and have a reply within the hour.

The meetings were another fun surprise. There was a lot more laughter and inside jokes than what anyone could have prepared me for. It wasn’t a distraction from work, but an integral part of how they conduct it.

Finding My Feet

After onboarding I moved to working from home full-time, joined the Ecommerce team and started learning two things at once: an industry and a codebase.

The industry came faster than I expected. Promotional products is an industry with lots of vocabulary, and commonsku’s platform is the workflow layer underneath a lot of it, handling quotes, orders, ecommerce, payments, all the machinery that a distributor might run on. Within a few weeks I could follow a meeting without nodding blankly.

The habits of a software team took a bit longer. I was new enough to software that I didn’t know what a standup was, and the team caught me up without ever making it feel like a deficiency. The harder problem was getting me to ask for help at all. There were a few tickets across the first couple months where I got properly stuck: hours of getting nowhere, then more hours, because asking around felt like admitting something.

Every one of these tickets came unstuck immediately in code review, where someone would look at what I’d done and suggest an approach I hadn’t considered. Somewhere along the way it clicked that I should probably just send a question over Slack, sometimes to my own team, sometimes to someone on another.

Two Terms, Two Teams

The work across two terms spanned two teams. As mentioned previously, during my first term I worked with Ecommerce, the team behind the branded online shops and the Presentations that distributors send to their end-clients. While I was there we shipped a ShipStation integration, so order data flows to shipping and fulfillment without manual re-entry, and Push to Shopify, letting users publish products built in commonsku to a Shopify store.

In my second term, I joined Enterprise, the team building for the platform’s largest customers. We shipped Client Catalog for enterprise clients managing large, structured product catalogues, and commonsku Payments, the company’s own payment provider. All four were shipped by the teams, I was just another engineer on them.

But “what projects” is the shallow version of the question. The deeper one is: how much of the job is actually yours? And the honest answer surprised me. In the beginning there was a bit more hand holding: they were a bit more careful about what work they’d let me do. By the first month when I’d grown accustomed to the codebase, the hand holding mattered much less to them.

To illustrate it best, they really trusted me. They trusted me to a shocking degree, breaking past assumptions of mine that closely associated the word intern with guardrails and close oversight. Code review obviously meant looking at what I’d written, but whether or not these suggestions were exercised was my decision. Testing my own piece was mine too, and not just running the tests, but deciding what needed to be tested, telling the team what needed to be looked at by official QA, and what could be dangerous or risky. At the end of the day, it was mostly my own judgment that stood between careless work and a broken system.

This same described conduct was true with everything. One-on-ones weren’t a formality but the place I asked what I was too unsure to raise in a group. Code review was input on my approach, not a rewrite of it, so the PRs I opened felt like mine. No separate intern track, but room to bring my own way of thinking, instead of merely executing someone else’s.

My teammates and managers were there not to check on me constantly, but to be there for me when I needed help. That made the work both empowering and freeing.

My Learnings

I came in expecting to work on a small piece of something. I left having seen what it takes to get a feature from a discussion to production, several times over.

The technical list is real: when I compare my understanding of systems now, to back in January, the contrast is stark. Scalability and load actually mean something to me now, because I had to think about them before I shipped, not because someone explained it to me. Maintainability turned out to be a real feature, not just some coding virtue people talked about. Working in a codebase with far more history than my involvement is its own skill, and it’s one I’ve kept trying to grow. All of that has transferred directly to everything I’ve built since. I’ve kept coding and building in my own spare time, on personal interests. My speed of development and the quality of my output have increased enormously, and I can trace it straight back to these eight months.

The worry I started with was that I’d spend four months next to work without touching it. What happened instead is that the work was handed over, and the consequences of getting it wrong came with it. That’s a harder thing to be given, and a much better one.

Thanks to both of my teams for a genuinely good eight months.