Here's the thing about the average career in big tech: five years after you leave, almost no one will remember you were there. Most of your old team mates will leave for other other jobs. 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.

I know it sounds preposterous, but ask anyone over the age of 55 or 60: except for folks who built their own companies or made truly exceptional contributions to their field, most will say that hobbies, friends, and family mattered a lot more.

So, there is this fundamental contradiction in this article: you can engineer a very neat career, 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. You don't need to dream about being a manager; you just need to be reasonably good at it.

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.

> 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.

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.

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.