I have been working at a large bank for a few years. Although some coding is needed, the bulk majority of time is spent on server config changes, releasing code to production, asking other people for approvals, auth roles, and of course tons of meetings with the end user to find out what they need.
I guess when I was a junior engineer, I would spend more time looking at code, though I used to work for small companies. So it is hard for me to judge if the extra time spent coding, was because of me being a junior or because it was a small company.
The kicker, is when we interview devs, most of the interview is just about coding. Very little of it is about the stuff I listed…
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.
Same boat. Nuh uh, you’re not promoting me. I don’t want to have to deal with offshore support, meeting 6 out of 8 hours, making sure Jira board is up to PM’s standards and only reading code when any of the devs have an issue they cannot solve by themselves or something breaks. I tried management career path and hated it with all my heart, quit when they wanted to promote me higher. Let me do what I enjoy, I’ll deliver.
Bonus points - developers make more than managers up to 2 or 3 levels up where I live, so it doesn’t even calculate.
That’s interesting, where do you live?
Poland.
A lot of development and other IT related jobs get outsourced, so experienced devs are in very high demand. We usually work in a B2B arrangement, a developer starts their own company (sole trader I think it’s called in the US) and invoices an agency that deals with corporate customers.
Salaries are around 3-4x average national salary, with smaller taxes than on a work contract and less safety (which is not a problem due to high demand). Locally, managers do not usually play any role, I report directly to the customer’s managers, usually far away from Poland. If I were to sign a contract with the customer, that’s no longer B2B usually, the salary is less and taxes are higher.
Not OP but I’m in France and it seems to happen everywhere. I absolutely refuse to become a manager/tech-lead/whatever because they always get stuck in the same kind of job forever. I like C++ but I don’t want to write C++ for the rest of my life, I want to study all the new things. And if you become a tech-lead, people lie to you by saying you will make decisions for the future. It’s false and you have almost no power to change anything.
This is exactly what happened to me. I was a team lead at my old job and I interviewed as a senior dev but got offered a standard dev position. In the end they offered me the same money as what I was making as a team lead so I took it and have never looked back! The reduced pressure and better work-life balance are so good. I now earn much more than I did at my old gig so 🤷♂️
A friend of mine been there, and he done exactly that.
I’m sure in a few years from now nobody will code anymore and you will just tell the AI what you want to see implemented.
Same as nobody writes actual machine code anymore and everyone only uses higher languages.
Higher-level languages compile (pretty much) reproduceably into machine code, so the same C code would always produce the same executable as long as the same compiler version is used.
Current AI chatbots will produce completely different results if given the same prompt twice. In its current form it can’t be used in a reliable toolchain for anything.
Big Part of my daily business is explaining people what they should code… People aren’t reliable as well.
You still have to understand the code as a senior, you don’t want to merge code, where you don’t know what it’s doing (AI extinction anyone, haha?). And I actually doubt that nobody will code anymore in a few years, as some stuff requires quite some creativity that is just nowhere close with LLMs (even with GPT4). I’ll admit though that probably 90+% will be able to be written by AI (and is in some way today already, if it’s relatively repetitive code). So yeah the new main dev-role will likely be “prompt-engineer”. But it’ll be interesting, the fast progress with AI never stops to surprise. And GPT4 is definitely able to think slightly abstract (and with correction writes quite good code). Deepmind also just recently released alpha-dev, which improved the state of the art in sorting…
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).
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.
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.
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.
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.
“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
This is pretty much what my day looks like (2 years since being promoted to tech lead).
To be fair it’s not a good comparison to compare an IC role against a management role for time breakdown.
Eh, I’m not really comparing, just offering what my time looks like since I’m still a “developer” of sorts. I’m still heavily involved with code, and I do end up making commits that ultimately deploy to production.
(I’m sure someone out there in an IC role would love to compare, especially if they’re considering taking a more managerial role.)
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).
So, you don’t actually do real work and have to live with the technologies that are chosen on your recommendation? Sound like a sweet deal. The senior engineers that have to actually make software that is sold and clean up the mess will hate your guts though.
I started out where everyone else did and worked my way up so I’ve “been in the trenches”. After doing this for 20 years and shipping multiple consumer and internal products I’ve seen it all and know what can make or break a project and what works and doesn’t when introducing or using a new technology to a dev group. Also, I definitely don’t throw it over the fence, it’s a team effort and we all agree on what sounds like the best approach. Along with code reviews, part of the coding I discussed is sitting down and creating a skeleton of tests and an initial architecture that others can build off of and give me feedback on. If someone is having trouble implementing something I sit down with them and work through it. It’s also about trust, people also trust me and know that in general I know what I’m talking about. The thing is most people would read my resume (or even this quick summary) and say I’d make a great development manager. But the problem with being pigeon holed into being a manager just because your a great dev is that it doesn’t reflect what developers are good at, making software. More and more companies are realizing this when they shove their best dev engineers into the position of a manger and it crushes their souls, and makes them leave. So they are creating these principal or staff positions which at most companies are laterally equivalent to a director of software engineering without the people/staff managment. There’s a great podcast episode on this by Stephen Dubner who wrote the book Freakonomics https://freakonomics.com/podcast/why-are-there-so-many-bad-bosses/
The crucial point to me, which I could not read out of your first post, nor will I implicitly assume it as a given, is that there still is a feedback loop from product development to the staff/principal level.
I’ve been burned by a code base that was created by a principal engineer, who tossed it over for maintenance and moved on to greener pastures (still in the company though). It is more to blame on the organization, than on the engineer, but still such an experience leaves a slightly bitter taste.
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.
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 ^^
A lot of my time is spent in meetings now ever since d I was moved to senior dev. So not very often :(
