Poll: How do you learn new technologies?

Additional option: build some thine.

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.

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.

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.

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.

I wrote a blog post on my process here: http://syskall.com/tips-for-learning-new-technologies/

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".

Read. Build. Repeat.

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!

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.

Lots of RedBull

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).

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

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

All of the above, with the exception of "Subscribe to a paid service..." and "Buy a video..."

When possible I seek out free information rather than buy it.

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

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

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.

So 123 of you (at this moment) just "build something" without reading anything? Like you just open a text editor and the code flows out of your fingertips due to your vast computer science knowledge? Typical HN b.s.

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.

Build something using the technology Use free material available on the net - youtube, blogs, journal articles.

Read the papers.

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.

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.

Pick real world problem. Build solution with new tech.