The key to fast startup development is packages. They are also a great tool to learn a language quickly. My personal technique is:

1) Type into Google: "Package manager for Ruby/Nodejs/PHP/Python/etc"

2) Find a site that lists packages for that language in order of downloads per day or week.

3) Look at the top packages to see what the most popular frameworks are. Generally the top 5 - 10 packages will be all you need to develop 95% of basic projects.

4) Look into the repos for each of the top projects and look for an "examples" folder. Most top projects will have basic examples that will not only bring you up to speed on common language patterns, but also help you learn the most common and most useful methods of that framework.

5) Import any packages you need for your own project, copy a relevant example from one of the packages to start it off, and begin customizing.

Personally I learn best by example, and I find that the examples in the top frameworks and packages for any language are all I need to get up to speed in a day or two.

and when there's no examples, i tend to go for the unit tests.

Well said.

Build an internal tool for your existing company/product. They frequently don't require much in the way of functionality to produce business value, tend to map naturally to "things you'd actually care about" rather than staying at the surface-level "and this is how you make text display in a table", and can be quickly shot in the head after you're sufficiently advanced in the new stack to realize everything you did wrong the first time.

As to how I'd go about building an internal tool, like say a dashboard for my SaaS app but this time written in Golang? I would blow up Google with a series of queries for [golang web framework], [golang mysql adapter], [golang Stripe library], and keep Googling every time I hit a roadblock. (I suppose there could theoretically be planning at some point but the nice thing about internal tools is if you create a creaking Frankensystem then what is the worst that happens? It takes 800ms to load instead of 300ms and you have to keep it behind the firewall, where you were going to put it already?)

Another nice thing about internal tools: if you find yourself banging your head against e.g. image generation for too long you can always just wire up a trivial internal service written in a stack you're more familiar with to call out to your usual image generation solution, and then just consume that service with the new app. Then make a note "Note to self for rainy day project: Figure out how to do image generation in Golang."

I've found that I just won't learn a language or framework unless I have a clearly defined goal/project in mind, so I usually start with that. Toy or otherwise, if I don't want to build some sort of project, for which the language or framework is a good fit, then I won't ever learn more than just dipping my toes into the language.

My approach is actually fairly consistent across languages/etc., and it usually gets me up to speed/gets me to a point where I know enough to work with something, but certainly doesn't make me an expert in the language or framework.

I start by doing a hello-world equivalent, usually with some sort of input and output. (E.x. "What's your name?"->"Dave"->"Hello Dave!")

Then, I usually go through some sort of basic program to get an idea of how the language features work and how things are done in the language. Exactly what depends on the framework or language; but usually of comparable difficulty to a dynamically resizeable array with basic algorithms like 'sort' (merge, quick, etc.) in C. The idea is to write something you're fully capable of knocking off in less than two or three hours, and is <1000 lines of code but isn't trivial. My reasoning for this intermediate step is that a large project needs to have some sort of structure, and if I don't have at least a rudimentary understanding of how things work in the language, then I'm going to have a bad time.

After I've done that, I get started on the actual program or project: I start by constructing a rough framework of how I want to structure the program and then slowly add in the parts that I want, restructuring if it's necessary.

Throughout the process, I look at websites/books/documentation/code examples/etc., particularly if I don't know how to do something or think there's a better way than what occurred to me.

Strongly seconded. There is no substitute for diving in and getting to grips with new tools. Nothing even comes close.

1. Read promotional material.

2. Read tutorials.

3. Devise some useful side project I could build with the language. Don't just go try to build them.

4. Build a couple of tiny utilities in the language.

5. Build something ambitious --- as in, something that would be ambitious even in my wheelhouse languages.

6. Reread online material about style, refactoring, libraries, &c --- I can't appreciate these fully or retain them until I've completed the preceding steps.

So, for Golang, I did:

1. Slurp up all the "what makes Golang awesome" stuff, read HN threads, &c.

2. Read Effective Go.

