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.
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.
> 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.
I'd only add/clarify that it's much more valuable to learn the major programming paradigms (OOP, functional programming, massively parallel programming, etc.) than to learn specific languages in terms of being well-rounded and setting yourself up for success.
If you know a paradigm, then for the most part, learning new languages in that paradigm is just a matter of learning new syntax, which is a considerably easier task.
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.
Just to underline this, I know devs in their 20s who became proficient in COBOL because an expert COBOL programmer can make crazy money.
All the jobs I’ve seen for COBOL programmers paid atrociously bad rates.
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.
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
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.
Mindset takes ages to form. And is timeless. Tech stack, you'll always find some more expert than you to hire.
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.
YMMV.
Java and it's eco isn't going away this century.
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.
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.
Unless you think your software is actively harmful, there is no reason to think that the work you are doing is pointless. The problem is that some guy in a corner focusing on just the assigned work at hand is more productive than someone who constantly gets feedback how useful his software is. This then leads to a feeling of meaningless because you are just sitting in front of the screen with a never ending pile of work but never seeing the outcome of that work.
Whenever some new tools or tech comes along that can help us solve real, tangible problems we deal with, the resistance to learning something new is palpable.
Adding to that, any cool new ideas I think we could offer as a business (either as a result of new tech, or even just new ideas using the old tech) is usually met with resistance by people who are seemingly committed to boring stagnancy at all costs.
That’s where I have to walk the line between putting up with boring at work and still have enough energy in me to work on the fun stuff on my own.
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.
"My 20 Year Career is Technical Debt or Deprecated" https://news.ycombinator.com/item?id=35955336
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.
People really pigeon hole you into whatever you already did.
Starting doing what you want to do now, on your own.
That's how I moved from physics to python and django. It's how I moved from python and django to rust.
.NET
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.
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
Html, css and javascript will be useful forever. As will basic computer science, architecture and so on.
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.
Tech debt is not something to be minimized, it's something to be made explicit and managed. The real trick is building machinery that is well documented and easy to maintain.
OSS and stability do not mix.
