Ask HN: Anyone else feel like their whole career will just be tech debt?
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.
62 comments
[ 5.2 ms ] story [ 97.8 ms ] threadThere'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
OSS and stability do not mix.
Mindset takes ages to form. And is timeless. Tech stack, you'll always find some more expert than you to hire.
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.
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.
However, just to offer a counterpoint, one thing I have seen time and time again from highly-motivated technical people is that they place the new and exciting technologies above the actual business needs. There is an inherent risk in using cutting-edge tools and technologies, and if the business is working well with the current stuff, why take a risk you don't have to?
Of course, the other end of the spectrum is only using completely obsolescent tools, and that can be a problem in and of itself as well, because it also brings risks with it.
I have, unfortunately, been on teams where these people got their way and it led to very expensive project failures because when reality came to bite, they couldn't deliver. The new stuff couldn't meet the requirements. Using existing technologies which were known quantities would have avoided that risk entirely, even if it wouldn't have been as fulfilling for them personally. The company isn't run for individuals' personal amusement and tech fetishes, and sadly when that takes priority over all else, it can lead to failure on colossal scale.
I still try out new stuff, but I don't propose we use it for serious business-related activities until it's been fully proven out.
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.
All the work I do has business value (at least, perceived business value) but I don't think it's fun or exciting to do. It bores me to death. Too much recently, actually. If the job market weren't so shit, I'd leave.
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.
YMMV.
Java and it's eco isn't going away this century.
.NET
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.
Honestly I feel the rates for all software devs have gone down from a year ago which I am sure has something to do with the massive layoffs from the big companies.
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.
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.
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.
"My 20 Year Career is Technical Debt or Deprecated" https://news.ycombinator.com/item?id=35955336
Html, css and javascript will be useful forever. As will basic computer science, architecture and so on.
> 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.
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.