What Next?

Earlier this month, my employment at Shopify came to an abrupt close. I’m currently reflecting on my next move.

I have continuously been either employed or seeking immediately employment since my first semester of university. 17 Years. This is an opportunity for me to reflect and ask myself the big questions: who am I, and what do I want?

During my two years at Shopify, I conducted dozens of job interviews. I always introduced myself to candidates by describing what brought me to Shopify and what kept me there:

  1. The people. This is the most important thing. Life is too short to work with jerks and the people I work with at Shopify are kind.
  2. The technology. React Native and TypeScript are a really fun way to build quality mobile apps.
  3. The company mission. I need to work for a company whose mission aligns with my own personal values.

Through repetition, this introduction had become so automatic that I had stopped even thinking about the words. Are these the same reasons I would join a company today? Or has the last two years changed what I’m looking for?

The first point about people is absolutely non-negotiable. I won’t spend half my waking hours working alongside jerks.

But the second and third points… they made sense at the time but I don’t think they’re adequate for me to evaluate if a new role will be the right fit.

Let’s break down what I’m looking for by a few different themes.

Career Track

Historically, software developers have had two career tracks: Individual Contributors (ICs) and managers. If you were lucky, you could graduate from “senior developer” to “architect” and spend your days contemplating large technical decisions. But this was an exception, not a career track.

Over the past decade or so, we’ve seen a shift away from the dichotomy of ICs and managers. The “Staff Developer” role is more than a “Senior Senior Developer” – Staff Developers are technical leaders that fit between and outside of IC and manager roles. This recent Shopify blog post explains it well.

I’ve been working as a Staff developer for several years now, both at Artsy and Shopify. The role gives me a lot of autonomy and it comes with high expectations. Autonomy and high expectations go hand-in-hand; depending on the work environment, this can be gratifying or frustrating.

Over the past few weeks, I’ve contemplated a move back into a strictly IC role. There’s a part of me that wants to get into flow state and just churn through tickets. Spend all day coding. Let someone else handle the big decisions.

But I don’t think it’s a good idea.

In a team setting, I naturally gravitate towards whatever work needs to be done most at the time. I intuit what the team needs to accomplish its goal and I make sure it gets done. Sometimes what the team needs is an architect, sometimes a mentor, sometimes a Product Manager, and so on.

I like wearing many hats. If I moved back into an IC role, it wouldn’t be too long before I naturally found myself back working as a Staff Developer.

I’ve also considered a move into management. With time, I think I could be a great manager. But I worry that becoming a manager would take me even further from the technology side of the business. As a Staff Developer, I already code a lot less than I did as an IC. My role is making the people around me more productive through pairing, mentorship, prototyping, etc.

As a manager, my role would be helping my direct reports grow. But as a Staff Developer, my role helps the entire organization grow. (That’s why I think being a “Staff Developer” means that you develop the staff themselves.)

So: Staff Development it is.

Company Size

I’ve worked in tiny startups where I’ve been employee number ten; I’ve worked in large companies where I’m closer to employee number ten thousand. I’ve seen small companies grow over time and I’ve seen small companies that have been acquired.

I used to think that I preferred working in small companies. What I’ve realized, however, is that I am adaptable to any company size. What’s more important is the autonomy I have within the company.

For example, when I’m writing a mobile app and I encounter a bug in the backend API, I want to be supported and empowered to fix that bug myself. I do not want to file a bug report and wait for a backend developer to fix the bug for me.

How this example plays out has less to do with the absolute size of the company than it does with the company’s culture.

Company Mission

When I worked for Artsy, the company mission was a huge motivation for my day-to-day work. “Make all the world’s art accessible to anyone with an internet connection.” That’s a powerful statement. Over time, though, Artsy’s mission changed. “Expand the art market to support more artists and art in the world.” It didn’t really resonate with me the same way.

The change in mission statement was a discrete event; the change in the company’s actual mission was a process that occurred over time. The former only reified the latter.

What I learned is that I shouldn’t rely on the company mission itself to motivate me. Company missions change. My work ethic and motivation exist independently.

I still do need a mission to align with my values (eg: I wouldn’t work for a weapons manufacturer). If alignment matches, then my own motivation is free to flow from my values: the satisfaction of accomplishing quality work towards a worthwhile goal in a functional team environment.

Technology

This all brings us to the elephant in the room: the technology. What technology do I want to work with? When I was a native iOS developer, the answer was simple: native iOS technology. Then Artsy adopted React Native and I (eventually) came around to appreciate it. TypeScript is now my favourite programming language.

As I consider my next career move, I have an opportunity to re-evaluate the technology I choose to work in. React Native happened to me at Artsy. I rolled with that change into my work at Shopify. Do I want to continue? Do I want to build with native iOS technologies again? Or do I want to try something altogether new?

I originally became an iOS developer in 2009 because iPhones were so much more capable devices than desktop or laptop computers. They had cameras, microphones, GPS, accelerometers, and more. They were very personal devices. I delighted in delighting users.

This motivation still drives me. I still want to delight users. I don’t think now is the time to try something entirely different.

So.

I’ve been a vocal advocate for React Native in native iOS developer circles for years now. But I’ll be honest.

When I zoom out and look at apps built with React Native, I often see software that fails to delight. It is entirely possible to build delightful apps with React Native. But I must admit that it doesn’t seem to happen as often as with apps written in native technology.

I’m at a crossroads.

On the one hand, I could find a team using React Native that does prioritize delight. I could “be the change I want to see in the world” and push the envelope for baseline delight in React Native apps. It would be an uphill battle with no platform owner to define measures of success. Sounds like a fun challenge!

On the other hand, do I want to risk spending my time justifying a focus on delight? Or would I rather spend my time actually delighting users? A company that values the iOS platform enough to dedicate writing native software that only runs on iOS also seems more likely to prioritize delight.

(This is setting aside the developer tooling for these two ecosystems. I’ve grown quite fond of Prettier, ESLint, VSCode, and more. Then again, I still miss using Xcode day-to-day – and the developer tooling in Swift has matured significantly in the past few years.)

I’m considering this carefully.

If I choose to write software in native technologies again, it would not be a “return” to native iOS development. Rather, I would bring the lessons I’ve learned from React/React Native/TypeScript to Swift and SwiftUI.

No one crosses the same river twice, for it is not the same river and they are not the same person. I have grown and changed and so has iOS. Honestly, the prospect of leveraging my breadth of experience here really excites me. I don’t think many iOS developers have followed this path. This could be a unique way for me to contribute to both native iOS and React Native developer communities. That is very exciting to me.


With these four themes, I feel both closer and further from a next step. I know I want to do staff-level development in mobile software for a company whose mission I can stand behind. Beyond that, I could work at a company of any size using any technology.

I haven’t narrowed my decision at all. In fact, I now have more possibilities to consider than ever! At least I’m certain that among these possibilities is the next role where I can feel happy and fulfilled.

Wherever I land, I will do great work with a great team. The best is yet to come!


Please submit typo corrections on GitHub