Ask HN: I'm 10 years into CS career, but rarely code anymore. Is this normal? | Hacker News Reader

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

76 pointsmaxdoop73 comments

I graduated with CS degree in 2012. Worked as intern doing web dev, then moved to enterprise Java shop at large corp. Then, spent 4 years at consulting firm coding in variety of technologies.

I now work at another large enterprise, and find myself being more "architect" than "developer". I spend time discussing vendors, high-level design, architectural decisions between domains, and just more overall "steering" strategy than coding.

Is this normal? And further -- is this "OK"?

Some more context:

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.

However, I worry that I'm losing my edge. If I want to job switch, I'd be fucked on the LeetCode stuff. I could study it no problem, but I'm curious how much pure coding skills impact my career trajectory. As it stands, I'm not entirely sure where I'd move next but I want to ensure my skills are valuable (e.g. I don't want to become stale!)

View on HN

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

I disagree here as someone who writes code for a living. In my experience, managers who write code often do so at the expense of something that's a more important part of their job that they don't want to be doing.

Many managers are promoted engineers who feel more comfortable with code than people management. So when they don't want to hold 1:1s, don't want to deal with an interpersonal problem on the team, don't feel comfortable escalating an issue to management, etc... they instead pick up tickets and start writing code as a way to kind of procrastinate. This is bad because the organizational structure is such that the manager is often much better equipped to deal with such issues than the dev team, so they can go unaddressed.

I agree that a "manager" doing the work of one of their "employees" is clearly wrong.

What I am trying (badly) to convey is that we should build software-driven organisations - where the processes and policies, the back-office if you like, is software driven and so if you "the executive" want to chnage the company you do it through explicitly changing the code.

That's a cool idea but I think something important is lost without that human "fudge factor" so to speak. I do a lot of things for my team that maybe aren't explicated in policy or would be very difficult to legislate through code related to morale and fending off burnout. Humans need wiggle room, for lack of a better word. Robots don't make all things better.

We have the same idea in human society - we have very explicit criminal laws abs the jury system to handle the fudge factor.

The difference here is openness.

What your argument means to me is a need for democracy and openness in companies.

I agree. Managers (especially higher they go) should get out of production code. That said, they should be technically very skilled to be able to make tough calls, people and technical.

Companies should have two ladders. IC ladder and management ladder. Where companies fail is that they make the IC ladder less about actual work and more about documents, RFCs and 1-pagers and other nonsense.

They start measuring productivity by these docs instead of actually building something, thus setting perverse incentives for a promotion.

Docs, RFCs, designs are all means to an end, not an end unto itself.

Imagine a bad manager spending 30% of the time coding. Now imagine the same manager giving up coding, investing the 30% in making more bad decisions. And don't expect things going better but expect them getting worse due to total lack of grounding in facts and loosing his technical network to back him up.

There are many ways to be a bad manager, certainly. One way is to make terrible calls that misdirect the team. Another way is to neglect your responsibilities. If the options are "constantly interfering and screwing things up" or "checking out and writing code" I agree that the latter is preferable, but those aren't the only options.

If someone is trying to improve their performance as a manager it needs to start with real assessment of the core functions of the job, and those don't include coding. Too often people tell themselves they need to make time to "stay sharp" with coding when what they really mean is "I don't know how to tell Karl to stop micromanaging Hayden, and I don't know how to get the Widget Access team to stop ignoring our bugs, but I do know how to write a rate-limiter". Then it becomes "oops, this rate limiter is pretty involved, so I didn't have time to talk to the WA team. I guess I'll get to that later".

If the company needs a rate limiter and you don't have the budget to hire someone to create it, then maybe creating it is the sort of go-getting action we want.

And if we think the manager should go fight and persuade the organisation it needs a rate limiter then, yes. But they will need to write code to show the slowdown in latency, calculate the cost in servers if we don't have this etc etc.

And frankly that sounds more valuable to the bottom line than whether Mary is being micromanaged.

There are always always trade offs. "people management" is rarely about inter-personal issues arising to the level of HR like action. It is for more often enforcing standards on the job. Oh like linting.

