Poll: How do you learn new technologies?

[quietthrow]

Would like to understand what are the best practices employed by this community to learn/keep up with new technologies.

Feel free to leave comments if you dont see a option or would like to elaborate on your response.

[christiangenco]

1. Hear about cool new technology for the 3rd time, this time seeing a clear application for how it could be used

2. Get really excited and go to technology's homepage.io

3. Get 40% through homepage.io's tutorial before I get frustrated and confused

4. Shelve new technology away in my brain as a list of potential things I could build something with

5. Months later, get a really Cool Idea for something I could build with new technology and become overwhelmed with a need to build it

6. Fight my way back through homepage.io's tutorial, "getting it" much more this time, and augmenting the tutorial to start building Cool Thing.

7. Fight through errors striving for how I think the technology should work by hundreds of googles and stack overflows

8. Create minimally viable Cool Thing, get really excited. Friends don't understand what was so hard and why I'm excited, as I could have built the same thing in X technology I already knew, but they think Cool Thing is pretty neat

9. Start fixing bugs on Cool Thing and realize I don't understand how the internals are actually working, so go back to documentation/notable book resource/new technology videos and devour them because I have the clear purpose of refining Cool Thing.

10. Cycle through several iterations of Cool Thing and realize I know New Technology pretty well now

11. Hear about cooler newer technology, and read that I could accomplish in one line what it took me 100 to do in cool new technology...

12. goto 1

[pranavrc]

Exactly this. That "I need to get this done" urge drives me to go through the tutorial/book that I previously did not complete due to lack of direction/need.

[pelanne]

Hah! Scarily accurate.

[beat]

Do it in one line?

Javascript callback functions don't count as "one line". :)

[Mikeb85]

Haha +1 to this... Familiar path, this is how I learned Clojure.

[ratsimihah]

Das my life, too.

[zaphar]

Always build something. Nothing teaches you about a technologies limitations and benefits like building something with it.

I don't think you really know a technology until you've build something with it.

[quietthrow]

Agreed for the most part, but might not work in all cases. For eg. Learning to use vim ....

[tptacek]

There's a lesson here for people whose aspirations include writing technical books.

[mechanical_fish]

Is the lesson "HN polls are unscientific, biased samplings of groups of people that might or might not contain any members of the audience for your technical book?" ;)

It doesn't help that this is a generic poll about generic books. Of course imaginary books poll worse than imaginary websites: They're more expensive (because imaginary books have an imaginary label saying "$9.99", and imaginary websites are free and subsist purely on popular goodwill and flamewar-powered Carnot engines) and neither of them has any real content so it's impossible to evaluate the amount of imaginary value one is getting for one's imaginary money.

Whereas in the real world people judge their materials in the context of specific authors, subjects, goals, and budgets. People compare (e.g.) a copy of established-Github-wizard Scott Chacon's Pro Git (a try-before-you-buy CC-licensed free book) to the thrill of trying to learn Git's canonical workflow by reading its man pages and browsing flamewars about rebase v. merge. Or a ten-minute Railscast Pro about Devise, paid for by your boss, to the option of having to admit to that selfsame boss that your project's hand-rolled authorization code got hacked.

[seivan]

First, I read everything I can read. I don't even try, I just read. Then I try and read at the same time. Then I stop reading, and just trying.... and trying.. and mess up, and keep trying again.

You never really stop trying

[gyepi]

Most of my learning is from "print".

I always start with the available documentation, coupled with code reading to help me understand certain aspects better. Once I have a good feel for the language, I buy books to help me understand the nuances I may have missed initially. I usually end up buying books on languages and systems I expect to use a lot. I used oreilly's safari for years, but eventually stopped because I discovered that its available changed my learning style: I browsed more and read less deeply that usual.

No videos but I do use blogs occasionally.

[yareally]

If it's something similar to what I already use (like say trading one web framework for another), then I just look at the official documentation/examples and some decent guides. After that, I start building something with the new tech.

If it's something like a new language or database, then I might be more interested in getting a book on the subject (if there exist any decent ones). I'll usually skim through the book looking for areas that differ significantly from previous languages/databases and focus on reading about those parts. Following that, build something with the language/database.

Reading stuff only online if it's not official docs, can really burn you though (not that books can be any better at times, but books at least get reviews). Most of us probably already know that, but the quality of content of many blog posts and tutorials can be sub par (especially for things like PHP and Android). The faster a piece of technology changes and the way one uses it, the higher the variance it seems in quality of online content (just looking at bad practices in PHP from version 5.2 and before to 5.5 and also Android 2.x and before to 4.x).

Pretty much though, it all comes down to building. Reading can get you past some of the basics, but applying what you learn reinforces. Also, it doesn't hurt to eventually teach/discuss what you're learning with someone else, as it helps to also reinforce what you already know and question what you are unsure about (either actively or in retrospect).

[vinceguidry]

I find someone to pay me to build something using it. It's how I learned jQuery, Sinatra, Bootstrap. Bout to do the same with Angular and Rails.

