
Ask HN: As an experienced dev, how do you learn a language/framework quickly? - nemild
Background:
I&#x27;ve been coding off and on for 2+ decades, starting from BASIC to C&#x2F;C++ to Rails&#x2F;Node. Languages and frameworks change quickly, and I&#x27;m still not thrilled with the resources available to learn as an experienced developer. For example, I&#x27;m confident that I should be able to do a fair bit of iOS development with a week or two of hard work given my knowledge of C&#x2F;C++, Rails, Node.<p>My challenges with existing tools:<p>- Books are pretty verbose and don&#x27;t do a great job covering popular libraries (e.g., the top NPM&#x2F;CocoaPods&#x2F;Gems that are part of so many startup products)<p>- A ton of articles + samples online are designed for novice programmers approaching a language<p>- Online videos are super slow moving (even when you speed up playback)<p>- Progressively more difficult sample code would be great - but it&#x27;s hard to find the right progression and most are missing the annotation that explain the vagaries of the language or framework<p>- Perusing reference docs for the purposes of learning is too &#x27;exhaustive search&#x27; (e.g., why isn&#x27;t there a doc for say underscore.js that rank orders functions by incidence of use)<p>I&#x27;d love to hear what the HN community does - with a focus on learning a language + framework by experienced engineers for the purpose of building startup products (i.e., not simply for the purpose of becoming a language&#x2F;framework expert but rather to build something as quickly as possible).
======
NathanKP
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.

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

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

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

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

------
tptacek
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#.

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

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

~~~
eldelshell
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.

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

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

------
haberman
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](http://blog.reverberate.org/2014/02/react-demystified.html)

~~~
collyw
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.

~~~
bartonfink
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.

~~~
collyw
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.

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

------
peterjaap
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!

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

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

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

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

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

------
pnathan
\- 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.

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

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

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

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

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

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

~~~
sitkack
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](http://docs.racket-
lang.org/reference/debugging.html) and started to map out the transform and
flow of data through the system.

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

Example:
[http://ycombinator.com/arc/tut.txt](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.

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

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

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

------
brickcap
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 :)

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

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

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

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

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

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

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

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

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

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

------
nthj
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/](http://blog.codinghorror.com/learn-to-read-the-source-luke/)

~~~
d23
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.

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

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

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

------
k-mcgrady
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.

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

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

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

------
dave84
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!

~~~
sitkack
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.

------
eterpstra
I just happened to release an article about this today!
[http://flippinawesome.org/2014/05/12/beef-up-your-skills-
wit...](http://flippinawesome.org/2014/05/12/beef-up-your-skills-with-code-
exercise/)

------
dshankar
1\. Read & execute example code

2\. Make something trivial or extend the example code

3\. Read the documentation while doing so

------
SixSigma
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](http://were.cat-v.org)

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

------
marbemac
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](https://giveit100.com/@marbemac/9r2pkz)

------
coolsunglasses
Written material only.

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

------
halayli
Start a small project.

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

