A career-ending mistake

> This approach to careers fails to take into account that we inherently change as people.

OP very much talks about this in the last few paragraphs, both in that you can't plan exactly and that you need to course correct as things change.

Also, just because it's okay or may happen that you change tracks within your career, it's still a good idea to optimize the track you are currently on and have an idea of where you want to be. Just coasting because you can't possibly plan your life seems like a strictly inferior option.

I don't think the OP is talking about whether to focus on running the race or not, but rather which race to run. As you grow older, the number of open tracks diminishes and that is the point the OP is trying to make.

While one can change tracks at any time, success is far from guaranteed. Being a distinguished engineer at 40, one cannot suddenly decide to enter the track for CFO or CEO. The track for that accepted entries 10 years back and is already over-subscribed. Only the CTO track is open at that point and only in certain companies.

Well said: I think in this sense, flexibility is key.

And also I want to acknowledge everything that ends our career is not in our control .. like the dual forces of global offshoring / outsourcing and relentless automation (including AI driven) will continue to put downward pressure in the career curves of tech workers for next few years/decades.

I am 67, and equestria is mostly correct. I still get great satisfaction from my tech career, but sure, friends and family matter more. This story involves some work I did that did not bring me satisfaction.

I worked at my first consumer-oriented tech company, right after the dotcom crash. It was a really unexciting interlude in my career. I was given the job of writing the database and Java representation of credit/debit cards, and the related business logic. As often happens, the code grew over time, as requirements and card types were added. And it was finally time for a rewrite, and this code became a poster child for technical debt.

Startup activity resumed, and I left for a far more interesting startup.

Then, maybe 15 years later, I was retired, and doing consulting, and ran into a friend from the company, who told me that a new company doing something very similar, and was looking for help. I go in and talk to them, and discover that they actually licensed the software from my former company. Including my long-in-the-tooth credit/debit/xyz-card software. The code was still completely recognizable, disturbingly so. It lived on far past the point that it should have.

I decided to not take the consulting job. I really did not relish the idea of going back to this very forgettable and uninteresting code. But most importantly, I had just retired, and wanted to spend my summer on a lake, not keeping this code alive a bit longer.

I think that this speaks to an issue that's common across the economy, not simply isolated to tech: the career lifecycle. Specifically, the notion that there's an optimal amount of time and an optimal point in one's life (both for business and employee) for a worker to be in a given position, and that it's again optimal for him or her to not get there too early and to not stay too long.

E.g., tech suffers from the former, politics from the latter, and for both fields, the effect is a warping of the good that they could be doing for society. Society should be set up to encourage "correct" entries and exits and to discourage "incorrect" ones (with allowances, during the transition, to avoid having a "lost generation" that never gets to contribute).

Letting people hang on, with their outmoded ideas, into their 70s and 80s? Forcing breadwinners to take on maximum workplace responsibility at the same time that they are most able to contribute to raising their family or building and maintaining their community? There's something perverse about this set-up. To say nothing of the people forced to spin their wheels while the 10xers load their own plates with all the opportunities.

> but for most techies, the most useful goal is to make money fast in a way that doesn't drain your life energy. And most of the time, this means responding to opportunities, not sticking to your guns. For example, a lifetime IC job may be ultimately worth less than a management job that gets you to VP level in a decade.

If you can switch to management without draining your life energy, go for it? I hope you're a good manager.

Personally, all of my experiences managing people have been very draining.

I have to disagree with your premise.

The goal of many software engineers is to build software / systems they can be proud of. They love software and the machines it runs on.

Many people here have Arduino projects, 3D printers, home servers, and similar hobbies.

A few weeks ago, I was looking for compression algorithms for a particular use case and came across Brotli[0]. I was surprised to learn it was developed by Google. That realization hit me hard. Google used to be a hub for this kind of innovation. Projects like Brotli aren't built to maximize personal profit; they're driven by passion and a genuine love for software engineering.

It's clear that the industry is shifting from being geeky and nerdy to being more business and management focused.

[0] https://github.com/google/brotli

This argument assumes that code is an ends not a mean, which is false. The value you deliver is not your code, it’s the enablement of business functions. Let’s say you launch a new product that gains traction. Sure, in 5 years your code may be refactored out of existence. But the people doing the refactoring only have jobs because of the value you delivered when launching the initial product. That is your lasting contribution, not the lines of code you wrote.

> the most useful goal is to make money fast in a way that doesn't drain your life energy

