Before starting to learn a new programming language you should take a few considerations. How different is the new language from your current one? Compare the envivornment, paradigm, syntax, and level of automatic operations between the languages.
Tim Ferris wrote up twelve rules for learning a a new language. His rules were for a spoken language but they can also be applied to programming languages.
Episode Breakdown
12:12 Pareto Rules
Pick the most commonly used constructs you see and master those before learning all the edge cases. The best way to do this is just build something, and learn what you need as you need it.
“That’s your first goal to be able to do something useful”
Look at online code samples from places like github to see what things are most commonly used. Think how bad the worst employed programmer in a particular language is, then realize that’s only bad if you stay there. Otherwise it’s a good starting point.
14:37 Learn Cognates
Learn structures that are the same in the new language as they are in the old. For Loops, for instance, are very similar in many C-Based languages.
15:55 Use the Language Daily
“I probably spent a good 3-4 months adding to it.”
Code katas and online samples are best for this or build a small app, working on it daily.
17:51 Practice in an Uncontrolled Environment
Take your daily code kata, and try to modify it differently every day. They call this a henka in Japanese martial arts. Continue building a small app and just debugging.
21:13 Find Forums for the Language in Question
Reddit tends to be good for this. Look at top trending questions on stackoverflow. Look up “Language [your language here] sucks” on google and read the articles.
22:08 Use Your Experience with Other Languages
“The benefit of the design patterns is they are for all object oriented languages”
Infer things about this one from your other languages. Structures are the same across languages. If you want to loop through a list, for instance, you need the list, an iteration variable, and some sort of looping structure, as well as some way to tell when you are done.
25:45 Embrace Mistakes
“This is really hard to do especially for programmers as we like to be the smartest people in the room”
Make mistakes. You’ll learn more, faster, from fixing a screw up than you will correctly following all steps in a tutorial.
28:53 Create SMART Goals
Pick goals that you know you can achieve.
- Specific
- Measurable
- Attainable
- Relevant
- Time-Bound
32:38 Jump from Basic to Mastery
Get your code in front of others and invite criticism and correction. Practice a ton until simple things are second nature.
“If you don’t know how to do it type it and then eventually you’ll get to the point you don’t need the crutch”
38:31 Use the Idioms and Conventions of the Language
“I can tell when you switch from writing C# to JavaScript”
Don’t write javascript in C#. Write C# in C# and javascript in javascript. If working in a team, structure your code like the team’s code. It will make it easier for them to reason about if there are problems.
43:10 Don’t Switch Languages Too Early
At some point, the language will get on your nerves in a major way, and you’ll miss your first language. Getting past that is how you get better. Don’t be the person who can write “hello world” in ten different languages. That person is unemployed.