I'm 10 years into CS career, but rarely code anymore. Is this normal?

No. (Normal yes, OK No)

A longtime ago I had 40 developers under me and frankly hated it. Went and got a contract as an individual contributor, wrote some FOSS found I was happier.

Every few years I have to decide between the no coding daily route and the coding daily route.

It frustrates me that there has to be a choice. Let me explain.

I am (honest) writing a book about software literacy where I conjecture that software is a new form of literacy unlike the other analogies like driving a car is a lifelong skill and importantly will force society into massive meaningful change.

So let's rephrase the question :

"I used to write English everyday, but now I am going to become an executive and will stop writing English and instead set guidelines for other people to write English"

It's not you. It's that we (all) work for software illiterate organisations. Getting promoted should not mean stopping writing code.

It should be part of a natural day to day work. Why is it ok that an executive should spend a day buried in a spreadsheet but not buried in pandas code?

At a certain point the whole organisation should push to the CEOs repo. At that sort of level I can imagine they won't write production code, but they should damn well read it, approve it and write their own for their own (executive) purposes

You won't fix this. But fight back against it. Somewhere there is a project at your company that presents important data in a web form, and maybe has a download in excel button, but has no API, and worse only allows downloads by human SSO not machine tokens.

Every time you can make "programmatic access" a first class citizen. It's a start. Others may think of other ways to start

That sounds normal given your career trajectory and it's good to hear that you enjoy your work.

In order to keep your edge and facilitate the use of your architectural designs I would recommend implementing skeleton, or proof-of-concept, implementations of your designs that your colleagues can use as examples or templates.

I wouldn't worry about being fucked on the LeetCode stuff as your 10 years of employment should move you past that bar.

Furthermore, I've coded for over 15 years, worked with people that have over 30 years experience, and all of us would have a rough time of it since we've been busy doing other stuff.

It is a normal progression. There are many paths, some examples;

Programmer -> Architect

Programmer -> Manager of Programmers

Programmer -> Product Manager

Programmer -> Specialist (sometimes called SME or subject matter expert)

Is it "Okay" is a personal choice. Some people miss programming, some don't.

You mention you worry about "losing your edge." If I understand what you are saying by that it suggests that in your head you are still a programmer so you are thinking that people actively programming are keeping up with the latest frameworks and stuff and you will be less competitive in the job market because you didn't keep up.

That is only a problem if you want to always be a programmer. Most people evolve in their jobs as they find out the things they are either good at or well rewarded for, versus what they thought they were good at. Someone who understands programming but can talk to customers has a different value to a business than someone who can just crank out code. Not that one is better or worse, they are different.

When I manage groups I try to 'stack skills' and get complimentary sets in the people I hire so that the group as a whole is more skilled than any single individual. What that means is that if you demonstrated to me that you could accurately assess vendors "real" value from all of their sales literature then I've got one role for you, if you tell me you can turn anyone's idea into business logic in the code I have a different role for you, if you tell me that if bugs you that all this time is spent building the system that we could save if we just re-organized some of the steps, well I have a different role for you that leverages that too.

Truth be told, "leet programming" is kind of a dead end job. Knowing what to program is a job you can do until you're 90. To make the latter work however you have to have some ability to bring people along (aka "soft" skills).

Staying curious and learning new domains has kept me from becoming 'stale.' But predicting the future is impossible as far as I can tell.

Normal? As far as I can tell, yes. I'm about 3 years into my own career, but as far as I can tell from basically every career conversation I've had, that seems to be the way for larger companies, and seems to be the well-defined path.

As a side note, this appears to be the way for many other technical careers as well. For example, I know a prototyping engineer that bemoans a similar path. The more responsibilities you have, the more you delegate, and it snowballs.

As for "ok", that's entirely up to you. If you enjoy it and find fulfillment, then I think it is. I have a co-worker who's been with the same team for around 10 years, is at a manager level, but is perfectly happy to stay at the individual-contributor role. It's really about where you find the joy.