There's a couple issues with your assertion. Even if you go the VP route, people rarely make VP in under, say, seven years, and usually more like twenty years, without exceptional luck like getting in on the ground floor of a rocket ship. If you don't like the managerial path then you'll burn out long before you get to VP. The second issue is that learning to control your expenses is far more powerful than earning more money. I promise you, no matter how big the salary is, there are people drowning in debt despite of it.

Hobbies, friends, family - none of these should require outsize financial outlay. Doing what you love, building your community, and living below your means is a much more powerful strategy for lifelong happiness and fulfillment, and also much more likely to succeed than some years-long "sprint" to a job you can barely tolerate.

Ten years ago, while a junior engineer at a FAANG, I made a tiny change to one of the most popular pieces of software in the world. It's still executed billions of time per day, and I'm never quite sure if I should be proud or a bit sad that the sheer number of CPU cycles spent on this almost certainly vastly outweighs everything else I've ever done in my career combined.

I don't find that to be true. I remember many of my co-workers... some fondly, some not, but they are remembered. They added as much flavor to my life as my family and friends, if not more, because we spent more hours together. Their work influenced mine and I learned from them. And their insights helped direct which directions we took the projects.

Now, did our presence impact the company? Did our code survive? Or documentation? Do people who work there today have any idea we ever existed? No, perhaps not. But really... who cares? The relationships we have with people in our lives matter, as do the impacts we have on each other, regardless of what our impact was on some rando corporation I earned a check from some number of years ago.

> the most useful goal is to make money fast in a way that doesn't drain your life energy. And most of the time, this means responding to opportunities, not sticking to your guns

This is a tightrope I think many people wind up struggling with—it’s easy to slip into doing something that pays well but does drain your energy, then struggle to wind things back once you’re used to the increased income.

To me this seems to make a strong case for focusing more on relationships at work with people and less on work products. I still remember people I worked with 10+ years ago though I have no idea if the code they wrote then is still in production.

Very true. I saw comments in the code base where I work from someone that had worked there 3 years prior. Most of the people I asked could barely remember the person.

Yep -- this is something I wish I understood earlier on: burn hard, make as much as you can, then do what you _really_ want once you have enough money.

Even in small tech. I worked for an agency in the aughts and we would put up websites at roughly the pace of 1 a week. In my time there I'd guess I'd personally built a little over 100 websites and developed our internal framework for us to make doing so easier.

Every couple years since, I've gotten a bug in my butt and investigated how many sites still had pieces I'd clearly worked on. On this most recent occasion, I could no longer find anything. They've changed over to some open source CMS and I was unable to find anything I had built.

It's been 12 years in there since I left, but as far as I can see on the front side everything I'd written is gone. It's a strange feeling, like 5 years of my life just evaporated.

Given how much of one’s life time is taken up by working, the highest priority besides making ends meet should be to do something that fills you with purpose and is rewarding in a non-monetary sense. “Making money fast” isn’t that for most people, unless you shoot for retiring very early, which is quite difficult to achieve.

> for most techies, the most useful goal is to make money fast in a way that doesn't drain your life energy

Is it so insane to think that it is possible to enjoy your job? I feel that this treatment of your job as a toxic thing that must be handled with safety gloves from a distance may contribute more to the "drain[ing] of life energy" than the actual job itself.

Maybe I am wrong about this, but being a VP is exactly the kind of things that sound like draining the life energy out of someone. VPs all sound completely formatted in a way that only happen if you are under an immense pressure and the only way out is through that very tight exit, which leaves you nearly formatted.

For my previous job some stuff is public, and I can see it's still being used as it gets commits. I left about five and a half years ago. For the non-public stuff I wrote a lot of the foundational code, and I'd be surprised if all of that that been replaced.

The best of all worlds is when you can work with real friends with on cool new stuff. I had a job like that for seven years. I also had enough experience by that point to know I was in a rare situation, and to cherish it while it lasted.

> For example, a lifetime IC job may be ultimately worth less than a management job that gets you to VP level in a decade

How are you positive that you can get to VP level in a decade as a manager? That doesn't sound easy. Just by looking at the number of managers and number of VP in my company it would seemed that around ~2% would eventually become VP if the ratio hold, that's an incredible standard for "reasonably good". Doubly so if you are not even starting from the same track.

There's no guarantee your code will be rewritten or refactored. I have code written over 15 years ago that I know is still in production because it is stable and core to the application. I suppose one day it probably will be replaced but I'm pretty satisfied with that piece of work and found it to be, if anything, more life affirming than draining.

