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

[nemild]

Background: I've been coding off and on for 2+ decades, starting from BASIC to C/C++ to Rails/Node. Languages and frameworks change quickly, and I'm still not thrilled with the resources available to learn as an experienced developer. For example, I'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/C++, Rails, Node.

My challenges with existing tools:

- Books are pretty verbose and don't do a great job covering popular libraries (e.g., the top NPM/CocoaPods/Gems that are part of so many startup products)

- A ton of articles + samples online are designed for novice programmers approaching a language

- Online videos are super slow moving (even when you speed up playback)

- Progressively more difficult sample code would be great - but it's hard to find the right progression and most are missing the annotation that explain the vagaries of the language or framework

- Perusing reference docs for the purposes of learning is too 'exhaustive search' (e.g., why isn't there a doc for say underscore.js that rank orders functions by incidence of use)

I'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/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.

[slantedview]

Well said.

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

[cujo]

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

[aaronem]

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

[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

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

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