As for switching to another job, you probably wouldn't go through the LeetCode stuff, if you didn't want to. You'd likely move straight to manager, where your skills are currently. I imagine they'd be smart to not waste your time and just look at your resume.

I’ve been going 16 odd years now and code every day in work. It’s one of the reasons I prefer small teams and startups. There’s more of both strategy and dirty hands than you could ever want. Games is also a domain I believe you need to keep your hand in to stay current.

I think it's a result of how inexperienced the majority of devs are. At 10 years in, you're more effective doing architecture and dealing with high-level stuff to set up newer developers for success, but if everyone you worked with had 10+ years of experience they couldn't all be architects! :)

Well.. It depends... If development is what you want to do, then it's not OK. In terms of losing your edge, I agree with you completely and I'm in a similar situation at the moment(though for different reasons): the company I work for is infuriatingly conservative. The newest thing in use is the oldest which is still maintained. Any technology invented after 2011-2 is considered witchcraft. And even suggesting something which would clearly make things better for everyone, results in a long convoluted answer as to why not(without an actual answer, just a way to brush it off) or "open a jira ticket in the suggestions project" if someone is busy. Basically this is just a formal way to tell someone to leave a comment in the guest book. And the "suggestions project" has tickets dating back to 2014, all of them completely ignored. While I appreciate that there are no pointless hour-long meetings discussing made-up acronyms and whatnot, the fact that I feel like living in 2010 is not just frustrating, I'm absolutely furious. So it's easy to see why I'm looking elsewhere, even if I haven't spent a whole lot of time here. But in my experience if you want to be a developer and live on the edge, steer clear of the "architect" types of roles and stick to strictly "developer" roles.

The bigger the word in front of Engineer, the less I have coded.

This is totally normal. If you like doing that keep hammering away... I 100% believe system thinking is more valuable than leetcode when I interview Senior or higher.

it's not at all unusual for you to do less software development the higher up you go on the ladder, especially if you have direct reports. Strategy, architecture, planning, removing blocks for others, these are all valuable parts of software engineering work at a large firm. Big organizations create a kind of work all of their own that has to do just with managing the workings of the organization itself and that work can't be avoided.

About this being OK - just saw Rich Hickey’s Hammock-driven development talk and can’t recommend it enough.

Your value comes from solving problems, not from typing code.

With time and experience you learn to solve the right problems, and sometimes throw away non-problems, saving massive amounts of money and resources.

It's normal but not inevitable or irreversible.

Your reaction will likely be, gut level, either "I prefer this and choose to continue", or "this isn't agreeing with me I will actively move back to hands on".

If truly the former, ignore the nagging doubts and carry on it sounds like you're on the right path for you!

One warning: 10 years into a 40 year career, going hands-off your tech skills will at some point become obsolete. That can lead you into making poor decisions later, potentially, through sheer lack of practical understanding, and with no realistic way back.

Even saying that though I would find it hard to recommend going back to coding despite preferring what you're actually doing, life's too short to settle for 2nd best.

Tough choices!

It seems to me that if you are a developer that is good with people (and especially if good at coding) that management duties will eventually follow. What I found is that I have to keep pushing my career back to coding daily. The same is true for architectural work.

Also, for me at least, I try to code at home to keep my skills up to date. So if it happens to be the case that I am not coding on a particular assignment, that I make sure to keep the skills sharp by coding on side projects at home.

Well, aside from a couple of years as a group leader, I've coded my ass off for my entire 30+ year career. Granted, it's in a specialized, scientific field but it's what I feel I am good at and what I chose to do. And was fortunately able to do it.

During the group leader time, I realized that the books were right - I had no time to code for anything more than the occasional bug fix or code review. My job was to make it easier for my people to code (ie, do THEIR job). I tried to handle all of the meetings I could so they did not have to break concentration and go. I participated in the market and bug reviews, ... Necessary job, but it wasn't one I preferred and have not gone back into this kind of work.