3. Decide "this would be great for building a large-scale web crawler backend"; gears start turning on how the different parts of the language would mesh for me.

4. Build a TLS proxy, a simple hex-dumping plugboard proxy, a CA library to do on-demand certificate generation.

5. Build an emulator for the TI MSP430 CPU and bootstrap it to the point where I can compile mspgcc code and run it on the emulator.

6. Read every blog post on the Golang site, start paying attention to Golang threads on HN and chiming in.

Step #6 is the step I'd want to be at before asking questions on the project's IRC channel.

I could break out Ruby, Python, Tcl, and C++ into the same set of steps over the past 10 years (my "native tongue" is C).

This is just how I do things, not necessarily the best way to do it. Also: when I'm learning, I favor a sharply NIH style --- I actually try to avoid fancy libraries, especially for stuff like Golang and (at the time I learned) Ruby, where the language is "hot" and the ecosystem is full of stuff that might not last. I'm worried about doing what Jamis Buck did and introducing dependency injection into Ruby, and then having to waste time undoing that.

I have in the back of my head 3-4 fairly ambitious projects I've queued up for the purpose of learning, say, Clojure or F#.

I've been creating the same webapp (a simple bug tracking system) over and over again in different frameworks to learn the stuff I care the most:

-Localization (amazing how many web frameworks suck at this, specially, client-side frameworks)

-Learning curve

-Authentication / Authorization

-CRUD, REST, TDD, LoC

-Template language

-Fragments/Tiles/Panels support

-Deployment (i.e. grails WARs are amazingly big)

Over time I've made this webapp in Grails, Play, CakePHP, RoR, Django, Flask, Wicket, SpringMVC, Struts1-2, Hibernate, jOOQ, Angular (ugh!), ExtJS, Express and Meteor.

What I like about this is that I don't have to think about how the product will work, no design, and I can reuse most of the HTML structure (header, footer, menu, etc) and I can compare and reach a conclusion about the framework pretty fast. If I can't make the freaking thing work after two days, the framework sucks or I'm simply too stupid to use it.

So based on your experience with this process, what are your comments on the listed (or unlisted) frameworks?

Angular gets an "ugh!" but ExtJS doesn't?

Yeah, it's a personal opinion, but Angular is weird, and ExtJS was easier to get a hold off five years ago, so go figure.

I found, in terms of learning a language quickly, that taking a course in programming language concepts where you have to learn a variety of different languages, covering functional, procedural, OO, symbolic, static and dynamically typed, etc, makes picking up new languages easier.

Most programming languages use ideas that already exist in other languages, so the more languages you learn, provided they cover the breadth of the major paradigms, the easier it is to pick up new ones. Alternatively, if you can't take a course or don't want to, make the effort to become competent in a number of languages that cover the spectrum described above. C++ developer? Learn python for the dynamic \ functional aspects. Then learn Haskel to force you to think pure functional. Or OCaml. Learning js, due to the way it implements objects, also taught me a lot about object oriented programming, as you are forced to use closures to get private variables, and it's object model is primitive so learning to work with that can be educational.

I build something small and work my way up.

For me it works well to solve the little problems like routing, templates, etc. on simple/dumb things and add complexity over time.

Like, build a blog or twitter type app that maybe does basic CRUD type things, and has some kind of data listing etc.

This isn't exactly an answer to the question, but I wish that it was more common for projects to provide high-level conceptual overviews. More often they just dive into code and expect you to pick up the big picture through osmosis.

For example, when I was trying to learn about React.js, I spent a day or two of research to write this, which is the kind of documentation I wish had existed in the first place: http://blog.reverberate.org/2014/02/react-demystified.html

As a back end developer trying to learn JavaScript I can't agree more. The syntax is easy enough, and once I found a decent explanation, the scoping rules make sense. But for getting an overview of the concepts and the standard way / best practices for designing the application I am often at a loss.