I wish I could learn a tech from a book, but the signal-to-noise ratio is generally too low in the vast majority of books I see. I don't need a bunch of "recipes" or a disgustingly short bash rundown in a book on Ubuntu, I need clear, server-oriented insight into how the OS internals work, and what went into the underlying design decisions.

Every book on a programming language I pick up spends 90% of the time on basic stuff you could pick up in a few hours with the same language's "getting started" page. I'd love a teardown of the source code with commentary on the intentions of the language designer. I don't want a gentle introduction, that's just a waste of my time. I've already introduced myself with a dozen or so hours of playing around and reading docs. But the people that could write useful things about technologies generally aren't. Or maybe I'm just not looking hard enough.

[billpaetzke]

> I find someone to pay me to build something using it.

Sounds good to me. Where do you look for this person? And how do you sell yourself developing in a tech in which you have no experience?

[Terpaholic]

I use Stack Overflow first, searching for "Stack Overflow learn ____" and seeing what they recommend.

I believe the best way is to BUILD something, so in the past lynda.com has been useful to get code into the IDE because you can write it with video, tweak and experiment (where the real learning occurs), and then go back to the lessons.

[_xhok]

I think "build something" would be better reworded as "do something;" that is, use the technology. Studying theory before diving in may work for other fields but if, say, you're trying to learn Django, you learn more from making a web app with it than you do from reading or watching several tutorials or guides. If you want to use vim, just write your next program with it, and consult the help every time you notice an inefficiency in your work flow.

I think this approach works with hacking because there are so many little perks you have to know about and finishing a project is one of the best ways to expose yourself to many of them.

[songzme]

I have been doing bi-weekly talks about new technologies that I have never used before for my meetup group in San Francisco: http://www.meetup.com/apidiscovery/

The way I've been learning, is to do a quick getting started to get the gist of the new technology, and then read through the documentation. What I have realized is that by reading the documentation, you get to really understand that technology you want to learn.

Good Luck!

[sim0n]

I usually take a look at any docs/example code and then start hacking straight away. Not the most academic way of learning but I personally have the most fun learning this way.

[JakeSc]

For me, it's orders of magnitude more efficient to try out a new technology than to read a book. For example, I recently took on a more advanced Arduino project. Knowing very little about electrical engineering, I've been making slow tangible progress, but immense intellectual progress.

I usually end up seeking out reference material to supplement my experimentation, but by far most of my learning comes from actually "building something using the technology".

[tomku]

For me, it's a mixture of books/e-books, screencasts, self-directed projects and free web resources. Paid versus free doesn't really matter much to me - whether it's a $20 book or free series of blog posts, the time investment tends to dominate the money investment. I'm more worried about wasting time on poor resources than saving a couple bucks, and books have treated me very well in that regard.

[isaacb]

You really need an option for "Reading the documentation" which is pretty different from reading blogs and watching youtube videos.

[brown]

Project Euler (http://projecteuler.net/) is great for this kind of thing.

The problems start simple, which is perfect for the "learn the syntax" / "learn the tools" phase.

Then the problems get harder, which is perfect for the "learn the advanced features" / "learn about the community" phase.

[eccp]

Exactly this! ... I started learning Clojure but I was too green to build something complex, so my problem was "Where do I get problems to solve with it?" and somehow I stumbled with Project Euler, where many others implement solutions in other esoteric languages as well.

[phektus]

I do this with web technologies but may be applicable to other areas as well:

1. Read tutorials if available, then books in that order. Not to be exhaustive but just to get more stuff into my head.

2. Do a small project that uses it.

3. Repeat from step 1 but with more info to digest and a slightly bigger project to work with.

After some 4-5 iterations I would have a nice grip on the technology and a handful of small projects to show with.

[ggreer]

My time is limited, so I prefer to learn from the mistakes of others.

Before I build something using a new technology/framework/language/whatever, I look at popular open source projects that use it. Not only is it useful to pick up idioms, but browsing through the project's closed issues is a great way to find and avoid common pitfalls of the new technology.

[cema]

I am surprised to see the "work with a mentor" option having such a low score. Don't you guys learn from each other?

[dagw]

Speaking only for myself, I'd love nothing more than to work with a mentor, but I have no idea where to find one with both the time to dedicate and the relevant skills. Nor am I sure how I would fit it into my work schedule.

[danielweber]

I think it's the best answer, but it's also the hardest to accomplish.

So many times I'm like "WTF is this tool? Why would I want it?"

[agentultra]

First thing I do when I have a problem is see if someone else has solved it for me.

I have limited brain space and learning something really well often forgoes learning new things unless they are evidently superior.

That being said, I don't often spend time learning new technologies. Instead I invest in learning fundamentals.

[ekpyrotic]

Additional option: build some thine.

[pedalpete]

Building is key, but the way I learn while I'm building is to go through blog posts, tutorials and videos. Always free ones though.