Ask HN: How do you keep up with the ever-changing tech stack?
25 comments
Like other people have said, I don't keep up. Let tech change in the background while you just work on your current projects. When you start something new, take a glance around and see if anything new looks promising, and if so, learn it. Otherwise, just keep doing what you know.
Let other people worry about testing out all the new nonsense. I go with stuff that’s pretty mature and stable, with the goal of being able to use it for at least a decade. If something isn’t going to stick around that long, it’s really not worth my time.
Just because something exists, doesn’t mean you need to use it. Python exists, along with Flask and various other frameworks. Those will likely be around for 10+ more years, but if you’re already working in .Net, like it, and it solves all your problems… who cares that Python exists.
These are all just tools. If I have no use for a lathe, I’m not going to go out, buy a lathe, and learn how to use it. It’s a waste of time. Even if I think they are cool, if I don’t have a reason for it, bringing it into my life would add stress and nothing more.
Just because something exists, doesn’t mean you need to use it. Python exists, along with Flask and various other frameworks. Those will likely be around for 10+ more years, but if you’re already working in .Net, like it, and it solves all your problems… who cares that Python exists.
These are all just tools. If I have no use for a lathe, I’m not going to go out, buy a lathe, and learn how to use it. It’s a waste of time. Even if I think they are cool, if I don’t have a reason for it, bringing it into my life would add stress and nothing more.
I just commit to technologies for long periods of time. I suspect there are very few new frameworks or technologies you've had to move too in recent years or that have provided enough of an improvement over your existing ones to make sense.
The idea of chasing the bleeding edge of tech is a choice. You don't need to make it.
The idea of chasing the bleeding edge of tech is a choice. You don't need to make it.
Unfortunately not a choice as an app developer. iOS and Android will deprecate and remove anything you build every other year if it's not up to date.
You don't have to change tech stacks every other year for app development.
Groovy is being replaced with kotlin DSL
KAPT being replaced with KSP (which breaks a whole bunch of stacks)
We get emails saying hey, you gotta make this change in a few months or we'll be delisting you.
Most of the popular libraries end up being replaced with bits and pieces of Google Jetpack. This is a lot softer, but we've spent weeks just updating dependencies because it breaks things in chains. We've had hours long pair programming sessions trying to debug some abstract error message. You can't replace a small piece, taking one out makes it collapse in strange ways.
The moral is don't expect Google to keep anything consistent (except Gmail I guess). But it also makes for decent job security.
KAPT being replaced with KSP (which breaks a whole bunch of stacks)
We get emails saying hey, you gotta make this change in a few months or we'll be delisting you.
Most of the popular libraries end up being replaced with bits and pieces of Google Jetpack. This is a lot softer, but we've spent weeks just updating dependencies because it breaks things in chains. We've had hours long pair programming sessions trying to debug some abstract error message. You can't replace a small piece, taking one out makes it collapse in strange ways.
The moral is don't expect Google to keep anything consistent (except Gmail I guess). But it also makes for decent job security.
From what I read of the OP they were talking about JS frameworks so it'd be like having to go from Java to Kotlin to Flutter to react mobile every few months not just updating libraries which is annoying but has continuity.
Care about the problem, not the solution.
If some framework solves a problem that you don't have, then you don't need to worry about the framework.
If some framework solves a problem that you don't have, then you don't need to worry about the framework.
I don’t keep up. When someone asks why some memory corruption happened, I can participate. When we are dealing with performance issues, I raise my hand. OOM? I can take a look. Slow SQL queries? I’m your guy.
An issue with React hooks? I don’t know man. Something wrong with the Jakarta annotations? Uff, ask Joe. Your graphql thingy is not working? I can give you a hand, but I’m clueless.
So, people around me value my knowledge about the former stuff. Nobody really cares about the latter (because deep down everybody knows that that stuff will die anyway in a few years)
So, people around me value my knowledge about the former stuff. Nobody really cares about the latter (because deep down everybody knows that that stuff will die anyway in a few years)
Wait 5 years. After 5 years of the hype cycle the rough edges are sanded off, or the concept has ceased to be relevant.
You could have built most (web) things in the past 20 years with Java and a SQL database. It's worth keeping an open mind to what useful things might come out of a new trend but give it some time to avoid chasing fads like Web3, NFTs, NoSQL, Microservices or LLMs.
(This is not to say any of these are entirely useless in every scenario but the useful parts will have stood the test of time and the rest is for 'thought leaders' and con artists)
You could have built most (web) things in the past 20 years with Java and a SQL database. It's worth keeping an open mind to what useful things might come out of a new trend but give it some time to avoid chasing fads like Web3, NFTs, NoSQL, Microservices or LLMs.
(This is not to say any of these are entirely useless in every scenario but the useful parts will have stood the test of time and the rest is for 'thought leaders' and con artists)
The struggle is real! As a former full stack dev who transitioned into frontend only (and still have trouble keeping up), my suggestion on the frontend side is also (like everyone else is saying) to not chase everything. Just pick one of two (probably Next, because it's the most popular and heaviest) and just learn that well. The other frameworks are much simpler and can be picked up as necessary if an employer needs it. Many of them use JSX as well and copy the rest of Next's tool chain config (bundler, tester, Typescript, linter, etc.) So basically by learning Next and vanilla JS well, none of the rest should be too hard.
If you really have extra time, you can always build side projects (or even just the same prototype) in different frameworks to learn and compare. But honestly a lot of them will just die out before they see any substantial real world usage.
i wouldn't bother with most of them. They're just fashion trends. I think React and Next are the only sure bets in the JS/web frontend world right now. Learning the rest are bonuses.
If I had a lot of extra time, I'd probably learn Vue/Nuxt, SvelteKit, and HTMX/Alpine.
-----
What about on the backend? Back in my day it was mostly just Java, Rails, PHP, microservices, etc. These days there are so many container management systems (k8s? docker? some Google thing?). And entire new languages like Rust and Elixir. Not sure what to chase there either.
Is there a movement towards a heavy batteries included framework (like Next on the frontend)? Something like what Rails or Laravel/Symfony provided?
If you really have extra time, you can always build side projects (or even just the same prototype) in different frameworks to learn and compare. But honestly a lot of them will just die out before they see any substantial real world usage.
i wouldn't bother with most of them. They're just fashion trends. I think React and Next are the only sure bets in the JS/web frontend world right now. Learning the rest are bonuses.
If I had a lot of extra time, I'd probably learn Vue/Nuxt, SvelteKit, and HTMX/Alpine.
-----
What about on the backend? Back in my day it was mostly just Java, Rails, PHP, microservices, etc. These days there are so many container management systems (k8s? docker? some Google thing?). And entire new languages like Rust and Elixir. Not sure what to chase there either.
Is there a movement towards a heavy batteries included framework (like Next on the frontend)? Something like what Rails or Laravel/Symfony provided?
There's a rule I often ignore at my own peril: don't deploy version .0 of a software, ever. It needs 2-3 versions for all the bugs to be ironed out. Unless you like playing beta tester (which is a lot of fun sometimes).
Same goes for all these frameworks and tools. Let them mature a bit before you commit.
If you're worried about getting a job in the future, know that job posts are full of lies. They will ask for all and everything, even that obscure tool nobody is really using but showed up in some search a hiring manager did. Don't steer your career based on that alone.
Same goes for all these frameworks and tools. Let them mature a bit before you commit.
If you're worried about getting a job in the future, know that job posts are full of lies. They will ask for all and everything, even that obscure tool nobody is really using but showed up in some search a hiring manager did. Don't steer your career based on that alone.
I learned Django when I first started programming 13 years ago. It's still the best! And JS/CSS/HTML have only gotten better (Flexbox and Grid etc), and have done so in a backwards-compatible way. React's fundamentals haven't changed much in a decade either. Nor have SQL and the popular DBs (Sqlite, Postgres etc) So, I feel like as long as you ignore the hype frameworks, things haven't changed much.
Sounds like you need to carve out some regular time for learning - you are right, it is important to do continuous learning.
In terms of what to learn about, you could try an analytical approach and score technologies according to your criteria.
One criterion could be: does it have a good tutorial and documentation?
Replit and Stackblitz can help you try out new things.
Also, the learning effect is multiplied when you build an actual project: often this will influence what you need to learn.
In terms of what to learn about, you could try an analytical approach and score technologies according to your criteria.
One criterion could be: does it have a good tutorial and documentation?
Replit and Stackblitz can help you try out new things.
Also, the learning effect is multiplied when you build an actual project: often this will influence what you need to learn.
No one has the time to be an expert on everything. Learn a few things very well. Learn enough of about a dozen other things so that you can carry on a meaningful conversation in any of them. Peripherally Learn a few details about the rest so that you don't look like a deer in the headlights if someone mentions them in casual conversation.
Well I don't.
I've seen 2 people who cares about the stack more than the task itself. They lose their job way more often than average and is often criticized for not able to complete their task on time.
Some hiring managers tend you quiz you with framework details instead of your learning & reasoning ability. Avoid those teams.
I've seen 2 people who cares about the stack more than the task itself. They lose their job way more often than average and is often criticized for not able to complete their task on time.
Some hiring managers tend you quiz you with framework details instead of your learning & reasoning ability. Avoid those teams.
I read HN to stay informed. I sometimes try new stuff but mostly ignore it. Many times in my career, I had to learn those new shiny things. And you know what? Learning is fun, and if you do it on your day job and have a real task, it's very fast to get into new stuff.
As per @sanswork's sibling comment, I'd suggest avoiding the issue. The frenzied cycles of web front-end frameworks in particular seem pathological. I made a recent decision to look for a 'boring' technology, landing on Golang. I want something I can rely on for the long term.
I'll jump on the don't bandwagon. I've been using Express, React, and SQL for a decade. I don't see any reason to change anything.
I just read a post about a solo developer who has a $1.3 million business. It runs on Java and jQuery.
I just read a post about a solo developer who has a $1.3 million business. It runs on Java and jQuery.
I’m basically in the same boat with Rails.
I’ll learn a new stack when I switch jobs and they use a new stack.
I’ll learn a new stack when I switch jobs and they use a new stack.
I try to give 30 minutes of time exploring what's new. But I learn new stack way later when I actually need to used in my project (and I vaguely recall reading about it somewhere).
Focusing on databases and SQL has worked well for the last 40 years.
The new frameworks and tools are akin to screwdrivers with different handles. They accomplish the same thing in the end. You don't have to keep up with it out of necessity.
Be like me, I still carve onto clay tablets
I'm a full-stack developer and recently I've been feeling a bit overwhelmed. The tech stack is constantly evolving with new frameworks and tools emerging all the time. I often feel like I can't keep up and I'm not sure how to choose and learn new technologies. At the same time, I have existing projects that need maintenance, and there's never enough time.
So, I'm seeking advice from the community: as a developer, how do you balance learning new technologies while maintaining proficiency in your current skills? How do you decide whether to invest time in learning a new framework or tool? Are there any resources or methods that help you efficiently learn and apply new technologies?
Thank you very much for your suggestions and insights!