I cannot recommend Javascript: The Good Parts highly enough if you're trying to learn JS. It's probably the single best programming book I've ever read, in that you could very well read that and a very basic introduction (on the level of syntax) and legitimately claim to know the language.

I have had a look through that book, and it is very good one one level, but trying to get anything practical done these days seems to require JQuery, and a lot of context knowledge about the DOM.

Maybe Its just because I know the backend well enough, a switch from Perl to Python was quite effortless, but making the same jump to javascript, I find a lot more difficult.

I started in mainframe languages, and have moved across to modern languages. I have a set of things that I perform in any language to gain familiarity: loops, nested loops, lists, arrays, dictionaries and other data structures, control structures, etc. All of the basic things that you know you will need. Then I usually set about how to setup testing - at least unit tests. I use TDD, so this is vital.

It only takes a few hours to go through these basics and get a tour of the language. I try to sit next to someone who is using the language if possible - they often have tips and tricks that they have found through trial and error, and can cut time off your learning.

I can generally become productive in a few hours. That affords me time to learn the deeper structures of the framework as I go along. Having that initial core understanding really reduces issues down the road.

Take a project that you've built using a framework you're already familiar with and replicate it with a new framework.

This way, you're focused on learning the framework and how something is achieved within that framework without bothering to think about architecture, features, etc.

This is how I learned Symfony (I came from Zend) and it served me well!

First off, I try and rank the pieces of the project by complexity.. there's almost always a simple CRUD interface that it needs somewhere that I can start with.

I always start out getting a book, which I then don't read the majority of (although that is a luxury of moving from web language to web language instead of something more drastically different). I'll read how to get the project setup, and skim basic framework object structure (this is where having a book you can easily skim back-and-forth in is handy). Then I'll just start. Most simple stuff (syntax to traverse a collection), I'll just Google quickly. Inevitably I hit a framework aspect that's unique or in-depth enough to merit study, and then I'll read that section of the book completely.

If you're using a third-party library with source, stepping through some of the logic is generally something you end up doing anyway, but it's pretty useful to do right away to get an idea of some of the optimal structural tricks the more familiar devs use. Maybe follow a couple of API calls for a step or two to see how they arrange things.

Once you've done enough to feel comfortable (maybe the first couple chunks of complete functionality in the bag), it's good to Google around for things like "Common Mistakes/Pitfalls in X". You'll probably have run afoul of a couple of those, and will now be familiar enough to understand and remember them. You can go back and clean up the little bit of code you did then.

I get a book, start a project with a goal, map out things that I know already to concepts in the new framework (Models to Models, etc...). I ask myself what is the same, what is different... I try to separate out language differences from framework differences.

I also try to understand the motivations behind making it, and what they were trying to accomplish as a goal. I have to try to make sure I don't force paradigms from another framework/language on this one.

I just grab it and start building!

Generally this involves following whatever basic "getting started" procedure is available - this typically covers the big-picture details of repo structure, package management, general philosophy etc. - as an experienced developer, you've probably had enough exposure to various processes, tools and paradigms to easily understand how you would approach building whatever you're trying to.

I often come up against things that I'm not clear on the canonical implementation of - but a quick search usually clears that up. I think of it much like learning a human language, and imagine it's much better if you're immersed in it, than it does if you try to learn it from a book. It does mean you're more likely to make mistakes, but so long as you leave a little buffer for rearchitecting things when you've done them wrong, that's all part of the learning process.

I've especially tended to avoid books and longer-form articles—they often seem to be really out-of-date and different from the current best-practice, particularly for newer stacks.

Re-building an app you've already done in another language is good..."Todo app" is kind of a "Hello world" for more experienced evs...

However...sometimes I'll just copy an example...the manual typing-out of code, for whatever psychological thing in my brain, really stimulates an extra sense of observation in me...I think part of it is that when I just read code, my brain is thinking "OK OK, get on to the point!"...but when I slow myself down enough to type out the code, my brain thinks "OK, while we're waiting for the typing to finish, let's think about this code".

