As a software engineer, the world seems to be moving even faster with new languages and frameworks popping up every year to add to the hundreds already available. It's hard to even think about all of the open source plugins and libraries out there, especially for the more popular platforms on Ruby (Rails), Python (Django), PHP, C#, and Java. The count must be in the millions by now. The C# .NET framework and Java class libraries alone are too huge for any single developer to even hope to know what's all in them.
The Pace of Progress
What's a developer to do? How can we claim to be experts without knowing everything there is to know about our chosen profession? Of course, this is a fool's errand. No one can possibly know everything there is to know even about a small slice of our world. If you tried, you would spend all of your time studying the next thing to come out and the next thing and the next, and there would be no time leftover to actually get anything done.
So what about the other extreme? Could you learn just enough to get by and then stick with that knowledge for the rest of your career? Pick up some PHP, HTML, and CSS, and bang out websites for the rest of your days. Or learn some C and write embedded software until you retire. There are certainly people that do that, but it seems awfully risky to me. As the technologies move forward and get replaced, you'll be more and more likely to get replaced yourself, or at least look less and less productive as other developers pass you by with more efficient knowledge and skills.
Those are only a few of the major changes that have happened in the last ten years, and the software industry is showing no signs of slowing down. Suffice it to say, letting your skills stagnate is not a good plan. There must be a happy medium between drowning in new technology and refusing to even get your feet wet. The trick is to figure out just how deep you can go so that you can swim at a smooth pace without getting exhausted.
Scott Berkun brought up an interesting theory about information that starts to get at what we're talking about here:
One popular theory about our universe is that there is a fixed amount of matter in it. All that changes over time is the state and position of particular atoms. ... The net information in the universe might be fixed.If we think about potential knowledge as a vast, effectively infinite sea of information, then we will never learn even a small part of it in our lifetimes. At first that may sound depressing, but really, it's liberating. You don't have to learn everything because it's impossible. If you try, you will most certainly fail! Once you accept that you won't ever know everything, it's much easier to see what you should learn.
...We are compulsive information hoarders. We still pretend information is scarce. It isn’t. It never was. Even if you limit it to human produced information, for the last few centuries if you could read and had a nearby library, you had several lifetimes of information available to you.
Learn the stuff that matters to you and that interests you. Learn enough new stuff to keep being more productive, but also learn the right new stuff so that your newly developed skills don't become immediately obsolete. As an example, when Rails was first released in July of 2004, a lot of people thought it was hot and shiny and a great paradigm shift from how websites had previously been built. But it was changing fast. Today Rails is sitting at version 4.0.4, and it is a completely different animal than when it was released almost a decade ago.
Rails has certainly improved in any number of ways over the years, but the fact remains that if you picked it up when it was fresh, you had to learn about all of the changes that went into it to keep up. If you were actively developing websites and Rails drastically improved your productivity even in its infancy, then that may have been the right choice. If you're starting out with web development today and learning Rails, you don't have to learn all of that legacy stuff. You can pick up the current thread of development and run with it.
So there are tradeoffs to diving into a new technology. When you're on the cutting edge, there's more risk of learning stuff that won't achieve wide adoption, and the stuff you learn will be changing constantly. But if you're learning new ways of solving problems, that knowledge could benefit you even if you don't use what you learned directly, and you may still be able to put what you learn into practice to get real work done faster right now.
Filtering Out The Noise
Rails is just one example of a new technology, and when it was released it was far from certain that it would be as successful as it is. If you follow software technology, you know that new frameworks, libraries, languages, and tools are released all the time. On Hacker News alone, you're practically guaranteed to see at least one of those four things on the front page anytime you look. How do we deal with this deluge of information? There's an awful lot of noise out there.
First, know that there are many ways to do something in programming, and no single right way, just more efficient and less efficient ways. Let that sink in for a minute. There is no single right way to solve a programming problem. There is the way you would currently solve it. Then there are worse ways to solve it and there are better ways to solve it.
Programming languages in particular can show you different ways of solving the same problem. For any given language, you have to figure out how to build a solution to your problem most efficiently within the confines of that language's features. You're going to solve any given problem much differently in a functional language than you would in an object-oriented language. The problem may map more directly to one paradigm than another, and knowing more languages dramatically expands your toolset for solving these problems.
Second, be self-aware. Know your development pain points. Those are the areas of software development that constantly irritate you or that make you feel like there's a gap in your knowledge. If you ever find yourself throwing your hands in the air and yelling, "This is stupid! There has got to be a better way!" That's a pain point. Make a note of it. It could also be something more subtle, like being aware that you should really look into that new functional language or unit testing or (gasp) version control. You've heard whispers of them being kind of important, and you're curious. Add them to the list.
Finally, carve out some time to learn something from your list. Pick something easy and fun to start with, but pick something and start learning it. There are a ton of different ways to learn new software development stuff, so you need to find the best way for you. Once you've finished with one item, it may naturally lead to another so keep following the thread. Otherwise, go back and pick something else off the list. Each time it will get easier, so you can start tackling harder topics. The important thing is to be consistent about it. Set a little time aside to learn every day if you can, but at least once a week if you must.
It may feel like wasted time at first, like you're not being productive because you're not actually getting stuff done. Don't let it get to you. Even if you're spending 10%-20% of your free time learning, if you're putting what you learn into practice and making yourself 50% more productive, that's a huge win. On top of that, the time invested in learning is a constant cost, but the benefits accrue exponentially. There really is no limit to how much you can improve if you keep learning.