I think the other big factor that hasn’t been called out yet, is that a senior developer is more likely to be able to change the requirements entirely to write less code.

As I’ve become more senior, I’ve found ways to push back on product requirements that add little value for the users, but tons of complexity in the code. If I don’t follow the requirements exactly, I can usually write ~10% of the code. But you need to learn how to do that with lots of experience.

It takes the same amount of time, because I need to dive in deeper to understand the problem and how it interacts with my features, lots of planning and meetings to change the scope, but the final output might only be 5-10% as much code if we can reuse things that already exist in the codebase.

—

For example, product team wanted something to be bold that we had set up to be within dynamic plaintext. It would’ve taken a rewrite of that entire UI component to be able to make some bits of text dynamically bold. But I was able to push back and say “what if we just rearrange it slightly so that the bold is unnecessary”, and the designers+business were ok with that too!

If I hadn’t pushed back, my more junior teammate would’ve written 2k+ lines of code to support that requirement. But instead it was probably like 10 lines to support the alternative formatting. That 10 lines took lots of time to understand the requirements, but was much better for code cleanliness and consistency in the end.

Agreed that the more senior you are the less time percent-wise you will allocate to just coding but for strong developers this doesn’t mean your output drops compared to juniors, it drops compared to what you could do if you were only heads down coding. It’s easier in many ways to have higher output as you become more senior if you stay close to the code, know more about the code base, and can be much faster, all the best devs I’ve loved working with are like this. Many of the less productive senior folks that drop in their output and don’t code much (i.e. modify < 100 loc in a month as a normal occurrence) become architecture astronauts which is not imho what a senior dev should be doing as they will lose touch and eventually their guidance is less useful on the complex matters where they are most needed which in turn means their team and company impact is not what it should be.

I've worked with a ton of architecture astronauts, and while a bunch of them are just shit coders, you can definitely create new ones out of otherwise good coders with the wrong environment.

Those seniors that maintain their output are only able to do that as long as they maintain their knowledge of the codebase. As soon as you lose control your output goes from 10x to 0.1x in the blink of an eye. At that point your options are to look like a fucking idiot because your juniors are out-doing you, or to optimise for blowing smoke up the manager's ass. Easiest way to do that is large sweeping rubbish architectural changes that look good on paper.

Some people will take a stand, but most just play the cards they're dealt. Every great engineer I know has had both 0.1x projects and 20-50x projects. Knowing why that's the case is more important for a senior/lead dev than coding ability IMO. Get the best out of others and all that...