New technologies surface for a reason. Usually that reason is because they are more efficient or powerful at accomplishing a particular task.

There is still value to be had in sticking with old technology for the sake of legacy systems, but when they eventually reach their end of life you’ll be behind the game.

Business reasons aside, constantly learning new technologies keeps you on your toes and will open your eyes to different ways of approaching tasks, even in old technologies and so on, so forth.

Although it is certainly possible to build a career on a single technology stack if you get lucky¹, it is a near certainty that the technology is going to change more than once during the time when you are gainfully employed. You can (and you should) get better at what you already know, but learning new things ahead of time will help you cut down on the learning curve when the next technology shift comes to your corner of the industry.

There is a less apparent side to it, too: learning new things very often help you see the things that you already know from a different perspective, in the same way that learning a new language helps you learn more things about your current language².

Finally, a pure entertainment value of learning new things should not be underestimated: to me, it beats watching TV hands down.

¹For example, by picking COBOL over PL/I at the start of your career in 1965.

²This works for natural and programming languages alike.

Can’t we just stick with what we know and become better with it?

You can, but it’s really easy to fall into the trap of never wanting to learn anything new. Your job prospects dwindle, your teammates stop wanting to work with you because you’re “that programmer who’s completely out of touch”.

Mostly, you need to keep a balance. Trying to learn everything new all the time is going to lead you to be poor at many things, perceived as a flighty tinkerer. Learn a few things well, and focus at least on knowing what exists, even if you can’t use it effectively.

Well it’s probably due to the fact that you’re a web developer and the technologies in that field are very volatile with languages, platforms, tools, and methodologies rising and falling in popularity. It’s a field that is very VERY high level. If any of the layers beneath it are altered, that changes the position on top. And, frankly, it’s new (ish). New fields have a lot of room for innovation.

Personally, I work on embedded devices, learned C, and that’s worked pretty well for me.

But I’m still learning new things on a fairly regular basis. Sockets, SQL libraries, ncurses, objects in C. And methodologies are loosely coupled with technologies. Unit testing was taught horribly at my school, and I’m just now wrapping my head around it. I just heard about dependency injection the other day, and realized that’s exactly how I solved my last problem with unit testing a console function.

Most programmers aren’t factory workers that do the same thing every day. Those jobs can (and should) be automated away. Nobody pays for yet another bubble-sort implementation. It’s been done.

I’d say you can ignore a lot of what’s out there. Much of it is hype and fad and new names for old technology. The real advances will soon be replaced by even newer ones that don’t really depend on the old ones, even though the old timers say you ought to understand the old ones to understand the new. If you left the field for 10 years, when you came back you’d only be 2 years behind.

That said, spotting the real new technogy can be tricky. I’m glad I didn’t miss OOP, but it sure looked like just a handful of buzz words at first. And you often need to use current technology to do a job, even if everyone will have forgotten it in 3 years.

The software technology hype and confusion multiplies the change we have to deal with day-to-day. But electronic technology actually is advancing rapidly, and pushing software along with it. There’s a lot of real change out there. We’re still driving the cars, flying the planes, and going into space with the same vehicles we used in 1965. But the electronic hardware from 1995 is hopelessly obsolete.

So the deep answer to your question is that the scientists and engineers working with electricity have been very busy. The software needs to evolve to take advantage of the hardware. Worse (or rather–better?), I think the software’s been left way behind by the hardware. If the hardware people all retired tomorrow, software would evolve furiously for the next two decades at least.

If you need the new technology to do a job, you need to learn it. If there’s a chance it’s a new technology that will still be here 20 years from now, you need to keep an eye on it–and if you watch 20 techs that die for every one that lives, you’re doing pretty good. And you actually can ignore everything else. Except for that one bit of obvious smoke that will underlie all the software of the 2020’s.

IMHO, you need to find a balance. That takes skill and experience.

You need to find one or two languages you specialize in, keep up to date in framework/style changes that evolve in this language, and keep your skills top-notch.

But you also have to see how this language evolves, and understand the dynamics of software development as a whole. Will Java be around in 10 years, is Phyton there to stay, is PHP going to be replaced with .NET and Mono?

These are large scale, strategic questions, answers to which will let you become highly valued professional in your field, while having some solid backup (1 or 2 languages) and knowing when to move on from your main platform.

IMHO, following all the modern languages that are being developed every day is one of the biggest problems for the whole industry. We have ton of undeveloped, dead-end languages with almost no professionals in them, and people who waste time on them are rarely real professionals in even 1 language. Mostly they write code that’s mix of all languages and does nothing right. At the same time, amount of man-years that’s wasted on these nonstandard languages could be spent on improving few core language frameworks and specs.

As others have pointed out, many new technologies emerge to address new needs and therefore they make it easier to solve certain problems. Therefore you should keep up to date and at least know what is going in your field and understand which new technologies are relevant for you.

On the other hand, I think that sometimes there is also a hype factor in certain innovations: Some ideas are extremely old but only in recent years they are being pushed to become mainstream. Sometimes I have the impression that a new programming language (or a new version thereof) is pushed just because “new is better” and a new technology means new books, new programming tools, new compilers, new programming courses, or in other words, revenue.

So it can happen that you have to learn a new technology without seeing any real advantage wrt the technology you had been using before, otherwise you risk to be out of the market because your skills look old fashioned.
It is up to you to follow the development of new technologies and try to understand which ones can make you more productive, and which ones are just convenient to make your CV look better.

Bottom line: I think you should try to learn what you really find useful, regardless of whether it is new or old.

Because “sticking with what you know” represents a failure to “get better at it.” You don’t have to adopt every new practice and framework that comes along but you should at least have an informed opinion on the popular ones. In web development just asking the question would look horrible to an interviewer. Web dev is littered with the career-corpses of people who wanted to stop learning new stuff after 2000 and that’s as it should be because they make more work for the rest of us. Stay away from dev if it doesn’t interest you. It’s a lousy $/hour ratio if the part where you learn new stuff feels like work.