If that's too easy for me, sometimes I'll make the exercise tricky for myself by coding in a different style. This can involve rewriting the original thing, even altering the functional design and interface...or, with JavaScript, re-writing a JS-framework-example in CoffeeScript (which kills too learning-birds with one exercise)

Re: Copying the example code - LPTHW and others of that style are huge believers in writing all code out by hand. Even if you don't know what it's doing yet you're letting the language syntax and style start to soak in.

I have a suspicion that this works well for certain kinds of learners, though not all. I'm probably in the former camp (very visual/tactile focused).

- I don't buy books for technologies anymore, I buy books for algorithms. Most of my technology purchases are out of date.

- Most online stuff is decent for the first 2-3 weeks.

- Meat of the learning is done in the trenches with the manual of the system ready-to-hand (i.e., google).

- choose a small and stupid project for using it in anger. I favor one of these:

    1. Basic data structure (binary tree, linked list)
    2. Interface with postgres. 
    3. Shell out to the OS and do some munging of the results.

These represent a slice of common & standard tasks involving libraries, string handling, interfacing with other tools and data structures. Most of my work generally involves one of these 3.

Make something! Internal tool, something to scratch an itch, doesn't matter. Try to make something you'd know how to make in another language, but that will be challenging in your new one.

Too often "studying" can be procrastination. Find a kernel of the language that's "just enough" and run with it.

I used to try to read books, but I find for me it's much easier to use books as reference than as introduction. You find the corner cases in a language very quickly if you just move fast and break things.

Here's my process, for what it's worth: 1. Read some code that's out there in the language, either in a book or online. Books are great for this, particularly with more mature languages. Absorb the idioms of the code. Like poetry in a foreign language.

2. Play around a bit. See if you can get the basic tools (compiler, IDE, emacs extensions, whatever toys fit in your own sandbox). Write a "hello world". Get something built and running quickly. Even if it's just a loop that counts to 100.

3. Once you've played a little, go read a little more code. That's your scaffold for learning.

4. Come back and play some more.

5. Add to resume and see if someone will pay for you to learn some more. If not, repeat 3-4-5 until you've got a contract where you will be compelled to master the language, or...

6. Once you're doing something in production with the code, evaluate against other technologies you've used to get there. Does the new language work well? Does it play a role for you? Or is it flawed at scale? Maybe it's good for prototyping. Maybe you find it's really not good for anything and teaches bad habits. Add this knowledge to your base, and...

7. Go back to step 1 again. Repeat for entire career.

It's worked for me. I've had a lot of fun engineering. And when I get to step 6, I keep coming back to Java, over and over, as much as I'd like to move on. But that's a topic for another day.

I find that doing a "tour" or some sort of interactive learning experience is great for getting exposed to the syntax, and laying the foundations for what will become muscle memory for the most common bits of syntax (declaring variables, basic operations, etc). CodeSchool has a very good iOS course offering (I didn't complete it, but only because I realized that I really dislike Objective-C). After that, create something you can dogfood. As others have suggested, in-house tools are a great excuse. Personal apps are good as well.

A real project will get you used to doing real stuff, and if it's sufficiently non-trivial, will serve as a great drill for the basics (e.g. string concatenation). It will also help you get very familiar with the documentation, and the community around the language/framework. In the case of Go, you'll also learn to always search for "golang [problem]" rather than "go [problem" ;)

As an exercise in learning Golang, I built a really tiny service for something I wanted (an app that would read Hacker News to me with TTS). It took about 15 hours over the course of a week, and most of that was in debugging/reading/debugging mode, trying to figure out why I couldn't just unmarshall this JSON blob into a struct (turned out the struct fields needed to be string pointers, not strings).

When I am in the learning stage of a framework or language, I take a bottom-up approach to the program or system I am trying to build. I focus on the smaller aspects first and then move to larger architectural stuff once I understand it better. Google is my main tool, every single problem I encounter I google first before trying to invent a solution. This allows me to get a broad overview of what is available before moving into the territory where I need to create more heavily.