Less and less human stuff cannot be improved with coding and almost always the solution built in is insufficient, and customising it at enterprise level slow and costly.

I agree don't do the job you left behind, but that's is not the same as stop coding. The software literate company will need most software not less.

> Less and less human stuff cannot be improved with coding

I couldn't disagree more with this perspective. Interpersonal relations are not reducible to technical problems, they require getting buy in from other people.

> And frankly that sounds more valuable to the bottom line than whether Mary is being micromanaged.

What if Mary (or in my example Hayden) leaves the company because they're tired of being micromanaged? Engineers are costly to replace which is why we have people to keep track of the human side of things.

It seems like you're assuming a lot of what those managers want or don't want. Or is there some data behind this?

I don't need "data" to show that when someone does X which isn't part of their job in preference to fixing longstanding problem Y which they're directly responsible for, they must prefer working on X to Y. We all have blind spots and areas where we prefer to focus that might not align with what's most important. This is something you can see at every level and my comment is based on experiences in my own career.

So, there are roughly four executive functions

- model - monitor - mentor - resource allocation

Using Software to "run" the company will encourage openness, reusability, and robust discussion. This may not be what executives want.

And yes Linus Torvalds will inevitably come up here. And I think he is an excellent model (excluding the stuff he resigned / apologised for). He does / did not write code that goes in the kernel, but will write things that solve his executive needs (everything from mailing him when his local build has finished to, you know, git). These things will mostly be open, and beneficial to the "organisation".

No his job is not to write kernel code. But that's not to say he writes no code, nor is that code not useful in building the whole organisation around the "factory floor" job.

Anyway, the model / Monitor / Mentor thing - yes of course software will help building such things. And yes of course there is proprietary code out there (SAP etc) to kinda sorta do that but mostly it all devolves to executives downloading everything to excel and writing their adhoc queries in excel to answer the problems they face today.

There is zero point hoping SAP will write a custom what if filter for Company X's problems with holding US Sales in Dollars or Yen.

And there is a big upside in thinking if they were coders, and did write that query and made it open inside the company it would be reviewed, challenged and improved. And maybe even open up debate in the company but that's politics ...

I think your issues are orthogonal. The issue is certainly not specific to computer science. Heck, there's even a small monolouge about it from William Shatner in Star Trek Generations[0]. The more responsibility you have, the more there is to do, the more you have to delegate because you can't do it yourself.

That being said, I don't think it's wrong to step back and look at the bigger picture. Just because it's not for you doesn't mean there aren't people who love it, or even prefer it! After all, coding is just a tool. A very finely set tool, but just a tool and nothing more.

Then again, you can have situations like Linux, where Linus still looks at every bit that comes into the kernel, so who knows.

[0]: https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s

This is a poor analogy. Writing code is a technical discipline or a craft, as is technical writing. "Writing English" is not, for any place where English is the business language. From there, the analogy breaks down. If you want a better analogy, it's like the distinction between a reporter vs a newspaper editor. If you make someone who's never been a reporter a newspaper editor, you will likely fare disastrously. But insisting that the newspaper editor should cover a beat? It's just not the same job, so it's doubtful whether that's a good use of the editor's time. The editor is concerned with what is covered, what is being followed up on, and such.

If the CEO is spending a day buried in spreadsheets, then he's likely spending time the wrong way, or is operating a very small business where he can afford to do such things.

Again, the idea of "pushing to the CEOs repo" is actually crazy for all but the smallest shops. There should be no "CEO's repo". There should be "org x" repo or "product y" repo.

I agree with your sentiment that a working knowledge of programming should become something like a working knowledge of Arithmetic. Every educated person is expected to know basic addition, multiplication and so on, and also be able to use a calculator to perform these tasks. Similarly, every person should be taught the concept of a Von Neumann computer and writing programs in a simple programming language. However, building software product vs. writing a basic computer program are, again, two very different things.

>>> Writing English" is not

