Ask HN: Anyone else feel like their whole career will just be tech debt?

[erlich]

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.

[devonbleak]

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.

[ActorNightly]

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.

[clncy]

“In the land of the blind, the one-eyed man is King”

[steve_adams_86]

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.

[JohnFen]

Your comment is wonderful, and I agree.

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.

[garethsprice]

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.

[JohnFen]

> There's still a bunch of folks in their 70s employed writing COBOL

Just to underline this, I know devs in their 20s who became proficient in COBOL because an expert COBOL programmer can make crazy money.

[VygmraMGVl]

I know a dev fresh out of college who became proficient in COBOL, got a govt job offer, and now is working as a lifeguard because places that hire COBOL programmers take forever to process their paperwork. Presumably he'll start his real job in late summer when they get their act together.

[spratzt]

Really!!

All the jobs I’ve seen for COBOL programmers paid atrociously bad rates.

[fm2606]

I don't know if I would call it "atrociously" bad rates but a quick scan of Cobol listings on Indeed somewhere between $90K and $110K. I'm sure there are outliers on both sides.

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.

[JohnFen]

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

[softwaredoug]

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

[firebones]

It is certainly worsened by the period of zero interest rates, which fueled a massive viral outbreak of promotion-driven development cultures among most of the largest tech employers. Recent mass layoffs in tech really aren't an antibody--the marauding bands simply reconstitute and find other hosts to infect and value to destroy. It will take a decade for that boom to unwind with a lot of carnage along the way. /remindme 10 years

[marginalia_nu]

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

[thesnide]

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.

[Mizoguchi]

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.

[poorbutdebtfree]

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.

[dcminter]

In 2003 I was mostly doing Java. In 2013 I was mostly doing Java. In 2023 I'm mostly doing Java.

YMMV.

[ineedausername]

Don't wanna dissapoint u, but 2033 will probably be the same :)

Java and it's eco isn't going away this century.

[dcminter]

Hey, that's not my idea of disappointment; I rather like it :)

[imtringued]

JSF is still haunting me.

[DarrenDev]

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.

[kiawe_fire]

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.

[wry_discontent]

I have the opposite problem. Most business software is boring as hell, and I just want to have something cool to work with.

[JohnFen]

This is why I've never stopped programming as a hobby. My professional work is to get me a paycheck. My hobby work is to get me happiness and fulfillment.

[imtringued]

The problem isn't necessarily that it is boring but rather that we don't understand the impact of boring software.

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.

[wry_discontent]

I didn't say pointless. I said boring.

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.

[kiawe_fire]

I hear that.

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.

[rleigh]

I have seen this repeatedly over the years. It's frustrated me personally many times.

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.

[rleigh]

This is one of the reasons I moved into embedded software. It's much more satisfying for me personally. But even when I worked on business software, it was nice once in a while to go out an meet the actual customers who used the stuff day-in day-out. I learned a lot from them, and took it back to improve things, and that made it quite a bit more interesting, knowing I was addressing real usability and functionality problems which would improve their job.

[dustymcp]

Im in a startup sometimes i long for the boring stuff :P

[time0ut]

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.

[austin-cheney]

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

[Solvency]

How does that explain the other contrarian phenomenon of developers hating to use existing code from elsewhere and preferring to reinvent their own wheel or polygonally-shaped solution to an existing problem?

[austin-cheney]

I am the only developer I have ever encountered that even vaguely fits that Not Invented Here description, and I have been doing this for almost 20 years. This might have been more common decades ago but now the opposite is far more common. With things like Maven and NPM nobody in the corporate world writes original software anymore. The emotional insecurity is too high and leadership is too absent for modern developers to write original software.

[jml7c5]

This recent submission seems tailor-made for you:

"My 20 Year Career is Technical Debt or Deprecated" https://news.ycombinator.com/item?id=35955336

[berkeshire]

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.

[ramesh31]

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

[tayo42]

It feels impossible to switch into that though.

People really pigeon hole you into whatever you already did.

[dhbradshaw]

The judo move for that is to use that tendency for your benefit.

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.

[HeyLaughingBoy]

> I just want to have one stack and master it.

.NET

[more_corn]

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.

[ftxbro]

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

[aigoochamna]

Learn and master fundamentals and not technologies.

Html, css and javascript will be useful forever. As will basic computer science, architecture and so on.

[moomoo11]

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.

[chiro-hiro]

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.

[ftxbro]

every line of code is tech debt its tech debt all the way down

[roland35]

Forgot tech debt, most of the projects I have worked on have been outright cancelled!

[aprdm]

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

[incogitor]

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.

[deterministic]

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.

[web3-is-a-scam]

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.

[namaria]

Venetian traders figured out 800 years ago something that would benefit programmers to learn as well: debt is just the mirror image of credit. Everything has a trade-off, there is no free lunch, thermodynamics and whatnot. Every asset has to be maintained.

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.

[slavapestov]

Learn math, it will never become obsolete.

[ironmagma]

Java and C++ aren't going anywhere.

[stcroixx]

You’re saying you didn’t bet on Java.

[metaltyphoon]

Or .NET

[eimrine]

Or Lisp.

[eimrine]

What are complains to React, just slow running or anything else?

[imtringued]

Other than react hooks I don't see the problem with react either. It is about as standard as jQuery. If anything it brought an end to the 3 year or less JS framework lifecycle.

[shimzs]

like to over come the hitman

[hindsightbias]

We used to have this debate about X11 versions thirty years ago. UI's were a mistake.

OSS and stability do not mix.

[thinking001001]

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.