For instance once I was building a recipe search engine on a new platform in python, my process went like this:

1) Make 1 table in the database, for recipes, with the constraints that I needed. (Learned Model Representation)

2) Build a lame page which would pull a single recipe and show it. (Learned Basic View and Controller)

3) Build a page where I can type in a query and get some recipes back. (Learned how forms are handled)

4) Added way more DB Tables to cover most of the data schema. (Learned more advanced DB operations)

5) Built better looking Web pages which would be more responsive. (Caching, Static file handling, more advanced controllers)

6) Built actual search code

Although this is a specific example, I find using a method such as this, where I start with very basic problems of the larger picture, allows me to get moving very quickly. Furthermore, as I start knocking off the easier stuff I feel more confident and I learn the best places to find answers for my questions for that framework.

Use the source. Really. Never, ever, ever be afraid to read something you don't understand. Read it until you understand it; keep reading it until you're able use what you understand. Always use what you understand, somehow.

See source. See source build. See source Run. Three very, very important steps. Each step requires patience and much verisimilitude in the face of extreme danger, fear, uncertainty and .. doubt. What you don't doubt, you don't really know. Doubt, always, whether you understand something properly, even if you've been using it for a while. You can always learn more, but the first step starts with just a little doubt .. or question .. or intrigue .. about how something may or may not work. Guess about it, if you don't like doubting so much. Guessing how much something you doubt, works, will reward you when you stop all the psychology and just get on with: See source. See source build. See source run.

Never forget, you'll never use all of the power of the computer, ever. Its not the power that matters. The only thing that matters to a computer is the user. Nothing else is interesting; getting the user to the computer is what development is all about. Develop until done.

My strategy has been to fork a codebase that utilizes whatever framework or language I'm trying to learn and work backwards. It's often enough a feat in itself just to get the thing to run locally. Once I've got it running, I just start breaking things to learn how all of the pieces work. I've always liked employing a "top-down" approach, where I start with something complex and then figure out how it works.

The dissection, vivisection approach is great paring for doing micro experiments with the technology. As the act of creation and scientific exploration are different, they require different thinking patterns that give the other parts of your brain a rest.

I just got a program in racket up and running, and not knowing the program or Racket, I hooked up http://docs.racket-lang.org/reference/debugging.html and started to map out the transform and flow of data through the system.

I love to read a quick 10min tutorial written specifically for experienced devs.

Example: http://ycombinator.com/arc/tut.txt

There's a really good one for Python but couldn't find it.

I like those tutorials because they explain the high-level vision of the language with low-level syntax and practical stuff. Once I "get" a language, it's easier for me to just look up what I'm missing when I need it.

I usually do:

  1. Read quick tutorial
  2. Hack something and read about stuff specific stuff to finish my "hack project".
  3. Real an exhaustive book from cover to cover. (But skimming over useless 
     sections or anything that I already know.)
  4. Work on a real project.

And in term of "hacking something", I usually create an IRC bot. Why? Mostly because it brings great memory as it's how I learned to develop when I was a kid. But also because it's very practical. You need to work with existing libraries to manipulate strings and sockets while doing non-trivial stuff. I used to know the IRC protocol by heart so I just had to focus on the syntax of the language.

I'm confident you can get into iOS too. Most important thing I ever re-learn over and over is that my brain is most efficient at writing the next line of code. Get to hello world as fast as possible. If you want an abstraction, likely that abstraction exists and has some minimum implementation. This method of layering abstractions has no end.

Latest example I was messing around with Sails knowing nothing about Node. We had one semi-experienced Sails user in the room and within 30min everyone was running Sails and we had created some pages and routes for everyone to screw around with easily.

Maybe that's the lesson. Find some other experienced people and one who is experienced in the exact tools. You will generate the same noob problems from multiple angles while having the experienced person to keep the stupid in check.

