Don’t ship code in your first 30–60 days
I’ve experienced some internal tension (in my head) in my third and fourth week at my new job at Shopify. It’s the tension that arises from wanting to be a valuable member of the team as soon as possible when I’m not yet ready to do anything that will move the proverbial needle on our projects.
The talk in my head sounds something like this:
Man, I’m already in my fourth week on the job. I’ve joined many daily stand-ups and I can tell that everyone else on the team is working on things that make an impact on our merchants’ lives. I can see the backlog is healthy and there is plenty needing to be done — plenty of impactful work to ship new features or to clear technical debt.
And honestly, I’m sure I can take on a ticket if I pushed myself hard. I’m also quite confident that I can lean on some of my teammates for answers and guidance if I asked. If I don’t take a ticket soon, people are going to think that they have hired the wrong person for the job. They’re going to think, “why is he not doing what he’s hired to do? How long is he going to hide behind the veil of being new?”
But I know intuitively that heeding this inner voice is stupid. At any company that is bigger than, say, 100 people, there is a lot more value in using time as new hires to gain context.
Context like:
- mission: why does the company exist? Who does it exist to serve and therefore, who should we be obsessed about?
- culture: what do the leaders and employees value in this company?
- culture: how do people like doing things here?
- culture: how do people like to communicate? Is swearing to express strong feelings okay? Is communicating with GIFs considered juvenile or fun by most people here? Do people start sentences with lowercase letters?
- engineering culture: do people welcome or even expect their ideas to be challenged, or do they expect seniors to have the say?
- engineering culture: how holy is automated testing in this organisation? Is there a stack that every engineer should default to? Do people break that rule? Do people break rules in general if they have good reasons to do so?
- engineering tooling: what are the core programming languages that I need to know in order to do my job well? Which ones am I weak at and could brush up on before contributing pull requests?
- engineering tooling: what’s the workflow for setting up my local machine for development? What are some neat tricks like editor extensions, browser extensions, hotkeys, etc. that engineers here like to use?
- engineering infrastructure: how are the main services grouped? How does this service talk to that one? Why does service X need to talk to Y when Z, which X talks to, is already talking to Y? Is there a strict process to follow when collaborating across teams, or is it more of a fluid thing guided by a lightweight framework for getting things done?
This list isn’t meant to be exhaustive but indicative of the valuable things other than contributing pull requests that new hires (like me currently) can spend their time on.
A funny thing: the core programming language at Shopify is ruby. It’s a well-known fact in the ruby community that Shopify is one of the largest software built with ruby. And I don’t know ruby. Yet. And yet, I got hired. Why? Because I’m trusted to be able to learn the language in a relatively short amount of time (but not no time) and then contribute.
I said these words aloud when I was chatting with one of my new teammates today: I am going to resist the urge to take an issue from the board until week seven or eight and instead, focus on gaining context and sharpening the tools in my belt. I believe this way I’ll be able to contribute far more and in shorter cycles when I’m finally done with onboarding.
Focus on onboarding when you’re onboarding. Gain context of the organisation. Sharpen your tools. Then and only then go take on the hard challenges!