You can have your cake and eat it, too: if your work is satisfying and seeing people use the things you built gives you joy, you can make good money doing something you life without optimizing your entire life solely around ladder climbing or bigger paychecks.

The problem with that is that it drains away your life energy in your late 20s and throughout your 30s, and in fact it's not only about draining one's energy, let's say that would be fine up to a point, but it drains away your purpose in life, and, in the end, your will to live. I refuse to believe that there are people whose purpose in life is to be a manager/VP, and, if they are, they might as well be walking corpses for all I know.

Your argument, while valid, also kind of misses the point of the original post: to know where your career ends, you also have to know what the general trajectory looks like. Basically, you cannot "coast" ever upward "naturally" anymore, because we've learned that's a bad concept (hence the term "failing up").

We pressure people into management roles who have no reason being there other than "that's where more money is" or "that's how you create change". If someone's "end state" is a highly competent and flexible IC, then why isn't there more money for them to continue succeeding at that role as compared to an ineffective manager? For all the talk that tech is a meritocracy, it obviously isn't, otherwise we'd be rewarding the best talent without forcing them into bad roles or hollow titles.

Motivations aren't restricted to money alone, either, as we've seen post-pandemic with the WFH-RTO conflicts. A plurality of workers have realized their time is more valuable than their work, and are refusing to take chump change for multi-hour commutes from affordable suburbs just because their employer is arbitrarily demanding butts-in-seats in a pricey city. Others want their employers to be more involved in politics, or at least acknowledge that choosing to be a for-profit business is in fact a political statement in and of itself; hiding behind faux-neutrality in times of crisis isn't sufficient response anymore. The times are a changing, and the workforce is increasingly making its frustrations known.

Which brings me to your last paragraph:

> ...for most techies, the most useful goal is to make money fast in a way that doesn't drain your life energy.

I would like to proudly stand up as one of those not in that "most techies" crowd. I do this work because it comes easy to me, is incredibly interesting, and allows me to work in infrastructure in a way that isn't building roads or laying pipe. I identified my career ending way back in High School: acting as the jack-of-all-trades IT guy for the school or district, grey hair and hoarse voice, gradually nerd-sniping the kids who, like I was, are bored out of their skulls and looking for a challenge. The money certainly helps (even if it's not nearly enough to buy a home close to the office), but my career begins and ends in ultimately the same place.

And that's the point of the post: identifying where your career ends, and the arc it takes to get there. It's why I'm doing the leadership courses and trying to beat a new path upward in the corporate world, one where highly-competent ICs who are also good leaders are recognized as such and put into long-term positions within an organization, to weather the storm of cyclic leaders and fickle shareholders, and ultimately build a stronger, successful, and sustainable entity as a result. I need those years/decades of leadership and money to reach that position where I have a paid-off home, decent retirement savings, and can finally dedicate my remaining time and talent toward building a better future for the next-generation of people.

> Your code will get refactored or rewritten. Docs will be superseded, then lost in some CMS migration. Before long, it will be as if you have never worked there.

The exception is if you build a fundamental component of the system, and that component is so unique in what it does that nobody who comes after you will even consider the idea of ground-up reimplementing it, but instead just has to immerse themselves into your mindset, trust your docs, etc, whenever they're maintaining that component, forever.

---

