I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.

> 4. Being paid less than the lowest grade manager, is not fun .

At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.

> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)

Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.

This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.

So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.

The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."

And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.

See? There are plenty of ways to be a technical leader without being on the management track. :-)

What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?

And you're dead right, not every place is Google or whatever. Hell I don't think Google's Google, mostly, in terms of what they actually do, but they do pay developers very well regardless, so there's that. But outside a handful of huge pure-tech companies and Wall Street, you better be moving out of development by 40 or so (earlier if you can swing it, really—god I wish I'd started making moves this way years ago), or your career's (pay's) in for a brief flat trajectory followed by a sharp drop way before you'd have liked.

If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.

In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company. If you think you're ready and your current employer does not, you'll have to look outside.

Years of leadership seems like a purposefully vague credential. It's not about a title; if you don't think you've been a leader at work, you probably weren't (or maybe you were and your talent just wasn't managed properly ¯\_(ツ)_/¯ ).

Also, get ready for a lot of gatekeeping. “Oh, you don’t really want to be a manager! It’s so much more responsibility and work. You should be happy to be a foot soldier for the rest of your career! Management is not all it’s cracked up to be. As you can see I’m stressed all the time! Now excuse me, I have to go close on my second vacation home in Hawaii.”

[EDIT] my suspicion here is that yeah, it's basically "luck into it". I mean that's how everything else I've done career- and pay-progression-wise has worked (luck into someone tasking me with something they definitely wouldn't hire me to do, but after I've done it for a few months someone else would) so maybe this'll work out the same way.

Is it even possible to find a management position outside without management experience?

I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..

There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.

There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.

So now the only thing left that tickles my fancy are the "abstract" problems.

Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.

Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.

Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.

I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.

I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.

> "it's the people managers making strategic technical decisions"

...was true in your case.

In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titles like “director” and “VP” and “CTO”. How many of those people have you seen who are individual contributors?

If this is the case, your company's technical leadership track has a broken pay structure. You shouldn't need to go into management to get paid better.

If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.

Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.

(But if you're bothered by having a manager younger than you, that's on you; I'm not sure what the inherent problem with it is. When I was a manager, I managed people older than me; now that I'm a senior IC, I have leadership younger than me. Both things are fine.)

It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and move to management.

> because you can't invert a binary tree in 20 secs in leetcode

It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

> 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

I've been managed by former students. Worked out quite fine for me. Why wouldn't it? Age does not equal competence.... I'd rather be managed by a competent young guy than an incompetent senior. (bad managers are no fun, that I agree; but bad managers are not necessarily young; and young managers are not necessarily bad)

> Being paid less than the lowest grade manager, is not fun.

Being paid less than what you're happy with is no fun. But it's not really required.

> do you really need 20 yrs of coding experience to write CRUD apps

So don't write CRUD apps if you're better than that.

> What exactly are you bringing to the table.

In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.

> There is no such thing as "IC track" for almost every one of us,

If that were true, it all becomes a huge pyramidal scheme (you constantly need more young developers so that you can manage them as existing workforce ages).

I'll give you that: for most people, it's probably easier to advance on the management track than it is on the IC track. And the IC track in many companies is a joke (if you're not at the headquarters, advancing is an order of magnitude harder; also you advance easier by playing the advancement game than by being competent in what you do - but that may be true for management too). So yeah, it's not for everybody. But OTOH, middle management sucks... big time. For some people, it may be a good deal to sacrifice some cache upside than to turn into something they don't want to be. It all boils down to what you want to optimize. If you're happy with a good income, even if it's not the best that you could possibly achieve, IC track might be an option (still, change companies every now and then. It's much easier to promote this way).

ok. I was being facetious with that (particularly famous) example.

you are able to breeze through hard leetcodes in your 40's in a tech interview setting?

Why would you be faster at 60's vs 20's , not sure i follow the line of reasoning.

> So don't write CRUD apps if you're better than that.

Can you give me some examples of better things that actually require 20yrs of experience ?

Am I as good as I was in my 20s? No. But the truth is that most people can't do the simple recursion... very few places will deny you employment because you can't invent original algorithms on the spot. They'd just fail tou for simple examples like the one you presented. The amount of people who can't do a tree traversal unless it's DFS is staggering. (and in all honesty, not all of them are useless programmers... sometimes people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)

[edit] > Can you give me some examples of better things that actually require 20yrs of experience ?

I saw this just now. Lots of things can use said 20yrs of experience... maybe even some CRUD apps (e.g. to know what to not over-design). Some things you probably can't do right without extensive experience (say, design a new programming langugage; or a new datastore). E.g. Rich Hickey famously designed Clojure because he wanted a better way to do those "CRUD apps". Also, it's quite easy to find a hard problem that you won't solve without extensive experience, no matter how smart you are (say: collaboration, data management & versioning in large AI teams). Pretty much any open-ended problem, really... remove all constraints and most programmers will get stuck. How many people can start with "void main()" (or equivalent) and actually release it to production, if the project takes a non-trivial amount of time to complete?

Re that example, I was just using this famous tweet.

https://twitter.com/mxcl/status/608682016205344768

You don't get a job solving simple recursion problems. You have to solve hard leetcodes.

Also, 2years ago (I think) I participated in Amazon TechO(n) challenge... I was 1st after the weekend, but couldn't work on it during the week (no time/ kids) so by Friday my solution ended up 5th or 6th I think.

[ninja edit] No, I'm not faster, I'm a lot slower. In fact I probably lost most of my speed in the first few years when I stopped competing... but it's not a linear function, at some point, you don't lose any more speed; and just a quick refresher every now and then can boost your abilities back to fairly high levels. And most interview problems are not really competition problems, they're fairly basic.

And no, I don't write algorithms from scratch currently, the company I work for might actually be characterized as "boring" by many people("robotic process automation" - look it up). But I've lived to learn that when there's lots of money involved, there's also lots of interesting problems to solve - one just needs to find them.

You seem to have gotten faster. For most people this knowledge tends to atrophy as they age. Maybe you are lucky enough to work at job that requires you to write algorithms from scratch ( embedded engg?).

What is your theory as to why that homebrew guy wasn't able to solve simple recursion problem ?

> people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)

It's important to note that this doesn't mean algorithm tests are inherently broken. People who can't solve _basic_ algorithmic problems tend to be weak employees. Rejecting them screws your recall (a few would be amazing if hired) but tends to improve the precision a lot, so the trade-off is often worth it.

> In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.

So true.

I would add the ability to look farther ahead at potential problems. I have seen so many young people blocked by some issues that should have been spotted way earlier.

> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

My main problem is that I look like an idiot while writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.

All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.

I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.

On your points,it sounds more like bad interviews if they're about syntax, not about the logic.

OTOH I'm already near the top of my earning potential as an IC in my area (and for most remote work that doesn't require some prior connection with FAANG & co or excellent skills at algo interviews) so I'm looking to move to roles that don't require that particular kind of prep and are higher-paid besides, tending to be more about concepts, people, and communication (architect, manager, that sort of thing). So I've done just fine working (and interviewing) the way I do, and hopefully the sorts of interviews I'm bad at won't be relevant to me a job or two from now, anyway.

>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.

This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.

>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.

>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.

Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.

>>4. Being paid less than the lowest grade manager, is not fun.

Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line? Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.

>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.

EDIT: Formatting