Honestly writing English is a technical craft. It's just one that 99% of the country has been practising this craft daily since age two. There is literally nothing else we are all so well trained at. Maybe washing?

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.

This is reassuring.

I have a buddy that is a pure coder -- individual contributor type of guy. He will often share his latest clever idea in some code snippet, and while I understand it abstractly, I feel lost when I focus on the finer details. I definitely couldn't sit alone in a room and come up with it myself at this point.

At the same time, _he_ is a bit lost when I talk the more broad architectural stuff I work on.

Thus, I often go back-and-forth on what I should be focused on, especially as it relates to future opportunities. It's helpful to hear I'm not necessarily abnormal or falling off (as it sometimes can feel).

Strong disagree on the leetcode bar.

Any FAANG will still give you algorithm questions in interviews, even at a Staff level.

This is my experience -- your foot gets in the door to get an interview easier though.

There are many type of Staff eng , some of them are solver who solve toughest problem in the team. They need very high standard of coding knowledge.

Two things:

1. Why do you assume people want to work for FAANG? Those are the last places I want to work. I know many people like me.

2. Algorithm questions - you can't forget your algorithms. At this point that would be like forgetting how to ride a bike. There's stuff I learned decades ago in unrelated fields that I work in that I still remember. Even so, it's not lost on anyone that extensive knowledge of algorithms is rarely important in actual day-to-day development work, and the things that are important interviewers rarely dig into.

¯\_(ツ)_/¯

Knowing algorithms and being able to do LC aren’t the same. It’s one thing to be knowledgeable about how a car works. It’s another to be a trained mechanic who regularly works on a specific brand of car. LC indexes heavily on the latter. You need to be very much up to speed. Solving 2x mediums in <40 minutes is the basic standard (1 hard in 35). You’re unlikely to be that proficient without a ton of practice and studying. They’re looking for someone who can swap the engine in a few hours - not the guy who can figure it out over a couple weekends.

I remember plenty of algorithms and the general ways they work but coding them up on the fly without any errors is another thing when out of practice.

Like I said, like riding a bike. If you actually know it then you won't forget it. Sure, you're going to need to practice to get your speed up - but so does everybody.

It’s not really like riding a bike though. There’s so much more effort involved.

It’s more like training for a race. Yes, you can pedal and get there eventually but compared to your competition - you’re coming in last.

Yes - and if you've raced before and were successful then with training you can get back to top shape and be competitive. It's going to be a much easier time for you than for someone who's never raced at all.

I think you’re making it sound easier than it is. I’ve done this many times and to be successful - people have to spend nights & weekends for 6+ months. I don’t think it’s like training for two weeks and you’re good to go.

Again - done this a lot and have worked with a lot of others. Spending half a year is very very common. Those who never stop practicing tend to only need a couple months - but they like that shit so that’s why they do it to begin with.

The article is about doing it again after not having done it for a while. If you've successfully done it before then you can do it again, especially if you don't let those skills atrophy. You don't need to be developing on a day-to-day basis to keep your skills sharp. A couple months practice sounds about right.

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

As someone in that position, it unfortunately has not.

That being said, I refuse to spend any of my time on preparing on LC. I recently lost out on an opportunity at Facebook over this.

Someone from a specific team had reached out to me, was extremely excited about my background, assured me LC would not be a large signal due to my experience and that other rounds would matter more and referred me.

Because of their strong interest I was given a do-over after a sub-par first LC.

After the second LC I was told they wouldn't move forward (so much for other rounds mattering more?)

To me it's a sad comedy. I'm sure a fresh grad who couldn't code a "Hello World" without autocomplete would have outperformed me on LC by virtue of remembering algos I have long forgotten and having the time to "chew and pour" as we say in my country of origin.

Now a team loses out on someone who was (by their estimation, not mine) a great match because of some shibboleth that would have never come up in day to day work?

Obviously I went in willing to potentially accept an offer, but to be honest... had I continued after the second LC interview my plan was to turn them down and cite LC as the reason.

Someone who didn't make it complaining is just sour grapes, but maybe having someone they deemed "worthy" turn down their money to point out how ass-backward the practice is would have meant something.

