What's the Best Way for a Programmer to Learn a New Language?

Andrei Alexandrescu, author of The D Programming Language:

First of all, I'd opine there is no "one best way" because the learning experience is very personal. However, I can tell what works for me and hopefully for many others.

I do three distinct activities when starting to learn a programming language. These are not sequential but rather intermingled.

First, I give a novel read to the archetypal "The XYZ Programming Language" book. (Each language has one, which shouldn't be hard to find.) By "novel read" I mean a cover-to-cover sequential pass (the same way one would read a novel) with no attempts to use a computer, take notes, read out of sequence, or do exercises. I just read the book to get a level of understanding of language's overall look and feel, computational model, and important concepts. The novel read helps actual coding activities by imbuing the reader with the general mood of the language and a passing familiarity with the main notions involved.

Second, I write code in the language. This is the one step that really has no substitute. Hopefully within the confines of an interesting small project, getting some work done in the language is at the same time rewarding and instructive.

Third, I read code - ideally good quality code written by the most prominent proponents of the language, such as the implementation of the standard library or of popular applications. While doing so, I pay attention to the idioms and good styles that the language espouses.

That should cover it. One wonderful thing about learning a new language is seeing how classical, immutable good-to-have principles (such as modularity, separation of concerns, information hiding) get reflected in that particular language; the learner gets good reinforcement and further understanding of these principles (or sometimes, sadly, an equally informative negative nudge when the language is lacking). Another thing, even more inspiring, is to discover how the particular ethos of a language creates its own ecosystem - good idioms, best uses, expressive constructs.

Katie Cunningham, author of Python Guide for the Total Beginner LiveLessons (Video Training):

Several times a year, I teach groups of people how to program in Python. These are absolute beginners. Many times, the first time they opened up their terminal or command prompt was that morning.

By the end of the class, they’ve learned enough to make a fairly robust program. They can save data, use files, make calculations, loop, and test for conditions. They know how to read error messages, and they’ve played with imports and libraries. I get one question, every time:

“Now what?”

At first, I told them to think of a cool project. Surely, they must know of one! No, everything neat they could think of had been done already. Or, they had an idea, but it was too big. They’d have to learn 3D animation, or advanced calculus, or a tricky API. Finally, I remembered the first project I had really undertaken on my own.  It was a loot tracker for a game. My friends and I wasted a ton of time keeping track of who got what spoils when we played together in an online game. I ended up making a simple app to keep track of possible loot, who could use it, and who had gotten the last cool item.

It didn’t make me millions. No one ever used it outside of our little group. But it taught me more than most classes could. I learned how to use databases and secure them. I learned about linking up forms and organizing my code. I learned how to maintain my server, and I learned how to upgrade my system without breaking my app.

The annoyances in our lives, as much as they make us grit our teeth, are also the best places to start. The fact that they exist means there is a void in the existing technology. Perhaps the bit of code hasn’t been written, or it’s prohibitively expensive. Perhaps it’s too clunky, or terribly behind the times. Whatever the case, it represents a place the student can start their journey, and create something that makes their life, and perhaps the lives of others, better.

Lauren Darcey, co-author of Introduction to Android Application Development: Android Essentials, 4th Edition:

The best way to learn a language—whether it's a foreign tongue or a new programming language—is immersion.

Reading a textbook is not enough. Writing an app that compiles and sort of runs is not enough. You need to go deep, and you need to explore broadly.

Start by learning the scope of the language, always asking yourself what the language or platform is capable of, what its strengths and weaknesses are, what it should be used for, and—just as importantly—what it shouldn't be used for. Accept that the syntax, rules and customs of this language may be different from other languages you are accustomed to—embrace this and you will more readily learn the intricacies of the language and work well with others who use the language.

Next, devise some application ideas that test this scope and allow you to put into use those very language or platform features you want to master. Implement those ideas from start to finish, if you can. That last 10% of effort, the polishing and debugging, is where a lot of programming language mastery occurs.  If you can take the time to review this work with others who know the language well, this is the time, but also try to keep your unique perspective as well, because you might have insights that others have missed.

After all, innovation often happens with fresh eyes.

Scott Dorman, author of Sams Teach Yourself C# 5.0 in 24 Hours:

To me, the best way for a programmer to learn a new language is a combination of things. The most important is to have a desire to learn it. Without that, you’re just “going through the motions” and chances are that you won’t excel in the new language. With that out of the way, you need to start with a good language reference (be it a book, an online tutorial, or another person) and draw upon your skills in other languages. While there can be significant differences between languages because of core libraries and syntax, the basic fundamentals are the same. A for loop behaves the same way in C# as it does in Ruby, but the code you write to accomplish it is going to be different. Once you have a basic understanding of the syntax and the core libraries available, start writing code. The best way I’ve found is to take a simple real-world application (or a small subset of one if that’s possible) and re-write it. Don’t just “port” the code, but actually take the time to rewrite the code using the new language concepts. The benefit is that you have both an actual working application and real code to compare against. When you’re done, you’ll have a new version of the application but, more importantly, you’ll have learned how to do things in the new language that a simple “hello, world” style application wouldn’t have taught you.

brian d foy, author of Effective Perl Programming: Ways to Write Better, More Idiomatic Perl, 2nd Edition:

A programmer best learns a new language by using it, over and over again, for as much as possible. Books and training can help, but there's nothing better than practice.

Matt Galloway, author of Effective Objective-C 2.0: 52 Specific Ways to Improve Your iOS and OS X Programs:

Learning a new language is tough, even for experienced programmers. Languages all have their own little quirks and best practices. Even if you know a similar language already, it can be hard to work out how best to do something in the new language. But there are ways in which you can alleviate some of the pain.

Read, read, read. The first thing to do when learning a new language is to read as much as you can. Pick up any book you can find about the language and read it. You can also often find excellent information on websites. Find blogs, technical documentation and tutorials that will help you understand the language.

Practice, practice, practice. The next thing to do is to practice what you have read. Set yourself tasks to create something using the language. It's best to start off simple and build up from there. One way to combine the practice with reading about the language is to find tutorial websites that guide you through using a language and its features. These will help you to learn from existing developers who have already gone through the learning curve.

Rinse and repeat the read and practice steps until you become competent. But never stop there. You will continue to evolve as a programmer if you continue to read and practice.

Doug Hellmann, author of The Python Standard Library by Example:

Learning a new programming language requires more than simply memorizing a few syntax rules. Just as with natural languages, each programming language encourages certain "speech patterns." Those patterns manifest in software written in the language through small-scale idioms in expressions or functions within the implementation, as well as large-scale design decisions covering aspects such as concurrency models and API design. To truly learn a language, you must understand all of these facets.

I have always found it easier to learn new skills by starting with a concrete goal for applying them, something beyond "I want to learn X." For example, in order to learn to use Chef to manage automated configuration and deployment, I have also had to learn Ruby. But "Learn Ruby" is a large and mostly unmeasurable goal.  What I really needed was to "Learn enough Ruby to create a Chef cookbook to configure my development environment."  That's a focused goal; completing a working cookbook would provide something demonstrably useful and a foundation on which to learn more.

My first step is always to do a little studying. If the only goal was have a new Chef cookbook, it would be simple enough to copy-and-paste some examples from the web. That wouldn't result in much learning, though.  Studying those same examples closely enough to understand what each section is doing takes more effort, but makes it easier to apply the same techniques to new problems.  Books and on-line resources are good ways to find descriptions of unfamiliar syntax. I spent time with both to learn about Ruby's code blocks, string manipulation, data structures like arrays and hashes, and the control structures like loops that go along with them. Those are all reusable building blocks, and important parts of the language.

Besides focusing your learning, a concrete project can be a testbed for experimenting with each new piece of knowledge, and a framework for comparing different approaches. After a few sessions, my cookbook could configure a development server reliably and quickly, but having a working program is not the end of the process. The next step is to review the working code, to look for ways to improve it by making it more idiomatic. Re-reading your research materials reinforces the information and lets you find new details that were missed on the first pass. Looking for new examples by refining searches with terminology from tutorials that prove helpful is a good way to add even more new knowledge. With a working example program, you can make iterative improvements, while being able to test that the results work as intended.

Learning takes work, but building something useful at the same time helps you focus your research and gives you a framework for understanding the new information. You gain the knowledge you are after, and something practical at the same time. The portion of Ruby I learned to work with Chef gives me a place to start as I continue to learn more about the language in the future.

Aaron Hillegass, founder of Big Nerd Ranch:

Every language has a hump at the beginning where you know nothing and don't know how to start. Getting over that hump requires a really good book or class. Once you are over the initial hump, the best way to continue to learn is to find someone to pay you to create solutions in that language. The final step to mastering a language? Teach someone else how to be effective with that language.

Cay Horstmann, co-author of Core Java, Volume II—Advanced Features, 9th Edition:

1. Have realistic expectations. You might learn enough French or Mandarin in 30 days to ask for directions, and you might learn enough of a new programming language in the same time to program a simple game. But it takes months or years to be truly fluent in the new language.
2. Learn a language that is really different from what you use every day. There are a dozen languages that look like Java, and it's not worth the trouble knowing them all. But learning Prolog or Haskell or Erlang gives you a new outlook on solving problems that will make you more creative in your everyday work.
3.  Focus on the soul of the new language, not the syntax. When you learn Ruby, pay attention to metaprogramming, not the semicolons or lack thereof. When you learn Haskell, tackle monads even though they make your head hurt. And when it does hurt, be patient and try again a few weeks later. And again.
4. Put the language to work in a project that interests you. And then practice the idioms of the language, staying close to its soul, instead of mechanically translating from another language. But only the idioms that make sense for your project.
5. Understand what goes on deep under the hood. How do continuations manage to go back to a previous point in the program? How do actors actually share threads? What exactly does Prolog do when it unifies and backtracks? And what is the computational cost of all these miraculous achievements?
6. Write and talk about what you learned. Write a blog article (and don't hesitate to delete it if you don't think it rises beyond what has been written before). Give presentations in our organization. Maybe even write a book. But don't call it "Mastering Language X in 30 Days" :-)

Danny Kalev, author of The C++ Reference Guide:

Three decades ago, you could master one programming language and stick to it for your entire career. Those days are gone. Contemporary software projects use 3-4 programming languages. In such multilingual environments your survival depends on your ability to master a new programming language quickly. What’s the ticket to a successful immersion?

Linguistic theory distinguishes between first language (L1) acquisition and learning a second language (L2). Whereas the former occurs in a natural setting, during the critical age (0-7 years old) and has very good chances of succeeding, L2 learning requires formal teaching (textbooks, exercises and exams), and a lot of skill. Even after years of meticulous practicing, the results never compare to L1. Learning a programming language is similar to learning L2. To increase the chances of successful migration, here are a few guidelines that should make the process smooth and effective.

Similarity Isn’t Identity
It’s tempting to assume that a feature with a similar name works exactly in the same manner in the target language. This is rarely the case, though. Take inheritance for example. Java, C#, Ada, Smalltalk, Objective C, and just about every other programming language these days supports this feature. However, don’t assume that what works in C++ also works for Java or C#, for instance. C++ lets you inherit from multiple base classes simultaneously (multiple inheritance), or explicitly define the base classes virtual (virtual inheritance). You may also inherit from a POD struct. Unlike in C++, other programming languages might not support multiple inheritance or inheriting from a type that isn’t a class. Internalizing such subtleties is critical to a successful migration. Pay attention to the tiny-yet-crucial details.

Give the Designers Due Credit
Newcomers often look for the “missing features” in the target language: Garbage Collection (GC) in C++ for instance.  Rest assured that C++ creators know that their language lacks GC – with reason. Instead of clamoring and signing petitions, it’s advisable to understand the rationale behind such design choices. In C++, a GC would violate a fundamental idiom known as RAII. Besides, it’s not required for other good reasons: you can use a smart pointer or simply allocate the object statically (what a brilliant notion!). Bottom line: learn the design philosophy of the target language, not just its list of features.

Distinguish between Implementations and Standards
It’s not impossible to come across a poorly implemented compiler or a shoddy IDE. They aren’t necessarily the committee’s fault, nor do they imply that the language per se is flawed. When learning a new programming language, it’s critical to distinguish between standard features, which every standard-compliant implementation has to support, and implementation-defined features, which may impress or disappoint you, but they aren’t part of the language’s specification. This leads me to the next observation.

Read the Documentation
Books, forums, online courses and friends are excellent sources for learning a target programming language. However, at a certain point you’d want to go straight to the source: the official standard itself. It’s not exactly the kind of book to entertain you during a long flight, but it could turn a typical industrious programmer into a guru. Give it a try – read the manual!

Jennifer Kyrnin, author of Sams Teach Yourself HTML5 Mobile Application Development in 24 Hours (Learning Kit):

This really depends upon how the person typically learns, but I've found that practice works best for me. I used to believe that I learned best by reading books and websites about a language, but sitting down and building an application or website using the new language is what really cements it in my brain. 

The trick here is to come up with something real to build. It's easy to blow off something that isn't really important and creating yet another "Hello World" program might get you started, but I don't think anyone, least of all the student, cares. And it's hard to learn something if  you don't care about it. 

By attaching something you do care about to the learning of the language, you transfer some of that care from your project to the language. For example, the first time I set out to learn Drupal templating, I was just reading a book, and had set up a test site about my cat. I worked on it for about two days and got bored. The second time I tried, I had a specific project in mind that I knew Drupal would be ideal for, but I didn't want the site to look like every other Drupal site out there. I cared a lot about the existing site, and wanted the redesign to succeed. Because of this, I was more motivated to learn the templating and it was a lot easier. Is there more I need to learn? Always, but now I'm motivated to learn it because I need to keep that site looking good.

Eric Lippert, author of Essential C# 5.0, 4th Edition:

It's not much different from learning any new skill. You can read books, find a private tutor, take a class, form a study group, study examples, watch experts while they work, ask questions of experts, or jump right in and try it. Of course most people learn new skills by combining several of those techniques. That said, I wouldn't recommend learning how to ride a motorcycle from a book, or by just jumping on the first motorcycle you find and trying it!

Here's what works best for me personally when I'm learning a new language:

First: find a tutorial web site with simple "hello world"-style examples, to get the flavor. I want to know: is the language verbose or concise? Imperative or declarative? How does it use whitespace and punctuation? What characters and words appear to have special meanings? What are the basic building blocks?

Second: install the development environment and run the "hello world" program. Succeeding early is positive reinforcement, and lets you know if your tools are configured properly.

Third: obtain the FAQ and (annotated, if possible) language specification. Not to read it cover to cover! I keep the spec handy so that when I make a mistake or need to understand the precise meaning of a particular programming language element, I have it right there.

Fourth: pick a few problems I can solve in C# and try to solve them idiomatically in the new language. Sites like codereview.stackexchange.com are great for this; there are lots of people there who can show you how to make Python programs more "pythonic" or how to make your F# program look less like it was written by a C# developer.

Fifth: practice, practice, practice.

Finally: as I've mentioned before on this site, one of the best ways I've found to improve expertise is to find a good source of questions on the topic. If I don't know an answer, I research it until I do. But of course by the time you reach this level, it's not a new language to you anymore.

Mark Michaelis, author of Essential C# 5.0, 4th Edition:

The optimal way to learn a programming language is A) to code in it and B) to unit test what you code.

