There is so much churn in software. For new kids its easy, you just pick up the latest thing. But for older folks, over the years you've placed bets on longevity of stuff, invested in the ecosystem, only to see those replaced overnight by new projects. It's despairing.
At every point, you felt like the tech was good enough, but then the community and ecosystem just packed up and left somewhere else - to something that is not debuggable, and has crappy IDE support, and is slow to compile (e.g. Rust) or even run (e.g. React). And this is going to keep happening.
Does anyone see this changing anytime soon? I just want to have one stack and master it.
As long as someone pays me a highly inflated salary for doing things that other people can't because of the lack of proper CS education, I am totally fine doing tech debt.
Perhaps the key isn't to focus on specific languages, libraries, or frameworks, but on what you're building and the problems you're solving. You can learn this as you learn new tools, but the key is to keep your eyes and ears open to these details as you go.
> For new kids its easy, you just pick up the latest thing
I think it's actually hard for them because they don't really understand what the new thing is, why it is, what it does, etc. Sure they can learn the ropes quickly because so many modern tools have such ergonomic development experience, but they don't actually know what's under the hood beyond lots of code.
That touches on an important thing to learn, which is the "why". New developers often understand the why of things — from languages, to tools, to features, to entire applications — in a very limited and superficial way. It doesn't often change much, though. You can see underlying patterns and conventions that have spanned decades in various forms, even in newer tools like React. And really, React is dramatically easier to learn once you understand what it's doing and why. You'll fight with it less because you know what does or doesn't make sense to do. For example, you won't try to couple imperative code with components, because you know declarative conventions make much more sense. You won't litter props with inline functions, because you know the function references will never be the same and reconciliation will never be ideal. These lessons will come with you, because the code driving all of this uses common, fundamental, truly useful patterns you'll encounter elsewhere.
The more you can learn why things are the way they are and how things work, the more you'll see that these underlying reasons have significant staying power. Understanding this stuff even makes it a lot easier to adopt newer technologies; you can anticipate how you're supposed to utilize it, and why.
It is rare that stacks go away entirely. There's still a bunch of folks in their 70s employed writing COBOL, just as I'm sure there's at least 1 operating blacksmith within driving distance of you. The option to rest up and ride out one stack is there, but yeah the fun new work stops going to that stack.
I went through a similar mid-career burnout where I couldn't face jumping in with the 21 year old fresh grads to ramp up on yet another round of bloated frameworks. Shifting to management was the route out for me where I get to direct high-impact work and provide guard-rails that stop my reports from repeating the mistakes I made. They are all far better programmers than I ever was, and I've been doing it enough years now where it's profoundly satisfying to see my early hires thriving and far surpassing me professionally - while none of the code I wrote even 5 years ago exists any more (another existentially depressing thing about our profession).
If you love coding and want to keep working on green-field stuff, the freelance (contract, consulting, freelance, etc) route might be good for you. Change in this field is inevitable, and only going to get more rapid. You will need to either keep adapting, or find a way to incorporate or shift to something that has more ever-green skills.
> over the years you've placed bets on longevity of stuff, invested in the ecosystem, only to see those replaced overnight by new projects.
As an older dev, I haven't done this. I learned early in my career that it's a mistake to put too many chips into any language or ecosystem, because very few things have any sort of real longevity. This means avoiding dependency on any particular stack, tool, etc. so that I can more easily adjust to the inevitably different demands of the next project.
This is how it's always been, and I don't see any reason to think it will change in the future.
I have gained a pretty strong professional advantage in doing this, because I am at least competent in a very wide swath of languages and ecosystems, which makes me hirable in a very wide range of companies.
> I just want to have one stack and master it.
You can do this, though. It's called being a specialist. Even if any given stack is unlikely to be dominant for all that long, if a stack has been used heavily at any point, there will always be a demand for devs who work in it.
If you're lucky, it will be a stack that is both rarely used anymore and was used heavily enough that businesses have a large investment in it. That's where the big money is, because there is a limited group of devs who can address a critical (if small in terms of market size) need.
Is this a 0 interest rate phenomenon?
Historically, old software hung around. And the new greenfield stuff had a high bar to clear to replace what currently worked. The momentum around something already in prod is pretty high, and big rewrites are hard, whereas incremental refactors are easier.
The last 5-10 years seems to buck this trend: you got promoted by claiming credit for some new service that does the same thing as a legacy thing (maybe even less, lol) but in Rust, or some new fangled framework. Sometimes this happens because truly, first principles, its the right choice. Other times, it can be dubious, but enough people have convinced themselves that staff is needed to do this. And directors and tech leads will get a promotion when its done.
Lately, I think there's a lot of frugality in tech: do we _really_ need to rewrite FooService? Do we really need to migrate to NewFangledThingX?
I think and hope there will be a renaissance in boring tech, and rewrites of something will be cautious and only done when first principles the old thing can't solve the problem anymore.
BTW, I've been in this field long enough to know we're all tech debt in the end ;). It's the nature of the beast that old things get rediscovered, and spun new ways. Don't get too curmudgeonly, nothing is ever truly original, but there are evolutions on ideas. And many fundamental skills stay the same: software engineering, testing, performance, team building, reliability, etc, will last a long time
> I just want to have one stack and master it.
Java, PHP or C++ is probably where you want to look. I get these aren't the cool new things, but the thing is that cool new things come and go all the time. Boring and technologically conservative things have sticking power.
A good yard-stick for how long a technology can be expected to stay around is as long as it's already been around. A 50 year old programming language? Yeah it's probably around in 50 years. Last year's hot new js framework? Probably dead in a year.
invest into soft skills. hard skills come and go.
Mindset takes ages to form. And is timeless. Tech stack, you'll always find some more expert than you to hire.
Move on to backend development and see your craft run for over two decades if that's what you want.
Once a backend system is working well no one wants to mess with it, and as the time goes by and the original developers retire, documentation disappears and the technology ages if becomes literary impossible to replace.
With UIs you have no choice but to keep upgrading because browsers and mobile devices change and interfaces eventually stop working, usually every 2-3 years.
If you pick a niche in mission critical backend systems and become an expert in that domain you don't even need to worry about ever being out of work or having to retool and learn new skills.
Your customers will be terrified at the possibility of you not being around when they need you, because no one else can debug those 6000 lines of Fortran that keep a $US billion-a-year business running, so you can agree on service contracts that literally pay you to commit to answer the phone once or twice a year when things break or a new functionality needs to be added.
But then you'll be looking at front-end developers, their tools and modern languages, feeling like a dinosaur that missed the train of progress while sipping micheladas in Puerto Vallarta.
I retired from software in 2013 in my early 30s. At the time GWT (google web toolkit), Meteor, PerconaDB, and Mercurial were still trying to become a thing.
I think the focus on particular technologies is wrong. Better to focus on a sector and become a master of that sector than of a particular technology.
If I could go back 20 years I would stop myself from jumping between jobs while staying inside a tech stack. Instead I would tell myself to jump between jobs inside a specific sector, regardless of the tech stack.
I’ve reached that stage now, where I’m focusing much more on domain knowledge and don’t care so much about the languages used. Languages are easy, but in some sectors domain knowledge and the ability to write code can be hard to come by.
Being this sort of developer, your value rises the longer you’re in that sector. The more in-depth your domain knowledge, coupled with the ability to translate that into solutions and code, becomes incredibly valuable.
By sectors, I mean: fintech, healthcare, security, etc. Not startups.
Personally, I’m less invested in the tools I’m using, and more invested in what I’m creating.
Granted, it is frustrating sometimes to see tools that you really enjoy using, be replaced with tools that aren’t as good or as well thought out.
But ultimately, I believe that you can create just about anything, using just about anything, and even if you’re forced to use a toolset that you don’t like as well, there’s usually nothing stopping you from adapting those tools to help you create what you want to create more comfortably.
Also bear in mind - if you stick around long enough OR study your computer science history, you’ll realize most things are cyclical, and there’s very little that’s actually new.
Almost every new trend is a new incarnation of previous concepts. Master the basic concepts, and everything else comes pretty naturally.
I’m 15 years in to my career and feel the opposite. My stack isn’t some language or tool, its the entire field. The more I learn, the more ways I solve a problem, the more mastery I get of computer science and software engineering. It never gets old and I love it.
> Does anyone see this changing anytime soon? I just want to have one stack and master it.
No, this will never change. People in software need tech stacks because they are terrified to write original software and everybody has their own personal opinion about tech stacks. The most universal behavior in software is fear/insecurity because most developers are poorly prepared and lack trust in their leadership, so instead we turn to personal opinions of technology stacks to either mitigate away talking to people and/or making original decisions about architecture.
This recent submission seems tailor-made for you:
"My 20 Year Career is Technical Debt or Deprecated" https://news.ycombinator.com/item?id=35955336
A philosophical approach may help. Change is the only constant expectation that I have. All of my past work over 25+ years is now deprecated, obsolete, tech-debt, or irrelevant. It is the nature of software. Intangible work built upon ephemeral stacks, all to go away with time. My personal metric: how much I can keep pace with. Rate of change vs deep-rooted expertise.
>I just want to have one stack and master it.
C/Linux isn't going anywhere in our lifetimes. If you want one stack, that's it.
For anything else, yes the layers of abstraction will continue to accumulate.
> I just want to have one stack and master it.
.NET
All software is technical debt. It has to be maintained, deployed, debugged.
Debt is not inherently bad (mortgage, operating lines of credit, financing a purchase because we’re gaining more with our investments than the debt costs).
We do it (debt) because it’s better than the alternative. In the case of software we earn more from having the software than the maintenance liability.
If you’re concerned about debt make sure your debt is serviceable, and at a reasonable rate, and gains you more than it costs you.
> "I just want to have one stack and master it."
There's nothing stopping you from doing this, and it's less expensive than ever before. You can master PalmOS, beej even collected everything about it into a single pdf document https://beej.us/books/palminomicon.pdf
Learn and master fundamentals and not technologies.
Html, css and javascript will be useful forever. As will basic computer science, architecture and so on.
Life is about adaptability. Needs evolve. Tools stop making sense for those new needs. So you use or build a better tool. Or you improve the foundation to buy you some time.
Your company will replace or remove you without a notice when it needs to adapt to economic conditions. Same thing with the tech stack and debt.
Technical debt is a part of development, write a new loc that meant adding new debt. I don't think this situation will be changed anytime soon, it isn't easy to deal with legacy code/services.
every line of code is tech debt its tech debt all the way down
Forgot tech debt, most of the projects I have worked on have been outright cancelled!
My career is solving problems for companies/people. The tech in itself has very little value, in fact if I could I wouldn't write a single line of code. Waiting for ChatGTP to get there..
This is called progress. It's not always upward or steady, but it's a process you were once a part of. Probably careers and services wouldn't exist were it not for you.
Understand that all the tech is the same under the surface. Reach enlightenment by learning how to quickly map the surface to the underlying reality.
Yes but only because all code is tech debt. Yes even the code that you architected perfectly and is a work of art, that’s tech debt too.
Learn math, it will never become obsolete.
Java and C++ aren't going anywhere.
You’re saying you didn’t bet on Java.
What are complains to React, just slow running or anything else?
like to over come the hitman
We used to have this debate about X11 versions thirty years ago. UI's were a mistake.
OSS and stability do not mix.
Computer Science is, on a evolutionary level, a whole new field, something between a branch off of Mathematics and physical engineering so... no, it won't stop changing anytime soon. If you wanted something more timeless, perhaps you should've gone into the engineering of buildings, transport etc.
There's definitely something to the "choose boring technology" approach. But to paraphrase Palahniuk "on a long enough timeline the survival rate for all technology is zero". Everything becomes tech debt.
If your solution makes it a decade that's a huge accomplishment - you got that abstraction fairly well nailed. Now think about all the systems you use that were written 10+ years ago and how clunky and painful they are and how you wonder why nobody upgrades this thing or replaces it with something more modern - that feels like tech debt, no?
Hanging your career on a single technology has risk - your bill rate is gonna plummet if the stack goes out of style and you don't move on, or as the market gets saturated with people that have enough skill with it. If the framework hangs on long enough your bill rate might go back up as companies get desperate to maintain the things built on it that they haven't managed to replace. It also has positives - you'll be very proficient with building things with it and likely know how to mitigate its limitations to get stuff done efficiently.