The bad/painful version of this, is when the component relies on unique hardware (e.g. a mainframe's native IO-acceleration capabilities), and was designed by someone who was immersed in that ecosystem and understood how to write code to take advantage of it. So the code is incredibly non-portable, written in terms of the low-level abstractions of the hardware, that nobody else in the company will ever understand to the same level the original programmer did. This is e.g. flight booking.

You should hope to never encounter these, since they make the rest of your service that has to interact with this thing into a tar pit of low momentum, from your lack of ability to effect change on this component.

--

There is a good version of this, too, though: when the component relies on unique concepts and math (say, doing static analysis by generating constraint statements and solving/simplifying them using a prover) that are portable, and could in theory be reimplemented in a new codebase if desired... but which were literally invented by the programmer in the process of implementing the code, at the climax of months of lateral thinking about how to solve the problem. This is an engineering True Dweomer.

There's usually nothing wrong with codebases containing True Dweomer code; they're not any less maintainable than usual. And they solve a problem that isn't solvable with simpler solutions — that's why such a weird solution was arrived at in the first place. So they usually tend to stick around.

But everyone who arrives at the company will nevertheless be slightly afraid of touching the True Dweomer code. They don't understand it, even though they know they could understand it given enough time (and prerequisite textbook reading.) Unlike mainframe code, people might look fondly on the code, looking for opportunities to be assigned to a project that requires that they come to grips with it... but the project usually ticks along by itself, not requiring much maintenance.

(What you'll actually hope for, is that whoever writes the True Dweomer code requests to lift it out, out of whatever project it's a part of, out of the company itself, into an open-source project. Because that way, that person who does understand it, can keep maintaining it, even after they leave.)

[dead]

> almost no one will remember

And that is true for all memory, I suppose. There is none. It's constant communication, down to the quantum level, a constant vortex of information, and if the vortex stops, all memory is gone.

> Never once have I had any semblance of a "plan" or a "goal". And despite what all the authority figures in your life will tell you, that is a perfectly fine way to live and be happy

That's the ideal career for sure, but how common is it?

It would be great if I knew I could bumble along and become a staff eng/manager/director without any sort of plan or goal. I don't believe that's a common experience though, and it seems even more unlikely for people who are at the start of their careers today (Like me).

I think he covers this early on: if you don't aspire for anything more, congrats. Incidentally I'm in the same boat. Literally told my manager "nope, not really interested in pursuing a promotion. Just want to be paid fairly and continue working at this level." They actually appreciated having one less engineer that they have to try to cultivate a career for.

I'm happy to hear this. Cheers.

Have you had a common theme for these projects you navigated?

A friend of mine, who is quite successful in his occupation, told me that his motto is: "Always do the next thing."

Our culture possesses this weird belief, that people always need to be transformed. This cuts across all ideologies, ranging from religion to Marxism and corporate culture. I think simply declaring "bullshit" to that belief can lead to a much happier life.

IMO, there's no such thing as a career in tech, outside of maybe FAANGs (or whatever they're called now). It's just a series of jobs until accumulated wealth, ageism, or disability ends it.

If your goal is to get a cushy high paying job you will need to make sacrifices, otherwise that job would no longer be cushy and high paying. Some sacrifice their 20s and grind an education, career, and have no kids or spouse. Others put a large burden on their spouse to retrain, you have to weigh the short term toil versus the amortized improvements over your career. And it is important to remember that luck plays a part as well. Some get lucky on their first go around and others never get luck in life. The only thing you can do is maximize the number chances you have for good luck.

It is important to live well within your means. Having an extra margin makes job and life changes much easier and lower risk. Many people’s expenses grow to their income and they paint themself into a financial corner. Unfortunately once you are in that spot it becomes much more difficult to get out, and larger sacrifices need to be made.

There are always options, and we have more opportunities and “stuff” than any other generation which has lived. Our stuff and jobs should serve us and not the other way around.

This is the point I was going to make as well. I think the article is written for high-agency people, which are rare in my experience, even in tech.

Also related: The Peter Principle: people get promoted to their level of incompetence. We think we want something but then realize the job is actually harder than we thought, so we do a bad job (or burn out).

So to the excellent points in the article I would add an introspection about the level we want to achieve and how to continue working at that level, assuming we don't hate the job.

What if it’s an article for self-determined people ?

Or meant to plant a seed of thought in someone’s mind ?

> I can’t lose ten extra hours every week away from seeing my family

I hope you find the time to make it work for you.

And , I don’t want to assume but so have found “I can’t” attitudes don’t work for effecting change in life.

Maybe work on that aspect of your personality.

What kind of advice would have been better?

I agree that Managers/Directors should have a deep technical experience but having them contribute code to the day to day development is not a good situation for anyone (especially the companay).

There are some different aspects to this; The director will have many other responsibilities and may not be able to provide to provide the research/expertise required to produce a good code solution to the issue at hand and integrated with the rest of the system.

The rest of the project team may be delayed with waiting for the directors code and may well find it difficult to co-ordinate with the directors level of knowledge (which is perhaps out of date). In general, criticising the director for delay or bad code is not likely to be a career-enhancing path.

In small company/start-ups, this a common condition that does need to be remedied. Directors/managers have significant responsibilities that needs to come first rather than feed their own ego/desires. Hire good people and direct them to scale the business, your job is different now and you need all your skill/time/resources to do it well.

In short, personally been there a number of times and it wasn't good for anyone. But we struggled on.

> It's not true that in all companies you have to chose between tech and management. It's true in some companies. But at many companies lead and director roles are very hands on.