Like pretty much anything, you can’t simply sit down and read a book and suddenly transform into an expert on the topic. There needs to be a significant amount of application to real world experience for the information you read to become knowledge. So, whether following a book, an online tutorial, a video, or just trying to solve a simple problem – open up a code editor and start coding. In the process of coding, there are a few key principles to keep in mind.

Keep it simple. The focus is not in how much functionality you create, but in learning.   Therefore, minimize how much you leverage with automatic code generation tools and wizards, keep your problem space simple, and avoid pulling in a hundred open source frameworks. For example, rather than programming a three-dimensional, multi-player, distributed tic-tac-toe game, consider instead just writing a method that returns a string that could be used (at some point later on) to display the tic-tac-toe hash. Yes, it is simple and yes, it isn’t likely to win you a date at the next geek-a-thon, but keep it simple.

Focus on one language feature at a time, taking on new language features progressively. For example, learn about how to write methods before you take on understanding classes. And rather than tackling multi-threading, first understand lambda expressions if the language you are learning depends on the latter in order to code the former.

Find a mentor to review your code. Be careful not to allow them to tempt you away from your simple code but, within the constraints of what you know so far, get feedback on what you wrote.

There are numerous naysayers regarding testing-- at least stringent testing--while learning a language. However, I find that unit testing as I get up to speed incredibly helpful. At first, unit testing may simply mean writing out an assertion to the screen – perhaps in line with the very code you are writing. As I get more familiar with the language, perhaps a failed assertion could be in red, the program could beep, or even produce the equivalent of throwing an exception. Regardless, I find writing little tests (keep it simple still) around each language construct I am focusing on to be extremely helpful. It verifies my understanding of the construct and, more importantly, exposes my misunderstanding.

