Ask HN: As an experienced dev, how do you learn a language/framework quickly?

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!

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.

The hardest part is to get started. Start with hello world and build up from there. Trying, failing, asking, succeeding is what you need to do first. Since you're already experienced. You won't have to learn concepts like pointers which can be hard to grasp at first.

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.

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)

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

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.

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.

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!

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.

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.

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.

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.

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

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/

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.

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 make things with it

Start a small project.

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

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.

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

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.