A series of ever-bigger problems

Thoughts on growing as a software engineer

You’re reading Register Spill, my weekly newsletter. Every week I start a timer. 60min. What I write in that time gets published. Mostly unedited. It's what I'd write if you'd send me an email asking me what's on my mind.

Last week we’ve had calibrations at work. These are meetings in which managers and the executive team discuss the performance of all the engineers at the company in order for us to calibrate and be able to say “this is clearly level 3” or “this is close to level 5” and mean the same thing.

It’s very, very interesting because it gives insight in how other managers, or our Head of Engineering, think about performance and growth of engineers.

Since then I’ve been reflecting on what it means to grow as an engineer, what it means for me, and in general how I think about, well, work.

None of what I’m about to tell you is, in any way, definitive or even complete. It’s one particular way of looking into the kaleidoscope. If I turn it just slightly things might look completely different.

---

Here’s what I think: as a software engineer you grow to solve bigger and bigger problems.

It starts with small problems: a small bug, a small feature, an improvement. Someone has a problem - “this doesn’t work” or “this could be better” or “we’re missing this” - and you make it go away. It’s a ticket-sized problem, but you can take care of it so that the person asking for your help doesn’t have to worry about it anymore.

Then, over time, the problems get bigger.

A big feature that takes several weeks to implement: you take care of it, so that the person who wants the feature doesn’t have to worry about it.

Later, the problems become too big for you to solve on your own, but your boss can give you two other, possibly more junior engineers and you take them by the hand and you implement the features and the bugs and do the maintenance work with them over the course of months and your boss doesn’t have to worry.

Then, even later, the problems start to become abstract. It’s not features anymore, not clearly defined problems, it’s areas, or domains, or themes, or whatever you want to call it. Instead of getting concrete problems to take care of, it’s now your job to find problems and fix them. By now, very likely by getting others to help you fix them or fix them for you.

It only gets bigger from there.

It started with single tickets, then big features, then multi-feature multi-week projects, then it’s a whole area full of projects that you keep an eye and your hands on, then it’s possibly teams you take care of by making sure they work correctly, then you maybe grow to define what the projects in the area are, and then you end up helping define the areas.

From your boss’s perspective it’s the same thing, though: you’re solving a problem for them that they then don’t have to worry about anymore. It’s “I gave that ticket to Anna, she’ll take care of it”, then “I put Anna on it, she’ll implement this with the new junior dev”, then “Anna’s our domain expert there, she says we should do X”, then “Those teams? Yeah, Anna works with them and makes sure they perform well and solve the business problems we have in this area”.

---

---

I’m not going to put labels on each of these stages – “this is senior, this is staff” – because I think that varies from company to company. In some companies some of the problems I named would probably be owned by managers, or directors even, and not by engineers.

To me, it’s all the same: I’m an engineer that gets paid to create value for the business and the more experience & skills I have, the bigger the levers I have at my disposal to create value. Writing code is the first lever, then it morphs into defining which code should be written, then it can morph into ensuring that others know how to write code and how to define which code should be written.

In some companies, I bet, everything I said is wrong. But I’ve only ever worked in small startups and spent the last four years at Sourcegraph, in which autonomy and high-agency are the expectation from day one. What I described above maps clearly (which might make it wrong for others) to my own growth as an engineer.

Back in 2019, right after I joined I talked to Quinn, our CEO, and asked him what I should do. What he said was this: “Look, you have certain skills & talents and we here have problems that need to be solved. I want you to use those skills & talents to solve these problems.” And I was enlightened, as the saying goes.

Over the following years, with Sourcegraph growing from ~20 to ~250 employees, I’ve seen the same thing over and over again: a problem becomes important, so we hire someone to take care of it.

Problem: sales doesn’t scale anymore, because the CEO can’t be in every meeting. Solution: hire a Head of Sales that takes care of that problem so the CEO can focus on something else.

Problem: we don’t have customer support, but we have more and more customers. Solution: hire a Head of Customer Support to take care of that so the CEO can focus on something else.

You see the pattern.

And I now see the pattern everywhere: I see it when judging growth of engineers (“what problems can they can take care of?”), I see it with job interviews (“your only job in the job interview is to convince the other side that you can solve their problems for them”), I see it when wondering what I should do next (“they want me to take care of this multi-people, multi-project problem now, so they don’t have to worry about it”).