You can find these people. Go to an event where everyone's required to hack something that weekend and put together a pile of engineers. You don't have total control over what you get, but in my case, I got to mess with some Node. It wasn't mind blowing, but I know that it has a strong ecosystem for real-time clients.

First thing, i find open source example or libraries and modify them. Often, the modifications are pointless (how do I move this button) or not very useful (what if I wanted to rearrange things to do this one thing asyncronously), but the process of reading the code and digging through it to figure out how to do it is helpful. In theory, if something is open source, a new developer could sit down and try to pick a few things off the bug tracker, but every time I've tried this it hasn't worked out, usually you need to know a lot of context about a project before you can fix the bugs usefully. Longstanding, low-priority bugs are often unfixed for a reason. I still learned a lot trying this.

The nice thing about this is I can spend as much or as little time on it as I need. Even figuring out how to set up and build a project in a new language or environment can teach you a lot. Often my first step is to jump in and change a bit of text, since that's usually easy to find (grep). Sometimes even this simple of a change will open up a can of worms (in other words, a path to great learning).

Then, I come up with a simple project and build it. Often, I will use a new technology when prototyping.

But be careful, there's a big gap between getting to the point where you can get something to work with a bit of persistence, versus knowing the "right" way to do it in that language or api.

You say you could probably learn to build an ios app in a week or two given your background, and you're probably right. I have a similar background and it took me about six weeks, working on evenings and weekends, to put together my first iOS app from not knowing any Obj-C. But now I've been building iOS apps for years, and when I looked back on that first app I cringed. I've actually rewritten most of it by now.

It's been years since I have actually read a programming language/framework book end to end. Or even done an online tutorial from start to finish. When I started learning iOS, I started with Stanford's CS 193P lecture series available on iTunes. After some lectures, I started working simultaneously on the project I had in mind. Sometimes, I would go back to a lecture (like the one on UITableViews) to review the basics. But after a while, I stopped going back to the course (I must have finished about 50% of the course). At this point I was comfortable just Googling up whatever I needed to know. And of course posting questions on StackOverflow.

So, I'd suggest 1. Get enough from whatever source you like - books, online tutorials to get started on your own project. 2. Start working on your project. Google for best practices, libraries whenever in doubt. Post questions on SO when you can't figure something out. When you need to go in-depth into a topic, find good documentation on it and take time to read it through.

I am not as experienced as you are but I do spend a lot of time learning new frameworks. As with everything new the more time you spend with it the better you get.

Rather than trying to learn a thing inside out I like to pick stuff that can be immediately useful to me and build some small stuff with it.

For instance I am learning lua (and open resty) at the moment now lua is itself a very small language but I am new to it none the less. I tried reading a programming book but I got bored quickly as it repeated almost the same stuff that I have gone through many times before(operator precedence etc).Instead I created small utility apps that were useful to me immediately.

Like I created a lua script that cd-ed into a directory and started an elastic search server. Another one that abstracts couchdb api into quick command line options (I got tired of typing long curl http requests into the terminal) and does other things like replication pushing design docs etc.

I use books as reference, something to come back to, unless there is a book like learn you some erlang which I read cover to cover :)

There's two different scenarios.

One is where you know what you want to learn (iOS, say). The question is, how do you efficiently learn it (or at least the bits that you are most concerned about learning). There are several good comments here along the lines of "download the tools, read the basics, start building something, look for help when you get blocked."

The second scenario is when you don't know what you want to learn. Should the next thing you learn be iOS? Android? Ruby? Haskell? And if you're not just going to go by which set of fanboys is loudest, you need to learn a bit about the candidates so that you can decide which is the one to dive into and really learn. The problem is that there are more candidates than there is time (especially if you count not just languages but frameworks and tools).

I don't have a good answer for how to find out enough to decide whether a particular language or framework has enough substance that it's going to pay back learning it.