I‘ve seen bad companies where it is true, but in good companies typically not true. Look for example Peter Norvig, 100% hands on technical type, but in a high management position.

there is a difference between "technical" and "writing code every day".

c-levels, VPs, and directors can be very technical, but rarely write code. team leads definitely do, though it may be only 3 days a week, and rest is org/planning/pr reviews.

only at small companies does the CTO write code. our cto has written plenty of deep code back in the day that enabled the business to scale to its current size.

> management without technical excellence track is just misguided

It's different technical excellence.

What's not given proper weight is that it's different technical excellence. Roles seen as "more management" demand system-level understanding and technical knowledge. And a technical knowledge that includes what many see as not technical such as awareness of people or finance dynamics. They can, should be seen as technical aspects. A more senior, "more management" role has different levers to use to make projects come through. And these are different higher level projects. A more senior role is also free to juggle reports who specialize in this or that. If you hate or you are bad at task scheduling, have someone do that for you. If you are not great at writing speeches, etc, etc.

Among the ways you can prepare for that: (1) find at least one mentor (someone at least two steps more senior who can guide you on what to think about and on how things work. If the people two steps up in your company are bros... your mentors don't have to be in your same company.) (2) Consider what's missing to your skillset - and that's not planning software but maybe it is.

There is also a difference between being a capital-L Leader, and leadership. Healthy companies have space for technical leadership that is different from being on the management track to being CEO.

> While planning might work for some people, having a more short term view can work for others

One thing I noticed is that what I valued in my 20s wasn't what I valued in my 30s and 40s. It's difficult to anticipate who you will be in a few years from now. It may change drastically. Keep that in mind when planning!

Agree with the above. Seems to me, the many of us "going with the flow" without a thorough long-term plan, are perhaps applying Agile development principles to our "career" (aka series of jobs) , whereas the author is taking the nowadays-apparently-discredited Waterfall approach , where supposedly you can know where you're going to be at date X. Which of course we now know doesn't actually work out in software. And as for careers, even more so. One cannot predict the overall economy, or who one might marry , how many kids one might have, whether everyone is healthy in extended family, what one might feel like doing to be happy later on etc ;)

Could you describe how each job hop was less annoying than the less?

I know it’s a big ask.

I am just insanely curious to know.

The more capable you are, the more experience and ability you will have with specialized skills which will result in people that don't have those capabilities to think that your skills are not transferable.

If you find a magic workaround to that, please let us know.

> ...My favorite career end that I'm naturally working towards to is the ability to jop hob to different roles without having prior experience. One way to do that is to be able to show in an interview that you have transferable skills and learn crazy fast. Another facet of that is that you need to identify companies that are open to this sort of thing...

Maybe its been the job hunting climate of the most recent decade or so...but I no longer see opportunities for jobs where employers are willing to take on someone who might be awesomely enthusiastic, and well-rounded, but lack a very super-specific set of skills. This also goes back to those ridiculous job descriptions where an employer __"requires"__ a candidate to have, let's say, 10 years of a specific experience - even though said skill might have only existed for slightly over 10 years.

I wish i could do something like that: sort of jump to a different role without prior experience (or at least very little experience)....For me it would be more of an intellectual fulfillment, and wanting to learn more, etc...And, for any employer who would give me that chance, i'd legit give them 110%! But, i'm not holding my breath for that.

> A sweeping statement indeed, but it does reflect my experience too.

IMO - managers are terrible at the same rate as ICs. But the damage a terrible IC can do is limited in most companies because there's guardrails like automated testing, pull requests, no access to the production database, etc. At worst they end up being a big timesuck for other team members until they get let go.

A terrible manager will sink a project or team single-handedly, though.

Just as a personal data point, most managers I had in my now 25-year career in tech were good.

They set clear goals and expectations, provided honest feedback, both positive and negative, and quickly jumped to help re-plan when things did not work out.

They were also asking what I am optimizing for (for me at different times it was more money; promotion; interesting problems to work on; time to explore other long-term products) and as far as I could tell worked with their managers to move me in that direction, sometimes successfully, sometimes not.

I did not assume any of my managers had my best interest in heart, but one of my first managers gave me some lessons on "how to manage your managers, myself included". It took a few iterations, but he convinced me that by far the #1 thing most managers want is for me to deliver things on time; not cut a few days off the project timeline. And if I learn to do that, they will advocate for my interests, shield me from corporate BS, etc.

