[thegeomaster]

I'm not even legally an adult, and I feel like things are moving too fast for me. At 17 years. I guess I shouldn't feel like that, but I can't help it.

I started with VB6 as a kid, 6 years ago. I moved onto C++, then learned about 3D graphics and game engines, then learned HTML, CSS, JavaScript, gotten into web development, learned Photoshop, some basic design, working with Linux, PHP, a little of C#. Recently tinkered with MongoDB. Now I'm learning Common Lisp, but I feel I've missed so much, and slowly losing pace.

All those frameworks, Angular, Ember, intimidate me. ZeroMQ. RabbitMQ. AWS, EC2. "Big data". Swift, Dart, even Python and Ruby. Responsive design. Scala. Backbone.js, underscore.js, Node, NPM. Neural networks. How do those things work?

I'm freaking out a little, not even sure if I should continue pursuing this. I so love coding and new challenges, but I just fear it's moving too fast for me and one day I simply won't be relevant anymore. I take a look at HN's front page, and I don't recognize so many technologies mentioned in the titles of articles.

And I'm feeling like one day it'll go over the top, I won't be able to keep up anymore (and I can barely keep up even now), and I'll just quit and go learn play drums. It would be heartbreaking for me, but I'm not even sure if computers are the right thing for me in the long term.

So I understand this post, from the bottom of my heart. And there's this anxiety creeping up about it. Who knows if I'll still be able to do this in 10 or 20 years? And finding another craft which I love so much is also a scary task. I think I might never do.

[rayiner]

Relax.

One of the lovely things about being older is having the confidence to be able to be able to point out that the latest fad is just a warmed-over rehash of something old.