Yeah, it's definitely a sad comedy, especially when the LC questions they are testing on are usually the exact things that developers should be using an established library for instead of implementing themselves.

I also think that all hiring depends on internal politics, to which the candidate usually has no insight.

Luckily my wife and I have learned to laugh about it.

Don't worry, worse interviewing practices definitely exist :) I've been asked to dictate code over the phone "as you would type it out" for a very well respected place. I've grumbled pretty hard about leetcode dependence in interviewing, but it does seem to form a common language for interviewers to gauge problem solving skills against (similar to how people rail against design patterns -- they're going to exist whether or not we have a vocabulary for them).

As an established professional applying to Big tech, I kind of enjoyed LC prep.

It’s a rare opportunity to see other people solve the same problem as you, and I found I discovered quite a few interesting tricks, and was generally in awe of some people’s grasp of DP (I’m quite sure any DP whiteboard problem would stop me in my tracks).

The big learning for me was exactly the kinds of problems I knew I could solve versus those I knew I could not. I got two of the latter in my interviews, and immediately refocused on getting as much help as I could, which worked, and which I now would see as a positive signal as an interviewer. I’m always happy to hear “this is a problem of type X. I know I need to do Y and honestly I’ll probably need some help but let’s see what we can do”.

I enjoy it as well, but it does feel a bit like I'm being "nerd sniped"! Trying to justify grinding leetcode after an otherwise full day is hard.

I just had the same experience, I basically sailed through to the final interview: four 45min sessions, the first of which was algorithms and data structures.

I actually completed the task fine, but it definitely took me fumbling around a little to get there. I made a point of explaining my thought process and the questions I was asking as I went, but the problem just wasn’t one you come across much in real-world work. (And you know, algos as the first session in the morning before your brain is fully warmed up is brutal)

Importantly, the other sessions (two covering tech they actually use day to day, and a cultural fit one) went great. In the end they passed on me, and when they asked “do you know why?” I correctly guessed it was the lacklustre algo performance. They invited me to “do some study and try again in 12 months”.

Interestingly, the fact that they weighed it so heavily turned me off working there anyway. I was also surprised they didn’t ask me for any feedback on the interview process.

It was a very interesting experience, but I’ve learned that if I want to apply to anything similar in the future I’ll definitely need to grind more leetcode in preparation.

But I’m enjoying taking a break and working on side projects now anyway, and am thinking I won’t be back in an office for awhile :)

All fair, faang is not really interested in developers like you.

They want newcomers who can chew everything.

Their interview process perfectly fits.

This is bad information, leetcode matters more than anything, at all levels.

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! :)

This does seem to fit what I've seen.

I often have this weird imposter syndrome, where I sit on calls for 2 weeks and create some detailed end-to-end design. I then take that design and present it to a a team of engineers are are tasked with actually implementing it.

It feels strange to be doing that, and not having a hand in the implementation (i.e. coding). But then, those same engineers are the ones who come to me for the high-level questions.

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.

Switched twice myself from multi year management to technical roles. If one looks at careers over decades (and the industrial transformation that happen over that time) it can be tough to stay in managerial roles without selling your soul.

There are a lot of contradictions and one has to come to terms with what fits to ones values. The market prefers specialists but generalists often tend to get more stuff done and thrive once inside an organisation. In higher technical roles management skills are often key. Likewise in management roles being grounded in hard facts can be a plus. None of the HR advertised "career paths" help here much as one learns best by doing very hard for real - technical as well as managerial. Switching is hard and takes time but on the other hand one learns a lot. Nothings free.

Managerial skills age better so recovering (jdoss stressed that word for a reason) from a technical doing break does require some planning and having the right environment around one. It also requires having reached real depth in coding, design and architecture beforehand. Part of my job currently requires me to do some training and coaching and I find that really satisfying helping me to recover technical skills and have a positive long term impact on people.

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.

I think most of the guys like you are confused between coding vs copy pasting from stack overflow.

Yeah, no. Neither is software engineering.

Reply on news.ycombinator.com