Should Staff+ Engineers Be Writing Code?
I was at a conference recently where this exact question came up. As might be expected, there was not a consensus. First of all, there are two impediments to answering this question cleanly. The first is that titles across companies do not mean the same thing (a quick look at www.levels.fyi should convince you of that if you aren’t already). The second challenge is that the exact job description as you move up the senior IC (individual contributor) ladder becomes more and more vague. It largely becomes a choose your own adventure. Because of that, there are many flavors of staff or principal engineer that have very different expectations.
Okay, so now that I’ve said there are a billion different types of senior ICs, what are the actual commonalities? At a high level, the higher you move on the IC track, the more impact you should be having. Your exact impact can vary a lot, but really, the main justification for paying you more is that you’re providing much more impact and value. Your impact may come in the form of mentoring junior engineers, seeing and fixing the problems taking 15 minutes of every engineer’s time every day, or pointing out problems before they’re implemented, preventing rework. Given this, it is extremely unlikely that a senior IC will be spending all of their time coding. I have yet to see someone so good at coding that they are three or more times faster at implementing things than anyone else.
The real question then becomes should we spend any time coding, and if so, how much? If you’re looking purely at trying to have the most impact, the answer on the surface seems to point to not coding at all. And yet there are good arguments for at least keeping a foot in the door.
Why Code?
Love of Coding: First of all, many of us stayed on the IC track because we liked coding. While a job, even a senior one, is not only about doing what you like, it is still important that you stay happy and engaged in your role. If spending a day a week coding keeps you engaged and excited to come to work, you will likely do better in the rest of your job.
Ability to Spot Problems: One of the possible senior IC responsibilities includes finding and solving department or even engineering-wide problems. While some problems can be found by talking to people, engineers often don’t mention many of them. You will discover more problems and will better understand those problems if you’re working in the code. On top of that, more junior engineers may not have the experience to realize that there’s a better way to do things and therefore may not even identify something as a problem. All of that is to say that working in the code will give you better context on what problems exist in the code base and what is slowing down developers.
Architectural Understanding: Another common responsibility includes reviewing and coaching architecture and design. Similar to the previous point, it’s important to understand what already exists to give good advice on architecture and design. While it’s definitely possible that this could be obtained either from documentation or past experience, I find that I learn best by doing. For me, I will gain by far the most and best context if I’m in the code myself. It’s worth noting that I don’t have time for it to be feasible to deeply understand every piece of our code, but having context on even a few key areas is really helpful.
Building Credibility: Finally, as a senior IC, a large part of your job is to convince people to do things. In some cases, you have positional authority, but in many cases, you don’t. Even in the cases where you have actual authority, it can be easy for engineers to start resenting the person who always swoops in and tells them what they’re doing wrong (I’ve felt that way). There are obviously other ways to mitigate this problem too, but it’s easier for people to take you seriously if they know you’re working in the code with them. It’s also the only way to lead by example. They can see what it means to make incremental improvements; they can see what it means to leave code better than they found it.
Why Not Code?
Now that we talked about a few reasons for senior ICs to write code, I want to talk about a few of the arguments on the other side of the fence. The first one, we already touched on, but I want to reiterate.
Low Leverage: Writing code is rarely the highest leverage thing you can spend your time on. Most of the code I write today could be written by someone much more junior.
Slower Than Others: Pretty much universally, as a senior IC, you have many responsibilities that you’re trying to balance. With the higher level of context switching, it’s almost guaranteed that you’ll take much longer than someone with fewer responsibilities (and will take time to context switch back out of coding as well). You will also take more time rebasing and merging your code since it’s likely that the landscape changed around you as you were trying to implement your bug or feature.
Blocking Others: It can be really tempting to pick up the biggest, meatiest problems to solve with code. After all, I love solving really hard problems, especially with code. Additionally, I know that I will have good solutions and will make the code better in the process. The problem is that with so many other responsibilities slowing me down, it often becomes the case that if I take on these tasks, I will block at least some work on the project. At best, it slows down the project, and at worst, a team member is much less productive than they could be. If I’m not careful, I may even prevent others from learning and set myself up to be a single point of failure.
So How Much Coding Should a Staff+ IC Actually Be Doing?
I also posited this question to several other Staff, Senior Staff, and Principal engineers. For all of us, we felt that we were best at our jobs if we spent an average of 1–2 days a week coding. Some weeks that’s more, and some weeks that’s less, depending on what else is going on. For example, we all agreed that it’s hard to get much else done when we’re planning the engineering roadmap for the next quarter or year.
Ultimately, however, I can’t answer the question for you. The answer comes from combining everything we’ve already discussed and the mix of responsibilities expected of your role at your company. You may also consider the responsibilities that you want to have if that’s different. There are also other factors, such as the size of your company. You’re going to be coding more at a 5-person startup than at a company with 10,000 engineers.
Ultimately, the things to ask are:
1. What do you want to do?
2. What is your job description? Is coding expected? If not, does coding help you execute on things that are in your job description?
3. What are your career goals? Does coding help you get there?
4. Are you providing more value to the company by continuing to code? Are you doing the optimal amount of coding? Should you be doing more? Or less?
