Ask HN: Experienced programmers, how do you learn new language?
10 comments
Build something with it. More specifically, need to build something with it.
I learned C by writing a video game using it (so far in the past that it was the only real option for games).
I learned VB by taking a job at a shop that used it, then C# when that shop migrated to .NET.
I learned Ruby because that was the best maintained AWS library back in 2006, and my stuff was failing due to things their C# libs couldn't yet fix.
I learned Python by taking a job building a site with Google AppEngine back when Django was its framework of choice.
I recently (re-)learned Java by taking a contract gig at a java shop.
It helps if there is some code already written, so that you can see what things are supposed to look like and get a feel for how things work in that language. I find that I can drop in to a new codebase in an unfamiliar language and make meaningful contributions on day one, if there are bugs that need fixing or simple features that need tacking on.
Talking with other devs, it sounds like my experience is pretty typical. A straw poll showed that nearly half the devs on that Java gig were C# guys who either had never used the language or hadn't touched it in years. We all got bit by (myString == "whatever") never returning true at least once, but for the most part it's just computer programming. Once you know how to do that, the language itself isn't too important.
I learned C by writing a video game using it (so far in the past that it was the only real option for games).
I learned VB by taking a job at a shop that used it, then C# when that shop migrated to .NET.
I learned Ruby because that was the best maintained AWS library back in 2006, and my stuff was failing due to things their C# libs couldn't yet fix.
I learned Python by taking a job building a site with Google AppEngine back when Django was its framework of choice.
I recently (re-)learned Java by taking a contract gig at a java shop.
It helps if there is some code already written, so that you can see what things are supposed to look like and get a feel for how things work in that language. I find that I can drop in to a new codebase in an unfamiliar language and make meaningful contributions on day one, if there are bugs that need fixing or simple features that need tacking on.
Talking with other devs, it sounds like my experience is pretty typical. A straw poll showed that nearly half the devs on that Java gig were C# guys who either had never used the language or hadn't touched it in years. We all got bit by (myString == "whatever") never returning true at least once, but for the most part it's just computer programming. Once you know how to do that, the language itself isn't too important.
If you want to become an experienced programmer in a new language you have to pick up the big thick books and apply what you learn while reading them. Online courses are nice but they do not go into the depth that the 700+ page books go into. If you go by courses alone you will always be one of those engineers that has a spotty base foundation and will never truly become an expert due to missing out on something huge that was not covered in an online course.
If you want a good course go for the courses that have 35+ hours of content and go through everything. Remember you are a beginner in the new language so skipping anything is not advised as you might miss out on something important that the experienced engineer is laying down in the course. They normally learn the material they build from the courses from the big books and take bits and pieces of what the books have to condense them down into something a little more light weight.
As when you are sitting at the day job and have over 1 million lines of C and C++ code to go through you really have to have a good grasp on the basics and hard parts of the language to be really effective. Being a junior engineer on the most important project a company has requires some serious reading and implementation time on and off the clock to understand what is going on.
The best part is if the more you dive into the big books the faster you will be able to read them and apply what you learn and profit from that new knowledge. Things really come together when you are able to use knowledge of the base languages (C, C++, Rust, Go, etc.) to help troubleshoot problems in the higher level languages that may pop up as engine errors (PHP, Perl, Ruby, Python, Java, C#, etc.)
Just remember there is no shortcut to becoming a truly experienced engineer. Some point you will have to pick up the big books and dive deep and implement what you learn. Those that do not do it normally reach a plateau in their growth until they take the plunge into the big books, code/developer documentation, etc. and to understand it you have to also implement it and work with it on a daily basis.
If you want a good course go for the courses that have 35+ hours of content and go through everything. Remember you are a beginner in the new language so skipping anything is not advised as you might miss out on something important that the experienced engineer is laying down in the course. They normally learn the material they build from the courses from the big books and take bits and pieces of what the books have to condense them down into something a little more light weight.
As when you are sitting at the day job and have over 1 million lines of C and C++ code to go through you really have to have a good grasp on the basics and hard parts of the language to be really effective. Being a junior engineer on the most important project a company has requires some serious reading and implementation time on and off the clock to understand what is going on.
The best part is if the more you dive into the big books the faster you will be able to read them and apply what you learn and profit from that new knowledge. Things really come together when you are able to use knowledge of the base languages (C, C++, Rust, Go, etc.) to help troubleshoot problems in the higher level languages that may pop up as engine errors (PHP, Perl, Ruby, Python, Java, C#, etc.)
Just remember there is no shortcut to becoming a truly experienced engineer. Some point you will have to pick up the big books and dive deep and implement what you learn. Those that do not do it normally reach a plateau in their growth until they take the plunge into the big books, code/developer documentation, etc. and to understand it you have to also implement it and work with it on a daily basis.
Well, not your fault, most of the resources out there are just made to make a buck, or a click, it's pretty much hopeless nowadays. What I do usually is I try to find used books, they're cheap and often better. Doesn't work for all subjects obviously.
For C++, I'd download a working draft of the standard, that + examples on stackoverflow will teach you more than a 6 foot stacks of the latest books on the subject.
For C++, I'd download a working draft of the standard, that + examples on stackoverflow will teach you more than a 6 foot stacks of the latest books on the subject.
Get a dev environment set up so that I can try things.
Read a quick tutorial
Start writing code and googling the things I get stuck on
You can often find X for Y Programmers, e.g. C++ for Python Programmers that might be a good fit, though I can't say I really used any. I asked my coworkers some dumb questions when I got started about compile errors I couldn't figure out which helped.
I definitely wouldn't watch videos, as you say, it's really hard to find the bits that you need to know in video.
Read a quick tutorial
Start writing code and googling the things I get stuck on
You can often find X for Y Programmers, e.g. C++ for Python Programmers that might be a good fit, though I can't say I really used any. I asked my coworkers some dumb questions when I got started about compile errors I couldn't figure out which helped.
I definitely wouldn't watch videos, as you say, it's really hard to find the bits that you need to know in video.
Yup. For me, actually forcing myself to build something and not just follow a simple tutorial step-by-step is where the real learning is. You can feel yourself getting better every time you Stack Overflow something.
If it's similar to a language I already know, I grab a quick-reference guide and start coding. If it's not similar to a language I already know, I read an essay (preferably by the creator of the language) about the design philosophy, then grab a quick reference guide and start coding.
C++ is kind of an unusual case -- it's part of that rare class of languages that are so bloated that they can't be 'learned' per-se, because nobody can keep the entire core language in their heads. Luckily, it's a mish-mash of languages most developers already know: it's C with java-like "object orientation", minus the constraints against multiple inheritance, with a grab-bag of strange implementations of familiar features provided by the STL. So, it's possible to limp along writing almost-C or almost-Java and then consult documentation when you run into a difference.
I would recommend against tutorials. The best tutorials take you on an illuminating tour of the philosophy of the language with a handful of illustrations in the form of real code; a normal tutorial covers the domains the author thinks are interesting while totally ignoring everything necessary to solve the kinds of problem the reader needs to solve (which the author is totally unaware of); a bad tutorial is wrong or misleading because it's written by somebody who also doesn't know the language. The more popular a language is, the more likely any given tutorial for it falls into the 'bad' category. Courses have the same basic problems as tutorials, but are substantially longer. Push comes to shove, if you need code in context & there's somehow no code already on your machine in that language (which may be true of APL or Julia but is very unlikely to be true for C++), look the language on X in Y Minutes or Rosetta Code.
C++ is kind of an unusual case -- it's part of that rare class of languages that are so bloated that they can't be 'learned' per-se, because nobody can keep the entire core language in their heads. Luckily, it's a mish-mash of languages most developers already know: it's C with java-like "object orientation", minus the constraints against multiple inheritance, with a grab-bag of strange implementations of familiar features provided by the STL. So, it's possible to limp along writing almost-C or almost-Java and then consult documentation when you run into a difference.
I would recommend against tutorials. The best tutorials take you on an illuminating tour of the philosophy of the language with a handful of illustrations in the form of real code; a normal tutorial covers the domains the author thinks are interesting while totally ignoring everything necessary to solve the kinds of problem the reader needs to solve (which the author is totally unaware of); a bad tutorial is wrong or misleading because it's written by somebody who also doesn't know the language. The more popular a language is, the more likely any given tutorial for it falls into the 'bad' category. Courses have the same basic problems as tutorials, but are substantially longer. Push comes to shove, if you need code in context & there's somehow no code already on your machine in that language (which may be true of APL or Julia but is very unlikely to be true for C++), look the language on X in Y Minutes or Rosetta Code.
Assuming you know other programming languages it might be best to build something. I usually pick a small project I can get done in an afternoon or two that I could easily do in my language of choice and build that.
As an experienced programmer, its easier to go through quick tutorials and cheatsheets for a brief understanding.
Once you are comfortable, its better to hit the ground by building a small POC or a small project.
In my case, I learned languages and frameworks including React in a similar way. While creating a project in React, I came across advanced topics like Redux, GraphQL. I hit pause button and spend few hours looking in google on Redux and GraphQL. That's how I utilized my time in learning new languages or concepts.
Once you are comfortable, its better to hit the ground by building a small POC or a small project.
In my case, I learned languages and frameworks including React in a similar way. While creating a project in React, I came across advanced topics like Redux, GraphQL. I hit pause button and spend few hours looking in google on Redux and GraphQL. That's how I utilized my time in learning new languages or concepts.
1. Read the manual, or a suitable book. (C++ in particular has books for people with different starting points.)
2. For me, it helps to have an actual problem that I want to solve with the new language.
2. For me, it helps to have an actual problem that I want to solve with the new language.
I always like to start with a small side project to learn a new language. Google what you need to get the absolute minimal achieved. Keep this approach and you can stay focused to learn what is really important to get things done.
All the programming tutorials and courses out there are for absolute beginners. I can't bear watching a 15 min video that explains what scope is to get that 30 sec specific to c++ language.