Experienced Devs

Pretty common everywhere. https://staffeng.com/guides/staff-archetypes/

The better programmer you are, the more likely you get promoted in hopes of making the whole team good like you, the less time you spend doing what you were promoted for.

Senior backend developer here . I have been refusing positions as tech or team lead for exactly this reason. All my colleagues that ended up in those positions basically stopped having any time to code. Some of them left to go back to coding in another company as they were burning out from all the meetings and admin stuff.

Most of my day as a Senior is wading through red tape and piecing together out of date internal documentation so the rest of my team doesn't have to deal with it. Maybe some coding, if I'm lucky these days.

This kind of thing is common in many jobs — as you become more experienced, you take on more management responsibilities. It’s inevitable but not always ideal.

The alternative is that you get managed by people with no first-hand experience of actually doing the job, but it can also mean that people get promoted into management roles without necessarily having management qualities (which can be the worst of both worlds — you lose a good coder and gain a bad manager).

Seniority typically means the scope of your role increases - you interact with other teams more, you spend time on high-level design, etc.

From what you describe, it sounds like you're doing that.

If you miss coding, you can assign yourself a few small bugs/features. That keeps you familiar with the codebase. It's probably a good idea to choose stuff off the critical path, since the meetings are what you're actually paid to do at this point.

I'm a principal engineer now, and I write the best code of my life today, and I also spend the least amount of time doing it.

I'm in network automation, so I spend a lot of time working with operators and specing change requests. I template what they do today to prevent errors, I then simplify those templates, expand them to be done in better ways, and write tools to automate the busy work.

Once the operators are happy running the tools instead of operating, they get hosted as a service, that schedulers and other tasks can call to remove the operator entirely where possible.

With our reduced operation time, we then scale up until we hit the operational limit again, and repeat.

As a lead I could stop coding. But I choose to keep time to code every week. I believe this is very important to keep in touch with the reality my reports are facing.

So this is possible to still code but this is not natural. Sometimes I simply cannot have the time to touch any code for a few weeks if I do not take care about it.

"Managing engineer," here. 4-5 developers of various skill levels report to me at any given time.

My time as a whole is roughly spent like this:

• 30% paired programming (assisting developers, helping them troubleshoot, static code analysis looking for a bug they can't find, diagramming a project for them to actually implement)
• 30% administrative (management meetings, performance feedback meetings with my direct reports, weekly one-on-one meetings with my direct reports, approving PTO, etc)
• 10% personal assignments (some sort of debugging/trouble shooting that requires my experience, or maybe putting presentations together to show off new technologies or some projects that we're working on)
• 10% pull request review, providing feedback
• 20% meeting with business stakeholders, gathering requirements, providing estimates, creating agile stories, breaking agile stories into tasks, etc

I am constantly fighting for more time coding. If you were to look at my calendar, there's only ~5 hours per week of open time. My customers are our developers, however, so for the most part I am at least in meetings about code and SDLC rather than random feature refinements and such.

Yes, tons. But it depends on the team and the software. If I'm on a small and inexperienced team for example I'm going to be doing a lot of the work, if I'm on a small but competent team then I may be doing a lot more design & abstraction then the actual work.

Right now as a tech lead I would say ~40% of my time is actual programming.

The position to try to achieve these days is of principal or staff engineer. In this role I get to code all day (mostly exploring new and upcoming technologies that might benefit the company) AND lend my advice for architectural solutions to various groups. In my opinion it's the best of both worlds, with out having to be pushed into a management or lead position (which always "leads" to more project management than software engineering).

It’s the same for me. I’m a dev lead and most of my time is spent in meetings, reviewing code and coaching. I’ve learned to adapt. I still get to write code on occasion and I love that.

Very typical to move in to a position where you are designing the code more than writing it. Junior devs probably can't architect a system as well and especially if you already know the system well you are in a better position to know the best design. But with that comes writing, documenting, organising a team, planning work, estimating, interacting with project management and customers, going through the SDLC hoops. The junior devs get given a spec / design and "just have to type out the code", with the seniors there to support, guide / mentor. This leaves very little room to code yourself, and the bits you do do might be the more complicated bits, in which case you should think about bringing along a junior for the ride and teach them. Or they might be the simple tools and libraries that you can do in a couple of hours because that's all the time you can find to do it in.

My employer (< 20 total employees, 3 total devs) was recently acquired by a much larger company. Our lead dev was made a manager and no longer has time to code and I was made a team lead and now half my time is spent in meetings, code review, or deployments. I am finding that with limited time for coding I am writing more concise, thoughtful code.

The hardest part of the change was adjusting my expectations for the product. We can no longer deliver what we want at the pace we want as that is now dictated by someone.

A lot of my time is spent in meetings now ever since d I was moved to senior dev. So not very often :(

I totally feel you. I've been in a position where the only way I could get any coding done was by working overtime.

I think like others I've found that it's more a function of how long I've been on the same team, not how senior I am.

When I switch companies or switch teams within the same company, it's a great opportunity to get a "reset". I'm no longer in charge of anything, I'm no longer the go-to person for important knowledge. I get to spend a lot more time coding and problem-solving. After a few years it gets harder and harder.

I think the trick is to find the right balance. After you've been on a team for a few years is often the best time to have the biggest impact and get a promotion or bonus. But it also means your day becomes the most consumed with meetings and you spend less time building, so eventually you might want to shift to a new team to get a fresh start.

The only part of your job I find weird is "delivering to production". How is it not the Devs responsability?

Otherwise I would say it is pretty common. Used to be lead backend in my last job and it was a long holiday for my IDE.

The only code I was seeing was on reviews or on my colleagues screen ^^

I feel you. I’m a Senior Backend Engineer, and the more experienced I get, the less I code. And the meetings… so many meetings!

totally about company. I used to work on small company (<40 dev), I was spending more than 70% coding.

I switched to bank, way more developer (>500), if I spend 30% coding I am very happy.

I think in the last 8 weeks, I've written like 10 of code