Do I miss being aware of everything about a product and its schedule, yeah. It was nice to be in the know even if I was responsible for it. Now, I have to trust my coworkers to do their work as they trust me to do mine.

One's "edge" is whatever is required to get good, stable, maintainable code out the door that satisfies users. Whether this is the code itself, the GUI, the planning... Whatever is required to get things done. With luck, you can choose your role to suit your interests.

I have a friend who about 10 years in moved to a director/manager role. Absolutely hated it. Both not coding and having to deal with people's BS. Eventually he was able to put up a big enough fuss that they moved him back to a sole coder job. I, on the other hand, am 20 years in and have refused every effort to promote me to more of an architect/manager role. I'm still coding every day and loving it.

Normal? Yes. Ok? That's kinda up to you.

Being able to design a solution, get buy in from leadership, and most importantly execute a solution at the strategy level is a valuable skill. I think behavioral interviewing, where candidates are asked to describe an experience/situation/project similar to what they would end up doing in the role they are interviewing for, is a better assessment for those kind of skills than HackerRank.

That doesn't mean you won't find companies using LeetCode/HackerRank-type coding tests even at higher levels, but like you mention you could always study for that. I've had friends do that successfully.

I've gone engineer -> tech lead -> engineer -> manager / built a team -> program manager -> director / built a team -> project manager -> engineer. It doesn't take as long as you'd think to get back into the flow of coding full time. Also, the rate of technical change keeps increasing anyway, so everybody's kinda in the same boat from the perspective of keeping up to speed technically.

10 years in here. Found myself in similar roles over the past 5 years that reduced my coding time and skill.