I actually find this site is god for getting an overall feel if something is good or not from the comments made about a library / framework, language. (Though there seem to be a tendency for anything in js to make it to the front page these days).

I've been coding for about 15 years, and these are the strategies that work best for me:

1. If the framework or language contains paradigms that are new to you, start by getting a learn-by-doing book like a pragmatic programmer guide, and work your way all the way through it.

2. Start doing little projects that are personally relevant to you. These can be anything: little math problems from projecteuler, data analysis problems, technical interview questions. Which projects you choose are less important than you being motivated to sit down and actually finish them, solving both the easy and fun parts and the annoying "shovel work" parts.

3. Sign up to teach someone (friend, coworker, meetup group) what you just learned. The pressure of the impending performance will force you to deepen your understand of the new topics. This is also known as the "Richard Feynman method of learning"

Come up with a pet project and code a prototype in the language you're interested in (or, more generally, using the set of tools you're interested in). If you like what you experience, extend the project, solving more difficult problems, step by step deepening your knowledge.

Actually I think languages and frameworks differ by the quality of their documentation. Some of them just suck. So maybe if you are not making much progress with one framework, you should try another one.

Unfortunately with iOS and Android, you are stuck with what Apple and Google offer you.

Immerse yourself via project. Not tutorial though, project.

Tutorials are nice, but ultimately very hand-holding, and leave too many questions left unanswered (i.e. "why the hell is this here?"). If you can build something where the answers aren't immediate, then that requires you to actively seek out the answers and make beginners mistakes that can only be fixed by knowing the quirks of the language/framework. If it takes effort to learn something, then you generally won't forget it.

When I started working on my circuit sim in javascript, I had only the faintest idea how javascript worked by running snippets of it directly embedded into my html. Now, I'm pretty familiar with the gotchas, especially the painful ones.

The best answer is always going to be a mix, which works for you. And each language you learn will provide more experience at learning. That said, and merely providing examples:

Find the koan collection for each language. Pretty good for syntax and peculiar idea demonstrations. Not so good at project design.

"build it as quickly as possible" and when you hit a roadblock start googling to find out how someone else got past it. Thats a PITA, surely there exists a library for that?

Also blog posts / podcasts by devs for devs and read between the lines a bit. Not so much what are they specifically talking about but more generally. Nobody talks about XYZ and nobody mentions solutions to ABC, but everyone's got an opinion about DEF and GHI.

1. Start a project - i.e., start learning any details only when I have some real piece of software that I need working, and for which the new language/framework would be the Right Tool compared to the alternatives I'm already familiar with.

2. Read up on the best practice idiomatic approaches for such problems in this particular language/framework. This will usually be significantly different than doing stuff according to the pre-existing habits.

3. Solve problems as they arrive, by judicious use of [parts of] tutorials relevant to implementing that part, finding appropriate libraries and learning all the surrounding ecosystem of tools, libraries and related projects.

Try to build something with it and learn as you go via Google. Sometimes you have to start with a hello world boilerplate or todo app so you can get a feel for idiomatic code design / structure that suits a particular language.

It's prior knowledge and then doing small projects or demos that enable you to learn the things you don't know. Take you time. Going from a desktop or web programming area to mobile is a bigger leap than you think. Especially because it sounds like it will involve learning the elegant and interesting objective-c.

For mobile programming I recommend watching the Google I/O and WWDC videos. They are verbose but it is the real deal.

Otherwise I like to do small tech demos or do tutorials from books.

Learn the IDEs better right away too. option-click stuff in Xcode and learn whatever Android Studio is supposed to do(I kid).

There is no substitute for simply reading the source code of the framework or library you want to know. You can go at your own speed, however fast or slow that may be. You know the code you are reading is always accurate and never out of date. And you have the opportunity to run into new ways of dealing with a problem that you may never think of looking up in the documentation.

Learn to Read the Source, Luke | http://blog.codinghorror.com/learn-to-read-the-source-luke/

