[grovegames]

Honestly, trying to stay current on all the new technologies is causing me anxiety. After 20+ years at this, I always felt I was one step behind. But now I feel I'm 3 steps behind. I can't imagine what it's like to be a developer with a wife and kids. I just couldn't' stay on top of half what I'm able to do now.

[ryandrake]

In my view there is almost no reason to stay on the Language/Framework Of The Month treadmill. If you were capable of learning language X, you're capable of learning language Y if you need to or just want to. Think for a moment: Why do you think you need to learn all the new technologies? Is it because you just love learning? If so, there's no reason for anxiety--learn at your own pace.

Is it so you can remain employable in tech? In my experience, good companies are looking for those "T-shaped" people: deep experience in one or two broadly defined domains, plus some experience across domains. You generally don't need to go deep in one particular language/framework combination. If you are good at, say, Javascript, and a company actually won't hire you just because you don't know React, well, trust me--you really don't want to work there. They are looking for a cog, not a creator.

Here's my totally anecdotal advice: Pick three or four resume keywords to go "deep knowledge" on in your career, and you'll probably be fine. Early in my career I happened to pick "cross platform" and "graphics SW". Mid way through I added "iOS" and "GPS/mapping SW". Well, I'm in my 40s and still going, so it turned out alright. Notice I did not specify any particular language or framework there: I have my favorites but I don't consider a particular language or a particular SDK to be that important in the long run. I have never really experienced this language anxiety. It doesn't matter.

[flavio81]

Take a rest my friend. You don't need to stay current on all the new technologies, just to be aware of them. And most of those are basically easier-to-use or more-popular versions of things already existing in the past. The things that are truly new in our discipline, arrive slowly.

[GoToRO]

Relax. I've seen code written with/for the newest technologies and it's mostly crap. Just like you don't have time to learn it, most people don't. But everybody is happy, including the client, because they have this new tool written in the newest technology so it must be good. People evaluate software just like they evaluate cars: they take a good look at the paint job and declare that this car is good, while in reality the seller only took care of the paint job, the engine is dead.

[Bahamut]

People often think new tech is a cure for their woes, such as poor code quality - often it is just papering over the real problems & barriers.

[SomeStupidPoint]

I've also seen tech switches used to mask rewrites, because they could sell management on the idea that $NEW_THING would solve our woes when what we really needed was just to spend half a year refactoring the legacy system (regardless of language), but half a year to redo work didn't fly.

[GoToRO]

Now that you mentioned it, I think this is the most common case.

[hzhou321]

> But now I feel I'm 3 steps behind.

Every time I see a new technology come and go, I feel myself was 3 steps ahead :).

[taneq]

Sooner or later you see the next wave and think "that doesn't seem worth the investment." And you skip that wave and the world doesn't end, and chances are the fad falls into irrelevance like 90% of other fads. And gets replaced by another fad which is basically the same with a bit of window dressing, and you realise the good concepts will stick around and the rest wasn't worth wasting your time on.

So you pick tools that work for you and are appropriate for the task at hand, and you get the job done, and you leave the fad chasing to the kids, because you've got better things to do.

[marcosdumay]

Take a good look at any new stuff to determine what it is good for (if there's any). Keep your results in mind, and go back to your old stuff.

Then, if you have a problem that can be solved by the new stuff, go and learn it, otherwise why bother?

Honestly I don't see that huge influx of novelty people keep claiming is here. Yes, specialized knowledge is advancing rapidly, but mainstream tools are quite stagnant. (E.g. I'm avoiding learning how to script Docker for near a decade already.) It may be a matter of changing your focus from products into technologies (what does require deeply learning a few techs).

[dozzie]

> (E.g. I'm avoiding learning how to script Docker for near a decade already.)

Quite an accomplishment, given that Docker is four years old. You're twice as effective in not using Docker as me.

[nuclx]

Avoiding Docker as well like I avoided Ruby and mocking frameworks. Some things just don't feel right.

[marcosdumay]

What? I remember reevaluating it so many times. Was there some other famous container product before it?

[dozzie]

Well, four years is what Wikipedia states.

I don't think there was anything as prominent as Docker on cgroups that was as old as ten years, since cgroups are that old. LXC was started eight years ago, and then Docker hijacked the subsystem and nomenclature.

But maybe you were thinking about some predecessor, like Virtuozzo/OpenVZ or Linux VServer? Those were never as popular in general public as Docker, but they had their mindshare, especially in some circles.

[brightball]

Hi! waves

Developer with a wife and kids here,

You pick your battles and as you age you determine what's actually a priority to learn as well as developing a system to filter out what's not.

In terms of languages, I made the decision about 5-6 years ago that I was going to stop bothering to look at languages unless they solved a problem that I couldn't solve easily in another language. I tend to refer to these languages as "Flavors of C" since they all basically do the same thing.

At the time I decided that, I already had a good bit of experience with Java, Groovy, Perl, PHP and Ruby. As it turned out, it's been a good filter and the only two languages that I've actually felt the need to learn in the last 5-6 years have been Elixir and Go...and Go was largely because it's getting used at work. Elixir is the only one I've actually dedicated my spare time too and that's because once I dipped my toe in the water I got a little bit obsessed (because it's IMHO, the 42 of programming languages for my use cases).

You generally do the same thing with the devops and peripheral side of things too.

I used to manage my own servers in my spare time to learn, but I just don't have the time to spare for it. I stay on top of things related to my job at work, but in my spare time I just use Heroku because the $7 / month is worth it even though I'm sitting on a lot of digital ocean credit.

In terms of databases, after I went deep on Postgres with one project and realized that it basically addresses every problem I've ever encountered (personally) with a database that I just don't feel any need to learn another unless I get to an extreme niche scaling scenario where it actually might leave something to be desired.

I've entirely avoided the Javascript framework-of-the-week stuff. If I had to choose one to learn, just based purely on observation I'd probably go with React since it seems to be the most stable-ish environment but I'd be lying if I said I didn't see some real appeal from Elm too. You'll notice a pattern that when people keep trying to solve the same problem a different way, that there is probably an underlying issue as a contributing factor. Plus, 99% of web apps just don't need to be SPAs.

You just pick your battles. You stop learning technology in search of a problem and start focussing on technology that actually solves your problems.

Elixir-Phoenix-PostgreSQL is, in my opinion, the 99% solution and when you have a toolset that addresses so many concerns so well, the only time you'll find yourself looking for more solutions is in the gaps.

The fewer gaps, the less you'll feel the need to fill them.