It can be hard to decide how much an engineer in a Staff+ role should be coding.
As software engineers move up the IC track, roles and responsibilities become increasingly varied. While sites like staffeng.com, do a great job of outlining various archetypes, the reality is that the exact job description is usually negotiable and at least partially defined by the engineers themselves.
Because of this, while organization rubrics and managers may provide some guidelines, it’s still up to us to decide how much coding we should be doing each day. It’s also the case that we’re trusted and expected to have the highest possible impact that we can. So where does coding fit into that high impact?
After careful consideration, I concluded that spending about 20% of my time coding was the right balance for me. I also talked to a handful of other people in various jobs, all at the Staff+ level, and everyone agreed that 20-40% (1-2 days per week) is ideal. Some weeks they will do more, and some weeks less, depending on what else is going on. For example, we all agreed that it’s hard to get any coding done when we’re planning the engineering roadmap for the next quarter or year.
When making the decision for yourself, the answer comes from a mix of:
- Responsibilities expected of your role at your company
- The responsibilities you want, if that’s different
- 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)
There are also many other reasons, which I discuss below, why you might code, or not code, that should be considered and applied to your situation.
Why code?
We love coding!
First of all, many of us stayed on the IC track because we like or even love 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’ll likely be better at the rest of your job as well.
We want to hone our 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, often engineers won’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 lack the experience to realize there’s a better way to do things, and they might not even identify something as a problem. Working in the code will give you better context on what problems exist in the code base and what is slowing down developers.
I’ve also found that what can look fine in a code review can instantly reveal problems when you try to do it. My team recently had a set of tasks that needed to be done for a bunch of endpoints. As I worked on one of these, I realized that there was a ton of copy/paste going on, which I failed to catch in code reviews up to that point.
We want to gain 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. While it’s possible to gain a good understanding from documentation, I find that I learn best by doing. 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 to deeply understand every piece of our code, but having context on a few key areas is helpful.
We need to write POCs and solve tricky problems
Sometimes as a part of determining direction, we find that we need to gather more information or write a POC (proof of concept) to make a decision. In other cases, we are solving a very hard problem in a very critical part of our system. In both of these cases, the outcome can have a disproportionate impact, so working in the code can be especially important to ensure a good outcome.
We want to build credibility
Finally, as a senior IC, a large part of our job is convincing 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 or even ignoring the person who always swoops in and tells them what they’re doing wrong (I know I’ve felt that way). There are other ways to mitigate this problem, 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 to write code, I want to talk about a few of the arguments on the other side of the fence.
Coding is 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. Additionally, as a lot of the folks I’ve talked to have been quick to point out, by doing code reviews instead of writing the code, we can get a lot of the context and spot many of the problems in much less time.
We’re 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.
We’re blocking others
It can be 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’ll 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.
We can give opportunities to others
Part of the job for many senior ICs is to help grow the engineers around us. While this can be done to some extent through leading by example, in many cases, it’s far more effective to do so by stretching those around us. I can more effectively help someone learn and grow if I give them a difficult task and coach them through the design or give them pointers in code reviews than I could by writing the code myself.
Reflections
While there isn’t a simple answer to how much you should be coding, a good starting point is in the 20-40% range. From there, you should consider what your goals and expectations are for your role and how you can best achieve those; it may make sense to adjust that number up or down. For your particular situation, how can you have the most impact?