It's important to keep up with the new things, but the fact of the matter is that there is very little in the world of software development that's actually new. Swift? Please. If you know ML (1970's), Smalltalk (1980), and Objective-C (1983), you know 95% of what there is to know about Swift. If you know Smalltalk, you know about 90% of what you need to about Java, and with those two, you know 98% of what you need to about Dart.

Learn the big important things, focus on principles rather than specific implementations, and you'll realize that there's very little new under the sun. At this age, while your brain is still limber, learn as much mathematics and theory as you can. You will probably not use Dart 10 years from now. You can bet you'll use the knowledge you picked up in your combinatorics or algorithms courses.

[sriku]

> One of the lovely things about being older is having the confidence to be able to be able to point out that the latest fad is just a warmed-over rehash of something old.

Sane advice. I'm 39, and I'm rather stunned to see 27yr olds calling themselves "old" and disillusioned with tech and what not ... let alone 17!

If you like to build things, hone your system level thinking .. which lasts longer than Angular/Backbone/whatever. (Heck I'm working with the intention of obsoleting them, based on old Smalltalk ideas!) If you like to build things the possibility of which average society has no idea of, hone your algorithmic thinking. I'm certainly more productive today than I was, say, a decade ago because I chose to focus on the ideas rather than specific tools during that time. I'm confident I can work with any tool at hand due to exactly what rayiner says. Good debugging skills, for example, don't die because you need to approach it scientifically.

rayiner - while you're right about the "if you know .." part, many companies today ask for specific skills and hirers don't know enough to say "we need guys to work on a Java code base, you know Smalltalk, you can handle it, hop onboard". So it is up to us tech folks who give these job specifications to hint at the broader kind of people we can accept.

[rayiner]

With regards to your last point: it's also up to job seekers and employees to signal to organizations that they need to take professional development seriously. You have to fight the pressure to over-specialize and demand opportunities to learn new tools and techniques. There's a basic conflict of interest here between employer and employee: the employer wants a highly specialized cog they can replace when their needs change. The employee wants to develop a speciality, but also build a general base of skills and dabble in new technologies so he can stay employable for years down the road. Employees need to fight for their interest in this regard, and employers need to have the foresight to realize that the most talented people who have the most options will not take a job at a place that stifles their professional development.

[TheOtherHobbes]

I'm in my 50s, and I'm having a ton of fun with this new stuff.

After burning out at a startup that did everything in 68000 assembler (nice architecture...) in my 20s I'm getting back to dev work now and finding I still have aptitude and curiosity.

There is a lot happening. But the change has barely has started yet. I can see hints of new shapes coming over the horizon, and anyone who thinks they're going to be needing the same skills ten years from now is fooling themselves.

Imperative and functional styles have been around for decades already, it's true there's a lot of pointless reinvention (at worst) and refinement (at best) happening.

But very different things will start happening within the decade. IMO the fallout after the bootstrapping will be like nothing anyone has seen before.

[sriku]

The ability to think clearly and critically is certainly something I don't expect to be obsoleted in a decade. I do expect what I think about and think with to change though. Maintaining a curiosity about new ideas and how they relate to the old ones is a healthy trait to have that will help one survive such change.

Wolfram Language certainly looks like an interesting and somewhat new take on building systems using advanced computation. For those who're continuously curious about genuinely new ideas (not just rehashes) it will not be "nothing anyone has seen before" when it (whatever it is) finally happens. To them, it will be more like "hey, it's cool that this idea I've been dabbling with for the past 5 years is pretty powerful and feasible to use today, yippie!"

Minor ex: I had two Haskell "aha" moments - one around 1997 and one around 2000. The former was exposure to Haskore which offered a neat design that clearly illustrated the "separation of concerns" design principle. The second one was when I implemented an algorithm in Haskell in 4 hours and it worked like a charm and was more general than some C code for the same problem that I was hacking on for almost 2 weeks prior to that and which continued to be buggy. The language made a difference to how I thought about the problem, taking away many of the low level concerns. Back then, for the cases the C code worked, the Haskell code ran 60x slower. Today, Haskell is blazing fast compared to those years and pretty viable for just about anything. Yippie!

[visarga]

I think Machine Learning will become much more common place. It's a radically different approach.

[antjanus]

I definitely agree with you on this point. A lot of the "new stuff" is just a rehash of the old or a new implementation in a different language of something that's been around for forever.

I'd say the front-end MV* stuff is a great example of this. I started out with KnockoutJS a few years ago and that's all but dead by now. Was it a waste? No, not really. It was pretty easy to go from Knockout into Angular. Sure, some concepts are different, but the ideas are the same. Moving on from that, I picked up VueJS pretty quickly and after tinkering with its Component-based example, I saw that it's pretty much almost the same as Polymer. BAM! All of these frameworks wrapped up in a nice package.

And what's behind it all? An idea. The concepts behind all of these are the same. Same goes for working with PHP vs Ruby, same concepts, different syntax, slightly different ecosystem. NodeJS (as much as I love to say how amazing and different it is), is pretty much the same as Ruby and PHP and Python except for its damned callbacks.

And then there are things like underscore (which is pretty much an array manipulation library), and backbone (which is just a library that gives you the MVC of javascript) etc.

All of it old concepts, and all of the similar libraries work very similarly. There's no need to relearn everything from scratch once you get the patterns and concepts down.

[monksy]

Just wait till you look for a new job, and it happens to be at a startup. The more mature companies tend to be a little slower at adopting new technologies.

In my situation I've been in the Enterprise/automation world. Which is a little bit behind. [Ok a lot.. but you work with what you can and what works within the requirements] ... you'll get the "you're not the right skillset" when the new organization is using *js, nosql dbs, and the FB APIs etc. That's rather odd when you've been developing for more than 10 years and have shown that you can learn new technologies.

I'm completely in agreement with you, however when it comes to a new position employers "don't want to risk you not knowing jquery 12"

[jared314]

You should be worried.

You are joining a pop culture that measures, judges, and hires people by how much they know about the current pop culture. Worse yet, everyone who tries to escape this conformity appears to just switch to a different conformity (OOP programmers switching to FP. Emacs users switching to SublimeText. Javascript people switching to Go. Programmers switching to Entrepreneurism. Etc.).

- Choose what not to learn (while being outwardly supportive of endless learning).

- Learn your excuse list for not understanding things now, and sit quietly while energetic people try to "convert" you.

- Choose what you actually want. (Many people are successful in unseen ways, and you never hear about them.)

- Know that you won't get it right the first time, but you will develop a feel for what to pay attention to after a few times around the hype cycle.

And, as always, keep learning.

[sage_joch]

"Choose what not to learn (while being outwardly supportive of endless learning)."

So that's why I didn't hear back from the (initially enthusiastic) Google recruiter.

(edit): I re-read the email thread and I think I was being unfair in the previous iteration of this comment. "See randomness" and all that.

[jared314]

You must keep in mind Google's perspective. They have a firehose of great candidates to choose from, requiring an assembly line of recruiters and interviewers to filter them. They could use any filtering method, no matter how inaccurate or impersonal, and still get a large group of great people.

[teddyknox]

I'm 20 and I've felt the same way. I just returned from a semester abroad and effectively took a 6 month break from all coding following my 7 years of continuous interest. When I came back to the states to start my summer programming job a few weeks ago, I was hit with a feeling of emptiness and mild depression. The reasons for this are likely tied up in my reverse-culture-shock, and the fact that I spent a majority of my time in India socializing and exploring. I came back to my home, to a job I was really looking forward to, and didn't find programming to be very fun.

To find traveling enjoyable and purposeful, you have to become a bit of an extrovert. My days were filled with interesting sights, sounds, smells, and people. I felt happy to have learned a bit more about the "real" world around me. Then I came home to a desk job, where I unenthusiastically wired up programming logic to produce results. A few days ago I realized the obvious reason why I was feeling down. I had planned my summer around my work, and I wasn't enjoying my work, because I was still searching for external reward. To enjoy programming again, I would have to dig deep and remember why I loved programming in the first place, and promote the introvert was suppressing in myself.

I told myself to forget that I'm working on a product that might not improve the lives of tons of people, or that my code might be obsolete by the end of the summer, or that outsiders find it hard to relate to stories of my progress at work. Instead I allowed myself to enjoy building cool stuff that would be mostly divorced from the physical world. It's worked pretty well for me so far. Reward is relative, nobody can tell you that you should find less reward in designing fascinating and complex sand castles in your mind than more normative tasks like socializing.

The takeaway I'm going for here is that if you're feeling burnt out, it might be because your motivations for programming have been messed up by social pressures since you started.

[Yhippa]

I don't know your wealth situation but one positive thing about our profession is that it provides us with the finances to travel and continue experiencing the things during your semester abroad. In my 20's, looking around, it was difficult finding people who had the vacation and money to travel abroad.

If you can make sure you realize that this is your job and take time to take advantage of your situation I feel it can justify the sadness you experience from our profession.

[wldlyinaccurate]

To see a young person say this bolsters my opinion that technology is moving too fast.

Everybody is in such a rush to learn new frameworks, new languages, new toolsets; nobody is learning how to actually _program_. I've worked with people who looked down on me for not knowing WeekOldFramework, but who couldn't architect a simple CRUD application to save their lives.

I feel like so many developers have this "quantity over quality" attitude about knowledge, and it's hurting the industry. With such shallow knowledge, we're doomed to never learn from history and forever write bad software.

Get off my lawn, etc.

[Ixiaus]

It isn't moving to fast. New library x is like going from PHP to Python, true holistic understanding and a grasp of theory goes a long way to enable someone to look past the superficial differences and focus on the substance - everything else falls into place.

It's also not about learning to Program, that's like saying to an adult that knows how to write, learn how to write! That doesn't improve their writing.

It's about thinking. Structured languages (like those used for programming) are Yet Another medium for translating Thought. Learn to think better, learn better tools that enable better thinking (Haskell, Idris, Mercury, etc...)

[GrinningFool]

HN is the worst possible place for you to spend your time.

A constant stream of new ideas - many of them not worth the bits they're stored as - punctuated by periodic tales of extreme success and extreme failure. It doesn't cover the in-betweens - yet the in-between is where 99% of the rest of the world's software developers live.

Someone like you, who had the natural drive and curiosity to start programming at 11 and dive into C++ sooner after, will never be obsolete.

Find what you like in the field. Learn it well. Accept that what you like may change and that you'll be inclined to learn something else down the road. Things that interest you today may not tomorrow; and things that seem out of reach today you may find coming to you as naturally as breathing tomorrow.

Most industry professionals don't chase after every new trend - we learn the fundamentals well, we pursue the things that interest us and let go of the things that don't. We even have time in our lives for things that aren't technology, yet we manage to progress in our careers as software engineers. (I would say making time for those things is critical to retaining your enjoyment of technology as you get older.)

My contact info is in my profile; feel free to shoot me a message if you want to talk further.

[mtct]

Stop follow hacker news and you will rapidly recover from this illness.

Source: Me, someone that see COBOL all day and still live happily after that.

[sien]

Exactly.

I work in a similar place. IMS and COBOL is all over the place.

Delphi is too. I maintain mostly C code written 20 years ago.

It pays better than any job I've had previously with up to date technology stacks.

A bunch of mates are Coldfusion coders. Now they are in demand because all these odd places have legacy CF code they have to deal with.

In 10 years time all over the place will be piles of Angular, Node & whatnot to maintain.

The pile just keeps getting bigger.

[visarga]

I loved Delphi 15 years ago. It was WISWIG, click on a button, write an event handler, drag and drop components, it even generated some boilerplate code for me. That was bliss. I learned how to do event driven UI's back then. Today I use jQuery much the same way, but without the nice RAD. Is there a Delphi-esque RAD for JavaScript?

[gordaco]

Calm down! Nobody in the industry knows everything about everything :). It's OK that you feel a little overwhelmed, because there is so much to learn. At your age, you can take your time, learn a little of everything, discover what is it that you like the most, and focus on it. And I'm referring to domains, not languages or techniques: if you're into web backends, there is not that much difference between, say, Python and Ruby, even if knowing both will make you appreciate the advantages and shortcomings of each one.

In the end, if you work steadily and know where to apply for a job, getting it is easier than it sounds (nobody's days have more than 24 hours, and if you started that early, chances are that you're quite better than your age's average). Just be aware that, with all that many languages, frameworks, etc. there will always be people (maybe even younger than you) that know more than you about some of them.

[ufmace]

I'm over 30, and been working in the industry for ~6 years now, and I say don't worry. Yeah, there's segments of the software world that push out new frameworks and languages at a breakneck pace that nobody could keep up with. There's no reason why you need to know them to work, though. The vast majority of developers out there are working in time-tested languages and frameworks. C++, C#, and Java for most of the enterprise and big business world. Most of the web work that uses any other language is Perl and PHP. There are jobs out there in the latest cool stuff, but they're a small fraction of the overall market. I haven't really worked with that side of the industry, but I'd have to guess that any company there knows that they aren't going to find many people on the market that already know their stack, and so will be open to teaching you.

Don't worry about trying to keep up with the latest stuff. Do pick a language and framework, and go build something in it. Make it do something useful and solve somebody's problems. A proven ability to execute on a business idea is worth far, far more than knowing the latest languages and frameworks off the top of your head.

[chton]

I've got 10 years on you, and while that still isn't much, I can at least give you some advice on how to deal with this.

Nobody can keep up with the entire industry. It seems like you're trying to know everything about everything, and that's simply not possible. What is possible is learning a little bit about everything. If you see a word, technology or concept on HN that you don't know about, spend 30 seconds googling it. Usually, 30 seconds is enough to get a basic idea of what it is about. The more you do this, the more you will be able to relate things to each other, and you'll be able to intuit a lot of context from just a single-line description of something.

Don't try to learn a lot of languages. When you're 17, it's useless to know VB, C++, PHP, C#, Lisp, swift, dart, python AND ruby. Pick one you now know and like, and stick to it for a while. Become a genuinely good coder in one language, and you'll be able to pick up another in no time. Knowing one language really well also teaches you loads of the basic concepts that you can use to understand other technologies. It doesn't matter if it's Angular, RabbitMQ or Big Data, you need a concept of the problem they're trying to solve before you will understand them properly.

Once you have this nailed down, you can learn about whatever you like. Every single thing you learn, whether cursory or in-depth, will help you understand everything else better.

In short, don't try to be a renaissance man, but be a T-shaped person (http://darrennegraeff.com/the-importance-of-t-shaped-individ...)

[Taek]

I love how you've got so many responses, and hope I'm adding signal more than just repeating what everyone has already said.

It's crazy overwhelming to look at all of the technology and opportunity out there and to know that you can't keep up with it all. But you don't need to keep up with everything. You need to know what tools are out there, and what their general purpose is. 15 minutes with Google will inform you enough about any single technology. In one day you can knock out 10 or 20 paradigms.

Once you know what's out there, you learn more about the things that are specifically relevant to what you're working on and what you will be working on in the near future. And you Google around to see what paradigms are being used by people working on similar problems.

Especially if you already have a specific thing you want to accomplish, it'll only be a week or so before you've narrowed your needs down to just a few specific tools. And those are tools that have arisen from decades of refinement, and will be relevant for at least a decade on their own even if they'll only be the "coolest" framework for a few months. You don't need to be at the forefront of every technology, you just need to be good enough.

And knowing that makes staying relevant feel a lot less scary. Most people only know a few things, and they only _really_ know one or two things. And each of those things is good enough to last at least 5 years if they were the most relevant thing when they were learned. Often they'll be good for multiple decades.

So keep your head up, and pay attention to what's cool and hot, but don't feel behind if you've never really understood what AWS does, or how Angular works, or if you don't know the difference between Unsupervised and Supervised machine learning. When you need the tools, you'll be able to learn them in time to remain relevant.

[hipsters_unite]

Don't freak out too much. Make a list of the minimum list of skills you need to do a non-trivial project solo, and learn those. Once you've got that base you can expand out, and if you've got a few different things to build on it should make that easier.

When I started, it was PHP/JS, but after a while quickly changed that to Ruby/Rails, Python, JS/CSS/HTML and design (can't do a solo project without knowing some colour theory, typography basics etc). With only six things to tick off, it was less of a daunting task and I felt like I was making progress.

I've added to that list both at work and around work since, but as somebody above noted, you can get burned out from coding all the time - sometimes you need to recharge and wait for the fire to come back.

The one thing I do know, is that if you have a passion for the craft and nurture it, you will be able to find a balance :)

[dictum]

This has already been said by others, but let me take this opportunity to talk to you as if I were talking to 17-year-old me.

Focus on what you're making. Let the process sort itself as you go. Step back from the computer and think about what you can do by yourself, with simple tools. Get a pencil and a sheet of paper. With this simple sheet of paper and this simple pencil, you can draw many things. You can paint a whole landscape (in gray tones, but still), you can make a dumb doodle or you can design a machine. You don't have to know how to draw, you can start today and eventually get good at it. First the circle, then the rest of the owl. [0]

All that with just a simple pencil and a sheet of paper. Both have a lot of engineering behind them, so making paper and pencils isn't easy from scratch, but as objects, they're simple and you can use them for many things.

I spent so much time worrying about tools, worrying about browser compatibility, worrying about doing things the right way, increasing performance... that I didn't do what I really wanted to do: make good stuff, for me and for other people.

There's no simple way to avoid the trap of keeping up with everything, but I've found that focusing on the intended result (what you want to create, be it a product, an experiment or a tool), picking a toolset early and sticking to this toolset/stack is what worked best for me.

* * *

Here's good news from present me: as you gain more experience, (which can correlate to the older you get, especially when you start early), you get better at knowing when something will really improve your work (making it faster, better looking, more enjoyable, better performing, more efficient, etc.) and when it won't. Perhaps the article's author is actually on to something. He intuitively knows New Tool X won't improve his work much, and he's wiser than his younger self, who would waste time chasing non-essential niceties.

[0]: https://imgur.com/RadSf

[notduncansmith]

You've got plenty of time. Other commenters are right, focus on theory, and bolster that by building things. Constantly. If there's one lesson I could hope to impart to any budding developer, it's to never stop building. Learn a bit about genetic algorithms - then implement a simple one. Learn a little Ruby, then build something with it. This will teach you a lot of what you need to know - fill in the gaps with Google. Focus on building good abstractions, and you'll be fine wherever you go.

[Tycho]

Are you familiar with the adage that the longer something has been around, the longer it will likely continue to be around? Also known as the Lindy effect.

Anyway my point is that C++ has been around for 40 years (and a dominant language for 30 of those), so it will likely be around longer than anything that surfaced in the last 6 years. Plus, mode new things are just refinements or variations on a theme, so you hardly need to learn them, just keep abreast of what's interesting about them.

[mhluongo]

It's going to be okay. It sounds like your problem is that you want to learn everything- and at 17, that's not really a problem. You can be successful in this industry by choosing any two (ok, almost any two) of the technologies you listed above, and focusing on them for a couple years. If they last longer than that, great.

You certainly don't need to keep up with all of the latest and greatest JS frameworks and understand machine learning to be successful :)

[jamiepenney]

It all seems overwhelming when you look at the whole of the industry like that, but it's a lot easier if you pick a niche for now. If you like backend work, just ignore Javascript for now. If you need it for a job, you'll be able to pick it up, I promise. You sound a lot like me at 17, although to be fair to you there weren't so many technologies at the time. I started with C/C++ and Win32, played with MFC, learnt OpenGL and tried to write a game engine with a friend, got into Java at Uni, did language parsing and C# WinForms at my first job, moved to a SaaS company having done no real web development before, now I work for another web startup where I need to know a whole chunk of those techs you listed.

I tell people I probably won't be working in tech when I'm 40. If you think that's where you'll end up, plan for it. My plan is to buy a business with my wife in her field and do some contracting on the side. No idea if that will work out or not, but that's a 10 year plan. Just having a plan can help with the anxiety.

[andy_boot]

There will always be more frameworks, languages and technologies to learn. Don't freak out. It is impossible to keep up with all of them just accept that you can never know everything.

I'd recommend a 'wide and deep' strategy, try and get an overview of as much as you can but specialize in a couple.

[thibauts]

Most of the tools you talk about will be old before you get a job, don't even bother. Among the people that know how to use them (and most know only a few of them) very few know how to actually program. They only regurgitate patterns they learned by heart. They're lost when they're left on their own. There are good odds you can do better.

My advice is keep the fundamental books close to you and practice a lot. Programming is mastered by practicing, not by reading blog posts, never forget that. Filter the noise. And most importantly : have fun. Mastery will come as a byproduct, don't even worry about that. You can trust your crave for knowledge, it will always lead you on the right path.

I'm probably not the most knowledgeable out there but you can reach to me if you want to talk.

[dobbsbob]

First day CompSci 101: 'The language you will work with professionally hasn't been released yet so we are learning this" I wouldn't worry about it. I work with developers in their late 40s who started out learning Fortran in the 1980s.

[lallysingh]

Woah woah woah, relax. OK, C++ and client-side tech (HTML/CSS/JS) is enough to go for some time. Common Lisp is a good way to go next, but you'll see most of that return in how it affects your use of other languages. For the rest in your list: they're solving overlapping sets of problems with overlapping sets of techniques.

You have to know very few of them to be quite productive. You also have lots and lots of time. I'd honestly focus on getting better at those that you already know than worry about adding in more. And just start building shit. Nobody cares what technology you use, as long as it's not PHP[2].

The more technologies that you know, the easier the new ones will be. I don't know why, but people keep adding them on their resume like merit badges. They're tools, and you aren't responsible for learning tools, you're responsible for making solutions.

But, if you want to learn a bunch of them, here's how you get started. When you start a new technology, ask yourself a few questions about it:

- What's the problem it's trying to solve? (hint: this applies to programming languages as well)

- What're the constraints imposed by the environment?

- What fundamental techniques is it using?

- What are its predecessors?

Those four questions will explain most of the technology[1], before you even look at the details. Do this a few times, and you can predict much of a new technology just from the answers to these questions.

Example: C++:

A systems language for large programs. Must have as close to minimal runtime overhead and optimal code as possible. It's native-code compiled with the platform ABI, usually with the same compiler backend as the C compiler, and without any runtime interpreter or compiler. Predecessors include C and Simula. Footnote 1 applies here, as it is designed by committee, with a "shove a lot of stuff in the language, and let each user figure out which parts are useful" attitude.

[1] Modulo random experiments, social system issues, laziness, and bad ideas.

[2] The only reason to use PHP is "someone made me."

[tedchs]

You remind me of myself at 17. Your post tells me you have both the capacity and the appetite to learn, which is the foundation of success in this field. Keep chaining one body of knowledge to the next.

[varkson]

I just ignore everything dripfeed myself new tech that looks good until I find something I like. Don't everything shown off on HN too seriously, but pay attention.

[steinnes]

You've gotten plenty of replies already, many of which I haven't read. But I have this to say: I'm 31 and I often feel the same, but it's not real. Just read Dijkstra and don't worry about Angular, Ember, or the latest fad.

You'll find out that the real knowledge is relatively stable and how well people know the latest fad frameworks has little to do with their long term relevance or employability.

[alttab]

I literally took the same path. Vb6, c++, games, Web development, and beyond. Just keep going, you'll be fine.

[mamcx]

I was there ;) -Now, I have 35-

... in my time the changes was made by Microsoft, and really I'm a sucker for learn new things.

"More things change, more stay the same"

Despite all the noise that new stuff generate, exist timeless wisdom that permeant all the good things, so focus in answer the question "What good, timeless thing I can get from this?" Even if some tech fade with the time, you keep what do you learn.

I start programming with FoxPro 2.5 in DOS, then Visual FoxPro 3. I still give credit to have used first a xbase language in how "good" I'm (in contrast with some people) doing database work, and have get OO instead of the people that chose Java... despite that Fox died long time ago.

Everything will teach you something good. For example, Pascal/Delphi show me how is work with structure. Python, what look like to have simplicity & readability. Fox, this is how you do database, and Visual Fox: This is how you do OO. Delphi, this is how look like to have performance and RAD, and not need C/C++. Erlang, this is how multi-core development must/could be, Haskell, this is the crazy world of immutability (and this is functional programming).. etc.

The mistake is follow a BIG. This burn me and others devs in my community when we follow whatever MS say. Don't do the things that a BIG tell you: Them are big, and their problems and resources are not yours. Instead, I focus in learn stuff practical for a solo developer or for a very small team (well, if you want to be part of a BIG, then do otherwise: ie: Understand the motivations and intentions of whatever you are listening).

Don't attach to anything.. too much or for too long. Learn as broad as you can, yes... but don't commit until you need to.

For example: I have read a bit about Erlang and GO. However, I don't do anything (in code) with that, because? I don't have a real, present requirement to use that tools. So, I don't get burned for that tech. I just read the websites, download the binaries, run some samples and get back to my actual, present, work. However I get aware that exist that things called Actor Model & CSP (and I google: CSP vs actor model) so I could use them, even with limitations, in python. Or just know that shared/state/mutation is bad for multi-task and passing non mutables messages is good, and use the libs at hand with that in mind.

I have not committed to GO or Erlang, but still, have learning a good, timeless, practical thing that I could carry with me.

So, not worry to get deep to soon, to fast. Learn broadly - look like is your thing!- but not worry about until the time to get worry come.

[venomsnake]

Relax. A lot of those technologies will be dead. And you should be intimidated by angular and ember. They have the smell of Enterprise Java for me.

Learn paradigms and principles. If you know what to do, you will be able to find the tools to do it.

Its a bit like cooking - the cookbooks for the peasants give recipes. The ones for the chefs give mechanics and techniques.

So learn pointers, functional programming, asynchronous operations and few more important paradigms, learn how to keep a code base tidy and organized and just ignore the foam on the water that is the hot new tech. You will be able to learn it in a week when need arises.

[eru]

> Its a bit like cooking - the cookbooks for the peasants give recipes. The ones for the chefs give mechanics and techniques.

See eg http://www.amazon.com/Ratio-Simple-Behind-Everyday-Cooking/d...

[MoOmer]

AngularJS and Ember can be intimidating if you've never:

A) Built an API B) Used an MVC Framework (front or back end)

This can be easily overcome by following either a book like "AngularJS in Action" or spending some time using a framework on a small scale project.

At the end of the day, I've found that when using Angular, my code is much easier to read, maintain, and reason about. I used it for one project about a year ago, and just started another project with it last week - which was easy since I'd spent some time with it previously.

Never feel that you should be intimidated by a technology; but definitely be able to reason about its use cases and the value it may add to your toolbox.

I stuck with Angular because I tend to write larger applications, and Angular had shining recommendations from those using it in similar contexts.

[venomsnake]

I find these kinds of frameworks intimidating, because in them there is usually a ??magic?? phase that is difficult to debug if it does not work.

[epayne]

> Learn paradigms and principles.

This. It seems to me that many authors are pointing to the importance of a balance between the long-term paradigmatic and principled knowledge and short-term tactical knowledge. Both are important and not to be neglected at the expense of the other.