Using the same approach to learning an API is invaluable. I believe this so strongly that as I learned the .NET Framework, I set up test projects corresponding to each assembly I was learning and wrote unit tests for the APIs that I was looking to leverage. What was especially useful about this approach was that at a later time, when I had to refresh my knowledge of the API, I could just look over the unit tests – possibly filling in the holes in areas where a deeper understanding was needed.

I wish I could say , “just read my book!” (assuming C# is the language), but the reality is that it isn’t as simple as that. My book will certainly simplify your experience and expedite your learning, but it isn’t enough on its own. The value of a book is the ability to go at your own pace in a carefully thought out, progressively more complex fashion (where I put the most significant effort for my books), building on a strong foundation of earlier constructs in order to comprehend the later ones.

However, at the end of the day, what’s it going to take is to Just Do It!! … start programming and unit test as you go.

Rebecca M. Riordan, author of Fluent Entity Framework:

Here are three tips for learning a programming language fluently:

Of course it’s important to learn the syntax of the language you’re studying, but the truth is that our brains aren’t very good at remembering isolated facts. So while you’re learning each bit of syntax, make sure you pay attention to how those bits fit together. The if, immediate if, and switch statements (whatever keyword the language uses for them) aren’t independent things—they’re all ways of executing some code conditionally, while do and for are ways of executing some code more than once. And both of those sets are commands, which are kind of like verbs. Variables and constants are kind of like nouns.

Make those connections and you’ll not only be making easier to learn this language, but also be building scaffolding that will make it easier to learn the next language, and the one after that. And, even more important, when you sit down to program, you’ll be able to ask yourself, “Which is the best loop statement to use here?” instead of always using a for loop because that’s the only one you remember.

Chances are you’ll be working through a tutorial that gives you some exercises to do for each bit of syntax it introduces. That’s important, but it’s also important to be working on a project that you want to build for yourself at the same time—it helps your brain pay attention. So before you start, pick a simple project or two and work on them at the same time you go through the tutorial.

You’ll probably wind up throwing out most of what you do as you learn more, and you may find out that what you thought was going to be simple really isn’t, but that doesn’t matter. What matters is that you’ll be making some decisions (and thinking hard) about what you’ve just learned, and that will help make it stick.

If you speak more than one human language, you know that while lots of things can be translated directly, lots of things can’t. “Apte á etre lié” may literally mean “fit to be tied” in French, but it’s not going to tell anybody that you’re angry. Programming languages develop idioms like that, too. JavaScript programmers use a lot of lambda expressions, but they’re pretty rare in Visual Basic. C# programmers like to stick everything but the kitchen sink directly inside a for statement, and that’s not even possible in most languages.

Throughout your career, but especially when you’re first starting out, you’ll look at a lot of code written by other people. Pay attention to how the pros in your chosen language think about the problems they’re solving. It might just be convention, but chances are that there’s a good reason for tackling the problem that way—it’s easier to read and maintain, or its more efficient. You might want to do things differently (caveat emptor: not all code on the Internet is good code), but learning the standard idioms will make it easier to learn from other programmers and for other programmers to learn from you.

Erica Sadun, author of iOS Auto Layout Demystified, second edition:

Study by doing. Programming is a skill best learned by practice. The deepest understanding is gained from setting yourself tasks and mastering them through the new language. While program design is a top-down process, moving from intent to detail, learning a programming language is bottom-up. You immerse yourself in the bricks and mortar, working to build up understanding from the language fundamentals. Sites like Project Euler (http://projecteuler.net) offer terrific starting points. You revisit familiar algorithms, expressing them in your language's new ways.

Learn to search. You need not re-invent the world every day. A strong grounding in search enables you to find the language-specific and system library solutions that already exist for whatever project you're working on. No matter what problem you're facing, someone has probably already solved it for you: "How do I concatenate strings in Objective C?" "What's the right way to read a file with Java?" No matter what language extension, API, or construct you think you might need, it's probably already there -- whether in the language itself or in popular libraries. Learn to find information in your design environment's onboard documentation and on the Internet at sites like Stack Overflow (http://stackoverflow.com).

Find samples. Every programming language has dialects. I'm not talking about Objective-C vs C++ vs C. I'm talking about the way you write your code in your applications. Most languages have accepted ways of expressing common tasks. A critical part of learning a language involves spending time learning how others are using the language. The sooner you adopt dialect norms in your code, the quicker you'll be able to ask for help from others in ways that focus on your problem and not your coding skills.  Look up examples of your new language in open source projects on sites like Github (http://github.com) and read through them to move beyond keywords and functional definition to expressive fluency.

Learn the IDE and debugging tools. Mastering a new language is rarely just about syntax, symbols, atoms, and semantics. Many languages live within bigger design environments. Part of your learning task involves how to negotiate that environment to build and deploy your products. Always allocate time to explore the tools, documentation, and features that will support you in your daily work. Even if you're just learning a simple language for fun -- a scripting language for example -- recognize that that language often exists within a larger environment.

Reach out. Participate as soon as you can in forums and on irc. Servers like irc.freenode.net offer many language peer support chat rooms. Don't just ask questions. When you can, try to answer them. Exposing yourself to other people's problems will help you learn what language areas you're still weak in. Explaining the language to others strengthens your understanding. Just make sure you know how to ask questions effectively. Here are four must-visit sites you need to read through before participating in any programming forum or chat room:

• http://mattgemmell.com/2008/12/08/what-have-you-tried/
• http://www.mikeash.com/getting_answers.html
• http://www.catb.org/~esr/faqs/smart-questions.html
• http://www.codinghorror.com/blog/2012/03/rubber-duck-problem-solving.html

Robert Seacord, co-author of Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs:

By programming in the language. Learning to program is a bit like learning to drive; reading about it only takes you so far. The difference is that you can’t kill someone while learning to program; that requires experience. Reading and studying the language, combined with continual experimentation, is more important to master programming in a language. The C and C++ programming languages, for example, have many undefined behaviors for which the compiler can do anything; for example, go off and play the game of life. More commonly, compilers for these languages will optimize your code by assuming that undefined behaviors can never occur and silently eliminating code that you presumably wrote for a purpose. Experimentation is insufficient in these cases; just because a compiler doesn’t optimize an undefined behavior now doesn’t mean it won’t in the future. Security is another area where reading, study, and contemplation are necessary. Many coding errors that result in exploitable vulnerabilities are completely undiagnosed by compilers and static analysis tools and have, on occasion, remained undetected (by the developers) for as long as a decade.

Bjarne Stroustrup, author of A Tour of C++:

That depends on both the programmer and the language. Consequently, the best way involves a Mentor who knows the programmer well and is an expert in the new language. That’s a luxury, we rarely have. So many go to the web, where good advice is plentiful, but it is not easy to tell good advice from the far more plentiful harmful nonsense. Naturally, experienced programmers manage, and they already have developed a way of learning new languages. That’s part of being experienced. My way involves a good book about the language, a fair bit of experimentation, and talking to people who knows what idiomatic code in the new language looks like. I follow the flow of the book, rather than just picking and choosing what looks interesting in some random order. A good author communicates concepts and style, in addition to mere facts. The typical mistake when first approaching a new language is to write in the style of some older language: “You can write Fortran in any language” and in C, and in whatever.

For experienced programmers approaching C++, I recommend my “The C++ Programming Language” (4th edition), which aims for mastery, or—if you are in a rush—the very thin “A Tour of C++,” which aims for an overview (only). For novices, I recommend my “Programming: Principles and Practice using C++,” which was written for freshmen university electrical engineering and computer science students. What is common for my books is that they assume the reader to be reasonably smart and willing to work to learn. I try to avoid oversimplification and sugar coating: programming can be a noble art and involves some skilled craftsmanship. I hope for readers who want to build real-world systems, rather than just toy programs to be able to get a grade or to tick a box on an interview form.

Stephen Walther, author of Windows 8 Apps with HTML5 and JavaScript Unleashed:

Buy a book. A book enables you to learn the most important stuff fast.

Next, build the same app using the new technology twice. Build the simplest possible app in the ugliest possible way with the goal of just making it work. Erase your code. Start over. Build the same app again with more elegance. There, now you have learned a new technology.

James L. Williams, author of Learning HTML5 Game Programming: A Hands-on Guide to Building Online Games Using Canvas, SVG, and WebGL:

My strategy has usually been one of two tactics: "Go with what you know" or "Jump in the deep end."

By "go with what you know," I don't mean that you shouldn't learn new languages, but instead take a project you coded previously and know really well how to reimplement it in the new language. It should be small enough to complete in an afternoon or two, but big enough to give you an idea on how the new language handles key programming concepts like looping, objects, and advanced data structures. Your familiarity with the source material makes it faster to port and helps cement the connections that language X implements this concept in a different or similar way to language Y.

If you have more time on your hands, you can select some tool or widget you always wanted to do and implement it in the new language. If the new language is just for fun with no deadline, I'll follow the first tactic with this one, as porting a project gives you focused skills for that specific project. Jumping into a project where you don't yet know the final design and that you have never done in any language will make you dig deeper and give you more general purpose knowledge.

Sharon Biocca Zakhour, co-author of The Java Tutorial: A Short Course on the Basics, 5th Edition:

I don't often learn new programming languages but, as a writer for the Java programming language, I am frequently presented with learning new, cutting edge, Java technologies.

I like to learn a new technology by writing a series of simple examples. I learn best with hands on experience and don't want to read a tome, or a technical specification, before trying something out. It works best l when I can think up small examples that are interesting to me.  Starting with the simple and working through more complex examples can be fun, is very educational, and hurries my learning curve.