This is definitely what you ultimately need to be comfortable doing once you're familiar with a library, but I'm skeptical that it's anything close to the right approach when you are trying to learn how to use a monolithic codebase quickly. Finding concise, example-based tutorials / documentation seems to be the best way to get up and running quickly.

I do still like books, though I find for technology topics my Safari Online subscription is way more useful than buying individual books. I'll have a book on my virtual shelf for a few weeks, dart around in it gleaning what I want, then I swap it. I not only avoid the build up of obsolete paper books, but I'm not having to struggle with the "should I buy it, which is the best, is it really worth $39 when I have blogs" type purchasing decision.

The great books will sometimes be bought outright, but by then I know well what I'm getting.

I like to use CodeSchool, PluralSight and Udemy. If it's pluralsight or udemy, I will stick the speed at 1.5x to 2x. You can burn through a course really quick that way. Also for Pluralsight/Udemy, I skip following along in code and doing exercises and just learn the gist of what is going on and what are the different capabilities.

Once you have gone through the course do a small project. I like something more involved than a "TODO" application.

I don't think I've ever tried simply absorbing the language or framework without building something in it.

Two summers ago, I had a Ruby/Rails internship, and before the internship I'd never touched Ruby or Rails. Since I needed to learn on the job, I built myself tiny applications in Sinatra, then Rails — and then could apply it at work.

The key, I think, is trying to build something specific with your tools.

For me just starting work on a real project does the trick. First I do a basic 'hello world' time project to quickly learn how the file structure etc. works. Then I start coding. For everything I need to do I google it. e.g. Create a string in Objective c. Save a file to documents on iOS. Load content in WebView on iOS. etc.etc.

Eventually things just start to click for me.

I think everyone is different and different things work for different people. For me, it's the reading + practice combo that works. Other people prefer videos, tutorials, help from tutors, diagrams etc. or combinations of these things. So basically do whatever worked for you in the past (not just with programming languages, but anything else).

I start with a book and/or the language/framework's online reference to gain basic familiarity, then build some breakable toys (say a calculator app or CRUD website) to test my newly gained knowledge/assumptions, and finally read forum threads about it to gain insight from people with more experience.

I found that the best way to permanently learn a new language/framework in depth is to build a project. All the books, articles, and tutorials you read will soon be forgotten if the knowledge learned from them are not practiced in real work. Sometimes those side projects can become useful, too.

My advice for iOS in particular is to not fight the tools. I took a dislike to Interface Builder back when it was a separate program and only recently have I actually started using it to build interfaces and in retrospect it would have saved me a lot of time. The follies of youth!

Fighting the tools is like hating a place you just moved to. No matter what you do, you will never feel at home and miss out on all the experiences of being a local.

I just happened to release an article about this today! http://flippinawesome.org/2014/05/12/beef-up-your-skills-wit...

1. Read & execute example code

2. Make something trivial or extend the example code

3. Read the documentation while doing so

Find a task and got on with it. I find it easier than playing, need something real to work with.

I'm not a massive fan of frameworks, even though I helped develop one myself http://were.cat-v.org

I build something with it and ask a lot of questions along the way. I assume the first thing I use it for is going to kind of suck, so I try and revisit the code to understand what's wrong and what should be done better.

For me, a combination of books and building a real, substantive app works best. I was actually in the same boat as you a couple of months ago. I have significant experience with Ruby/Node, and studied C++/Java in school. I decided to tackle learning Objective-C/iOS from scratch, and it only took a month of part time work to get to a point where I could build some pretty cool things. I documented that process from day 1, when I received the books:

https://giveit100.com/@marbemac/9r2pkz

Written material only.

Conceptual overviews (if one is available) -> tutorials -> exercises -> make a small thing -> make a bigger thing

Start a small project.

When I want to learn a new language/framework/technique/etc. I pick a side project and write that new project with whatever I'm trying to learn. There's no shortage of reference material on the internet to assist with this, and I think there's really no substitute for this method.