Some specific advice from that manager was (in his words) "never promise something in 2 weeks unless you could demonstrate it today" and "do not sit quietly when you are given unrealistic timelines; counter with specific subtasks you see and how long you expect each will take". That general advice worked very well for me and helped build symbiosis with direct managers.

I did dislike a few managers, but those were generally good ICs stuck into a management role they did not like (or at least did not know how to do) and kept both sticking their fingers into what their team was doing and start timeline discussions with "it would take me one day to do this, I will give you two; go-build-this-now".

Again, just a personal data point; not claiming that most of the world works this way. I may have been just lucky.

I think that’s largely due to the weird notion that engineers will eventually “upgrade” to management, as though one is the advanced version of the other.

There are whole degree programs dedicated to managing and organizing people, but we’re like, “nah, Joe’s a good programmer so we should talk him into stopping that so he can supervise people instead”.

Fact is, there’s little relation between the two. A person may happen to be good at both, but expertise in one does not imply adequacy in the other.

We train people in their technical role, but we (generally) don't train people to manage -- and years of poor experience don't count.

I'm not a manager, and I don't want to be. But I'm quite happy with the manager training that my employer puts people through before giving them direct reports.

One should always be negotiating expectations, though, even when one considers management to have our best interests in mind. And also remember that your manager is learning how to manage from you. You get to shape their experience of being a manager, and you get (to an extent) to guide them in how they grow as a manager.

OTOH, this can be a case of the "if everyone around you is a jerk, the jerk is really you" rule.

If you can't work well with any manager the common denominator is you. It's also the only thing you can change.

People rise to their level of incompetence[1]. This simple principle explains most managers completely.

[1] https://en.wikipedia.org/wiki/Peter_principle

My first manager was really good so it came as quite a shock when the next one turned out to be a lying, conniving bastard. Given enough experience you get hardened to it. Of course it would be better if you didn't need to.

> it's better to maintain a kind of defensive attitude

As a manager/developer, I do sometimes see this attitude in some devs. I try very hard to help them find a different job where they are not working for me.

As a person whose done it all, independent stuff, senior ic stuff, management stuff, the main thing that makes management terrible is simply that most companies have no support for middle managers.

You are a good IC? Sure let's promote you to management, but in 95% of cases, we're not even going to pair you with anyone or have a senior manager help you understand, build and grow - we're going to throw you in the deep end and have you sink or swim.

This often ends up with stressed out people used to doing well now approaching an entirely new problem with slow feedback loops and entirely different protocols than before, and the amount of burned out shitty middle managers I see is off the charts.

My wife asks me from time to time: "What do you need to learn now for the next five years of your career?"

It's a great question. It is also, I think, the right time frame, though one could argue for three years instead of five. Given the terrain I see now, I can plan for the next five years, and have those plans be mostly reasonable most of the time. Past that is harder.

In a similar fashion, I try to address all sorts of corner cases in my code, to the point of being called obsessive by some colleagues - but it definitely helped a few times with really stubborn and obscure bugs.

An extra log line here or there, or an e-mail sent to the admin in weird situations, goes a long way - provided that you don't generate many false positives, because no one pays attention to a program that cries "binary wolf" too often.

The person (Denpok) who quotes it is a charlatan posing as a guru, which makes the fake citation fitting.

Yeah, the Lao Tzu I know advises people to be simple, like uncarved blocks of wood.

Less competent in what? The people with decision-making power are supposed to be good at some combination of product innovation, product management, sales, marketing and accounting. ICs are only suited to making some decisions in the first two, and have next to zero expertise in the others.

I'm always happy to talk through career and engineering issues.

Hit me up, if you're interested: https://www.linkedin.com/in/neurohack/

I want to be able to work as a generalist who can learn most coding stacks and a wide range of experience in backend(ranking/recommendation) systems, data engineering and some early career full stack experience.

I highly recommend folks read Ecclesiastes, which opens with "Everything Is Meaningless". It's a philosophical book on what matters in life (and what doesn't).

  What do people gain from all their labors
    at which they toil under the sun?
  Generations come and generations go,
    but the earth remains forever.
  No one remembers the former generations,
    and even those yet to come
  will not be remembered
    by those who follow them.

Oh and by the way: you might die sooner than you think. It happens all the time. Are you spending time the way you want?

And those who can't manage people become managers of managers.

> very common today... the majority of companies that no longer train or encourage career development.

I don't get this. What is stopping anyone from doing that themselves? Why does someone else have to do it?