Learning on the Job
In April, I wrapped up my first 12-month placement as a Dev Degree student, working as a back-end developer on Shopify’s Docs & API Libraries team. The team builds the tools and documentation that let other developers create apps on Shopify, and the projects I took on taught me a lot more than how to write better code. I came away with some useful lessons about how learning works, how to ask for help, and why representation matters.
Dev Degree pairs classroom study with paid work placements. I spent eight months learning Ruby, databases, front-end development, and other fundamentals with nine other students, splitting time between Shopify and York University. In May 2020, I moved into my first real team placement. That year turned out to be a crash course in how developers actually grow.
Your Definition of “Basic” Keeps Moving
The learning curve when I joined the Docs & API Libraries team was steep, and months in, I still felt like I wasn’t making progress. My lead suggested I keep an Achievement Log—a running list of wins, big and small. Looking back at it now, I can see it’s a record of growth, not a list of trivialities. What I once considered major victories now look small, but that’s exactly the point: my bar for "basic knowledge" rises as I learn more, distorting my sense of progress.
One early milestone stands out: my first pull request. I was new to the Shopify CLI, the command-line tool that helps developers scaffold apps, and my task was to let it accept all Rails flags when generating a Rails project, like using --db=DB to change the database type. It took considerable guidance and plenty of wrong turns to land, so shipping it felt huge.
Mentoring made the progress visible in another way. When I paired with first-year Dev Degree students on similar tasks, I’d catch myself answering the exact questions I’d asked just months earlier. Seeing them start from zero, the way I did, was a good reminder that everyone begins with no context and a lot of curiosity.
There’s No Such Thing as a “Real” Developer
Once I’d gotten comfortable with the CLI, I picked up a project to add themes as a project type. My first feature was scaffolding a theme, which brought me to a task I’d been dreading: writing tests. I knew my code and understood the scenarios that needed coverage, but I couldn’t figure out how to structure the test files.
My lead’s suggestion was simple: mimic the tests from the Rails project type. The code was similar, and I had familiarity with the Rails implementation. The idea had never occurred to me because it felt like cheating—not what a "real" developer would do.
I got curious about what other interns thought a "real" developer looks like. Their answers included people who code in their spare time, run world-changing side projects, or never touch a GUI and live in the terminal with dark mode on. My own hangup was that real developers solve problems creatively without copying existing examples. But observational learning turned out to be powerful. Watching an experienced developer work through a problem in pairing sessions, then studying existing code to figure out what questions to ask, gave me a foothold. I learned to write tests by understanding and adapting the ones in front of me. Copying what works is a legitimate path to learning, one bite-sized piece at a time.
Imposter Syndrome and the Cost of Not Asking
My first team project at Shopify was the Shopify Admin API Library for Node, a TypeScript library that handles authentication, GraphQL and REST requests, and webhooks. A teammate suggested I add GraphQL proxy functionality, which seemed simple to them. For me, it was anything but. I found it hard to admit the level of help I needed.
I spent weeks puzzling over the task in silence. My team kept reassuring me I was doing well, and friends told me to have more confidence. But I was hiding something real: I was genuinely lost, not merely underestimating myself. Often, what we attribute to imposter syndrome is actually just acknowledgment of how much we still have to learn. My lead eventually had to step in and help a great deal.
The lesson stuck. Asking for help is not a failure; it’s part of the learning process. My team members told me repeatedly they wanted to hear me ask for help more often, and I’ve gotten better at it. Asking a senior developer for time is reasonable; expecting an intern to know everything on their own is not.
Learning Is Supposed to Feel Slow
After the Node library, I moved to the Shopify Admin API Library for PHP. My first task was adding the Context class, which carries important information about a user’s app and shop across the library. I’d never touched PHP, so I was excited to learn. Then I fell behind and grew frustrated. I had just spent months on a nearly identical library—shouldn’t I have hit the ground running?
As a part-time Dev Degree student, I work roughly half the hours of my teammates, and inexperience slows me down further. I caught myself comparing my pace with theirs and feeling I wasn’t fooling anyone when they called me a quick learner.
So, I applied what the GraphQL proxy debacle had taught me. I asked teammates to review my draft PR continuously while it was still evolving, so mistakes could be caught early. The approach kept me on track and also changed my perception: their input showed me I was less far behind than I had assumed. Learning became collaborative rather than a solo slog.
The truth is, learning is a slow process. It feels that way because it is. Not knowing is frustrating, especially when others seem to understand. The seasoned developers around me weren’t acknowledging that I caught on instantly; they were recognizing progress only relative to where I started—and celebrating that.
Representation as a Strength
Growing up, I didn’t see the point in representation—if nobody like you had done something before, you’d simply be the first. But that was the same mindset that made me believe I could never be a teacher because my last name “didn’t sound like a teacher’s.” That habit of acting unfazed by my differences followed me through school, extending to my gender, disability, ethnicity, and age. After dealing with covert sexism and ableism in high school, staying unbothered became harder. When I first started contributing to an open source repository, I worried about how a stranger might judge me from my GitHub profile picture alone.
That nervousness has faded. I haven’t faced that kind of situation on my team, and everyone I work with regularly invites me to tell them when they aren’t being accommodating enough. I’m always entitled to support and inclusion, but it’s my job to explain how others can help. Shopify even has an autism support Slack channel, where I can see people like me doing impressive work and ask for advice.
Looking back at my achievement log, one thread runs through all the highlights—beyond the learning and wins I’ve already described. It comes together in a final story. My lead asked each team member to fill out feedback forms about their coworkers. The last question was “Anything else to add?” I tentatively messaged a teammate to ask whether I could note how much I appreciated her openness about her neurodiversity. Having someone like me on the team meant a lot, I said. To my surprise, she said she’d wanted to write the same thing about me.
Valuing representation isn’t weakness or pettiness, and there’s no need to appear untroubled by difference. It lets us value and empower each other for who we are, what we stand for, and the impact we have.
That wraps up my first Dev Degree placement: the problems I tackled and the lessons I picked up. I still have plenty to learn—there’s no quick fix for the challenges that come with growth. But if I carry one thing into my next placement, it’s this: there’s so much learning involved, so get comfortable being uncomfortable. Face that head-on, and remember that learning is collaborative.