It has hurt me. I'm only a midlevel though, so I can't jump to an architect or tech lead role (well, I worked as a tech lead for a year but didn't get promoted into it officially). If you're a senior you could make that jump. I'm stuck in between and it sucks.

I think an architect is a technical , hands-on job, albeit a role that bridges both engineering and strategy/management. Architects should spend some time coding , maybe 25% of their time. I feel without doing some coding, you're bound to : 1) lose the view from the trenches 2) liable to slip into the management-land where every complexity is under-estimated.

Especially as you need to choose between vendors, APIs, and set a direction for the larger team or org, your decisions have impact. Its important for you to be in touch with hands-on engineering work, maybe at least POC work.

I work at a large healthcare IT, where the architect was actually only making diagrams, and getting needed approvals from committees/gatekeepers, as its a pretty security-focused (being healthcare) environment. Basically he's 'the committee guy' or the 'pictures' guy drawing a big fat salary, but with no technical contributions, esp since his extensive-Java knowledge is not applicable in a Python-shop.

Code is just a tool to shape your idea. I have 16 yr into CS career and I still code everyday (I can code in many languages based on task requirement). There are couple of companies where the work is boring and you can get away by not coding. But if you want to do innovation and build something new, you need to code.

Yes, I would say this is normal and OK as you gain more expertise in your craft.

Anecdotally, I have moved twice from higher engineering management roles (VP / Director) to Senior / Principal level IC roles and I am a bit older than you. It does take a bit of work to find the right IC position to shift into at the right company when you are ~recovering~ moving from management/architect roles.

I feel it is very helpful to be up front right away when you interview and express that you want to be more in the trenches with hands on coding. There are a lot of companies that want IC developers to have architect-like "spacial awareness" experience on their engineering teams. It's a valuable skill. Lean into it.

I'm a staff engineer about five years into my software engineering career. I have long periods of time where I write little code.

I'm on a small, special-purpose team and we spend a significant amount of our time investigating what we're going to work on next. From there, we put together docs and justifications that we take to the team that owns that service so we can achieve buy-in from them. We frequently run projects in parallel, so we can end up being the point-person for one project while assisting on others.

I'd say I spend 30-40% of my time actually writing code, though this is extremely bursty depending on the project. The other 60-70% is spent writing docs, doing research, or achieving cross-team buy-in.

Yes it's normal.. no it is not "ok" in my opinion. I am in the same situation except I find planning at a higher level more boring.

Yes it requires the architect to know all the different parts and how to move them together efficiently to deliver projects but.. it's not creative. There's no immediate feedback. There's little sense of ownership. It doesn't give me any job satisfaction. Sometimes it is more about how things appear than how it actually works. It's not why I got into this career.

For me, I feel it will also make moving jobs more difficult. I see some of my colleagues and they have little to no programming skills anymore - and they don't want that skillset either.

Yes it is normal and it is okay. It is just a reflection of the fact that the vast majority of software projects out there aren't writing groundbreaking code or solving impossible new problems. The complexity instead lies in coordination, decision making, translating requirements, setting expectations, adapting to unexpected changes..

As a senior engineer you are more valuable doing all this than hammering out code. If you enjoy it and are doing real work/adding real value to the company then this is a good career path to continue on. You are ultimately paid for the problems you solve, not the number of lines of code you write.

You can worry about Leetcode if/when you decide to switch jobs.

I think, this is natural. Ext step of engineering.

I think you transform the way you code (actually writing) to the way you think strategically and make decision. So whatever you write as coder will be seen in design and decision making process.

This is pretty much where I'm at 10 years in.

IMO, this is where the "10x" software developer is more practical than myth. The "architect" discussion you're having likely have significant downstream impacts on the team. You don't need to know all of the details (e.g. the actual code) because you know someone else can figure that out.

You understand how the parts fit together, what will be painful about them, and what the team needs to watch out for. You can help the team make decisions in a way that reduce their overhead and get them towards success more quickly.

Being an architect and being a developer that codes are two different jobs, and this should be more widely known.

Your skills are still valuable, but the problem is that many companies don't separate architects from developers when hiring, and that's why they subject their potential architect hires to the same LeetCode coding stuff. So when you switch jobs, you might have fewer companies to choose from, or fail a few more interviews from companies that insist their architects can get down to the nitty-gritty details of coding. It's a choice you'll have to make.

To quote a tweet by RandallKanna: “I will never understand why tech companies optimize interviews for a college grad to do better than someone with ten years of experience.”

> Is this normal?

Well, it's at least typical - it happens to quite a few people at about that time in their career.

> And further -- is this "OK"?

> I enjoy my work; I especially enjoy being involved in the higher-level issues and strategy. I enjoy working with other decision makers, and might even enjoy it more than the hands-on coding work I used to do.

Then, yes, it's OK. It's good, even. There's nothing wrong with doing work that you enjoy doing.

There are rarely unicorns who can do architecture/strategy and also code daily at the level and volume that their years of experience imply. They're out there, but they're rare.

You've done what the rest of us do, which is specialize. If there comes a point where you need to LeetCode into your next role, I am sure you can study for a short time and nail it. Your broad experience is an asset on that front.

Normal, yes. Okay, maybe. You may find companies less interested in hiring you if you haven't written code in a decade.

You are describing a valid career path, it is okay to be part of a software development process if you don‘t code.

But please leave technical decisions (database design, microservices yes/no, …) to architects who still code. And only focus on functional architecture (should requirement X be handled by component Y or Z)

It is normal. However, in my view maintaining coding skills helps with being able to switch employers, if needed. Which might come up unexpectedly.

And as it is easier to keep a skill than to relearn it from far behind I would spend 1-2 hours a week on true, raw coding. Leetcode, hobby project, whatever. My 2c.

Is it OK? Of course, as long as you enjoy your job it is great. For interviews you can just brush up on leetcode..

I try to sharpen the knife with side projects that keep my interests in programming high, but at work it is just a minority of my time.

I agree that you should consider whether it’s good for your life / what you want or not. All options are available. (I’m also 10 years in)

This highlights the cost and inefficiency of enterprise Java

somebody needs to tell the young ones what needs doing and it's you. this is normal.