Learning a new language takes a long time. Unless you need it for your job (or a personal project that's important to you), it's a bad investment. In this post, I'm going to show you why "learn at least one new language every year" is bad advice and what you should do instead.
Where did "learn at least one new language every year" come from?
As best as I can tell, this idea was popularized by Andrew Hunt and David Thomas in their book The Pragmatic Programmer (which is a great book, by the way).
In a section on investing in your knowledge they wrote:
Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting struck in a rut.
The quoted text was the first recommendation in list of things programmers can do to improve their knowledge. And it's a reasonable recommendation in the context of the book.
However, over the years, people have stripped that context away and turned it into something like this: "Learn at least one new language every year or you're not a good programmer."
And it's this twisted version that I want to talk about in this post.
Why it's bad advice
Programmers, especially beginners and junior devs, have taken this advice to heart. They are running around on the internet trying to figure out which language they should learn next and stressing about the fact that they don't know enough languages. But it's all a distraction and it's hurting people and results. Let me tell you why.
It sets up impossible expectations
Not only should you be reading blogs, writing your own blog, contributing to open source projects, networking with other programmers, working on exciting personal side projects, going to conferences, reading to keep up with the latest tech developments, and doing your actual job, you should also "learn at least one new language every year". Who needs sleep or a life, right?
New devs are almost always overwhelmed and they need help with the basics.
Do they understand how the projects they are working on deliver value to the business? Do they understand the code base? The tech stack? Can they make a useful code change that will pass code review? All these other professional development expectations are not helping new devs master the basics.
There are easier ways to broaden your thinking
Hunt and Thomas wrote that learning a new language helps broaden your thinking so you don't get stuck in a rut. But I can think of easier ways to broaden your thinking. You could:
- learn design patterns
- study architectural patterns
- look at open source projects
- talk to other programmers
- watch video lectures online
How much are you really learning if you are consuming programming languages in bulk?
I'm just a little fuzzy on the mechanics here. How are people "learning" these languages? Reading a book? Learning the syntax? Writing a "hello world" program? Duplicating a tutorial in the language? Writing a 1,000 line project?
In my experience, learning the syntax of a language is the easy part. If you want to write production quality code in that language you also have to learn the tools built around that language. That might mean you have to learn a new IDE. And you'll probably need to learn the frameworks and libraries for that language. And compilers, build systems, static analyzers, linters, where to get help, and how to assemble small pieces into bigger programs. Tools for testing, and on, and on.
That's a ton of work. Are people really doing all this stuff? I suspect lots of people stop somewhere between "hello world" and duplicating the code in a tutorial. And if that's the case, how useful is learning a new language?
But even if you do create a little project in your new language, I still question whether this is the best use of your time.
Language-specific knowledge is perishable
Suppose you invest the time required to really dig into a language and learn it deeply. How long will that knowledge remain useful if you don't use the language on a regular basis?
Four things are happening simultaneously:
- your memory for the details of the language fade every day you don't use it
- languages evolve
- the tools, frameworks, and libraries evolve
- best practices in computer science evolve
I learned Java 2 in university but a lot has happened in the last 15 years and I'm not sure to what extent I could even claim "I know Java" at this point.
You might need the language for a new job or project one day
If you learn a new language you can put it on your resume. It might help you get a job, right? Probably not.
Language/technology inflation is rampant on resumes.
I don't do much hiring but I ignore that stuff when I see it on a resume. I've encountered way too many people who claim expert knowledge of a language and then can't write a simple function in it during an interview. And if I'm ignoring that stuff you can bet that 99% of hiring managers ignore the list of languages on your resume too.
Could I be convinced that learning a new language required for a job you really want is a good idea? Maybe. If you frame it as "showing initiative," I might buy it. But even then, wouldn't your time be better spent practicing your interview skills? Or learning to negotiate a higher wage and better benefits?
The whole "learn a language in case you need it for a job one day" thing just strikes me as inefficient. How do you choose the right language to learn? How do you prevent your language-specific skills from degrading over time?
Read on for a better approach.
Focusing on high leverage skills with a long half-life is a superior strategy
Let's unpack this.
A skill is high leverage if it has a disproportional impact on the results you care about for the amount of effort you expended to get it. Learning how to learn efficiently is a high leverage skill.
A skill has a long half-life if it will remain useful for a long time. Leadership probably has a half-life measured in hundreds of years. But the newest JavaScript framework might have a half-life of a few months.
I'd encourage you to focus on learning the things that will best help you and your employer achieve outstanding results, with a preference for knowledge with a long half-life.
Here's a list of things that you might find more valuable than learning a new language:
- really learning your stack - get super productive
- your business - where are the high leverage places to apply your effort? What are the best problems to solve?
- how to learn efficiently
- effectiveness
- prioritization - Theory of Constraints, Cost of Delay, and CD3
- project management
- leadership
- communication
- time management
- teamwork
- business skills - strategy, hiring, negotiation, accounting, marketing, finance, sales, statistics, etc.
- build-measure-learn feedback loop as described in The Lean Startup by Eric Ries
- development methodologies/techniques
- design/architectural patterns
How to decide what to learn next
Find the highest leverage thing that will help you or your employer, learn that if you don't already know it, and then use that knowledge to improve the results of your company.
Then find the new highest leverage thing and repeat.
People who do this end up with impressive resumes full of outstanding results, which is what employers really care about.
At several points in my career, the highest leverage thing for me to learn had little to do with programming. This is especially true in small companies where you need to fulfill multiple roles. Don't be surprised if you find the same thing. Get into it; have fun. There are tons of interesting things to learn in the world besides programming.
Takeaways
You don't need to learn at least one new programming language every year to be a "good" programmer. In fact, chasing such a goal without good reason is silly.
If you want to learn programming languages as a hobby, go for it (I've done it myself). But don't expect it to have a huge impact on your career. This is a hypothesis you can test. Just ask your employer what kind of raise your company will give you if you learn [insert new programming language here]. If the answer is none, then you just established the market value of that language to your employer.
Key points: people hire computer programmers to help them solve problems, not for how many languages they know. The best programmers see the bigger picture and prioritize what they learn so that they can deliver the best possible results. It's always the results that matter.
Agree or disagree? I'd love to hear your thoughts in the comments section.
Top comments (44)
I enjoy learning a language every year. And I've been doing it long before The Pragmatic Programmer came out. Is it for everyone? No, of course not.
The majority of programmers I know have learned one programming language really well. Perhaps touched a little bit on others, but not enough to put on a résumé.
But this notion "Learn at least one new language every year or you're not a good programmer" is bogus. I entirely agree with Blaine on point!
I would not suggest that a new programmer should learn a new language every year.
For a new programmer, I'd recommend learning one language well (5+ years in it). Preferably, one that you can leverage to get a job and make money.
What languages can help you be gainfully employed? JavaScript, SQL, C#, C++, Swift, Objective-C, C, COBOL, or Java come to mind. (Yes, COBOL. Lot of companies still use COBOL, and their programming workforce is thinning out as their programmers retire.)
When to learn a new programming language?
I once overheard someone talking about how they know 60 programming languages and it was definitely with the implied and therefore I'm a super impressive programmer. Which might be true but he came off as an arrogant asshole.
I'm not sure I could name 60 programming languages.
Good safety tip! Something I need to take to heart, lest I fall into the same category.
Very good advice. Thank you for taking the time to share your thoughts.
Perl, Ruby, Opal, Crystal... Quarts? Zircon? Jade?
html, xhtml, xml, yaml, -> they all have language right in the name!
Quartz Zircon Jade Topaz Onyx Jasper Diamond Sapphire
It's crazy how many of them there are.
I was talking to my wife about this post and she said something along the lines of there being only a few programming languages. When I told her that there are at least several hundred languages in use with 30 or so making up the vast majority of the code, she got that 'programmers are crazy' look in her eye.
Yes yes yes one thousand times! Thanks Blaine! It's about time someone started thinking deeply about the unexamined "wisdom" wafting around the programming world. Often if you look past the face of these pieces of so-called advice, you don't find any substance. What possible benefit could learning a new language every year provide? Maybe the first three you learn will be beneficial if you pick dissimilar languages like Java, PHP, and Haskell, but after that there are other things a working programmer would do better to learn.
And I think you nailed it when you wrote, "I suspect lots of people stop somewhere between "hello world" and duplicating the code in a tutorial." The recent trend of a new JS framework every three months and an accompanying "to-do list" single page app springs to mind. How many to-do apps can you implement in how many languages, before you realize that you can't apply the principles you learn therein to real production applications in varying domains?
Great post and one I'll be sharing!
Thanks Scott. We live in a fast-paced world but I feel sorry for the devs just starting out who are really struggling with prioritization. The messages we (as a group) are sending to our newest members isn't very helpful and I just wanted to offer a different view.
In my opinion, "Learn a new language every year" is not bad advice if you don't translate it to, "Master a new language every year."
I think that languages (frameworks, libraries, databases, ...) are part of our world; casting a glance at them is OK and beneficial.
New languages tend to solve problems in different ways. They bring their lot of features that might make you reconsider the way you work using your main language.
It's like learning a foreign-language grammar and get a better understanding of your own.
I agree that there are other skills that matters more until you are fluent, but in the end a broader knowledge broadens your mind (and I think that it's perfectly OK to stop at a Hello World of some kind).
I think the post itself rather translates to “Learn a new language every year is bad advice if you don’t translate it to master a new language every year (which of course no-one can)”.
Maybe ... I still wanted to put forward a different opinion.
Maybe not entirely different (because I haven't learned a new language every year), but shed some light on the advantages of "just trying out" a new language with a Hello World! example.
Yeah, maybe.
Let me ask you this: imagine a group of programmers who you work with now or have worked with in the past. Now imagine they all worked for you in a company that you personally owned. Would you require them to try out a new language every year and pay them to do it? Do you think it's that important? Might it be true that some of your programmers would benefit more from using that time to learn something else?
I'm not sure that it's the right question to ask. What I would do is irrelevant.
Everyone has different sets of skills that make them individuals. With every new experience, we shape our vision of what we do.
I did some hiring in the past, and I might have hired someone because (as additional "talents") they were funny, because they liked board games, or because they liked reading.
People in my team have asked for training of many different kinds, spanning from computer languages to design, to communication skills. To this day, I've done my best to say yes whenever I could. I have also let them dedicate some of their time to whatever they liked. Not because I thought that they would, in a day, dramatically improve at programming, but because they would enjoy it and that in the end, it would benefit the company (and my team). To me, the key is to let people decide, and if they feel like learning a new language, I'm okay with it.
Now, let's focus back on languages. In my current company, we mainly use Java and PHP, but ... someone saved the day when he was able to tweak the swagger code generator (written in Scala), someone was able to save the day thanks to her go skills when she quickly wrote a program with parallel tasks, someone was able to save the day when he configured Jenkins using Groovy, someone debugged a PHP extension (written in C), and someone just had fun with colleagues showing them a game prototyped with Unity.
Are they "better" programmer? No.
Was it useful for the company? Yes.
Would I hire them "because they know five additional languages?" ? No.
They just happen to have developed an appealing amount of knowledge and skills, sometimes by learning a new language.
Yeah, I totally agree. And thanks for treating your programmers as humans; I'm sure they appreciate it.
I think it's the "... or you're not a good programmer" part where the concept go off the rails.
I agree. Not learning a new language every year doesn't make you a bad programmer.
Yes, Eljay-Adobe's correct. It's this pressure to do it just to consider your self a "real" programmer or a "good" programmer that bothers me.
Thanks for your comments.
This was incredibly helpful and alleviated the anxieties I get from all these Top n Programming Languages You Should Learn NAOW!!! which always seem to magically note that the language you're currently sweating over for hours upon hours is dying. That said, I was given advice some time ago to learn the language(s) that have influenced your choice (or your employer's choice).
I don't know how true or useful it is as a general rule but I have found clarity in playing with Smalltalk (recently) and Lisp, reading about the ideas that each bring and having it clarifying principles, idioms in Ruby. An example is that I've always found OOP just out of my grasp of full understanding. Borrowing a book by Sandi Metz and just working through some trivial examples in Smalltalk, reading where some of these OO conventions came from has helped - a lot.
However this still may fall into your Study Design Principles more than advocating for learning a new language. (I don't pretend to be an expert in either of those languages whatsoever).
I hear you, Luis. I've been programming in PHP for more than 15 years and people have been dumping on that language and predicting its demise the whole time. But it's still here and at my work we have no plans to switch away from it.
Uncle Bob's got a nice essay on his observations the correlation between programming language evolution and processor speeds: blog.cleancoder.com/uncle-bob/2017...
I believe people are going to be maintaining C, C++ Cobol, Java, etc., etc., for the foreseeable future. If you are a good programmer and know a language with a huge number of lines in production, you'll probably always be able to find work.
So carry on and don't worry about learning the newest language (unless you want to learn it, of course).
One a year is perhaps overkill, but the need to learn multiple languages should not be understated. You simply cannot become a good programmer unless you've done work in multiple languages, preferably ones that serve different domains, paradigms, and/or markets.
I think the sentiment of "one per year" likely comes from what may just happen during the course of a career. You won't likely master, or even signficantly use, all those languages, but you'll certainly be exposed to a lot.
If I look at the languages I've used, somehow, over my career it probably works out to about one language per year -- depending on what you consider languages. Very few of these I set out to actually learn though, most of them just happened to appear in my work, or hobbies, and I picked it up as I went.
That's a pretty strong statement. Is there a chance that you're confusing correlation with causation? "Lots of good programmers know multiple languages, therefore you must know multiple languages to become a good programmer?"
That sentence sort of makes sense when you say it but if you replace a few words but keep the logical structure, it doesn't sound right: "Lots of great athletes own multiple houses, therefore you must own lots of houses to become a great athlete."
In other words what if knowing multiple languages is an effect of being a good programmer, not a cause?
There are a variety of different ways to approach programming problems. Different paradigms and different methodologies. Each language and tool tends to specialize, or cater to a different approach. If you stick with a single language, or single tool, you'll simply not be exposed to these other approaches.
You'll be missing significant programming knowledge. Thus it's not correlation; it's causation. Until you actually use these other languages and tools you'll continue missing this knowledge and thus won't be a good programmer.
You could however be on the path to being a good programmer. One obviously has to start somewhere, and it's still to say that if you know only one language you have to be a bad programmer. It's not like I'd ever actually evaluate somebody based on the number of languages they know. Maybe I will meet somebody that impresses me one day and only knows one language.
I've never met a good programmer who didn't know multiple languages so you may very well be correct. But I'm still interested in the correlation vs causation question.
Anybody know of research pointing either way or know a good programmer who only knows one language?
Maybe we won't count SQL, HTML, XML, etc. as languages. So someone who does web dev and only knows PHP would count as knowing only one language?
I do consider all of those languages. I've written a series of articles about various paradigms.
Indeed, I'd say somebody who's done modern web development, full stack, who claims to only know PHP is most likely incorrect. Each of those you mentioned, like SQL and HTML, and let's also include JavaScript, and if we're generous: CSS, those are all different ways of looking at a problem. That's exactly what I'm after when I want people to learn other languages: these other approaches to solving a problem.
Now, it's quite possible to hack around in all of those and get a site working without really understanding why. Or it's quite possible to over-apply PHP and ignore all those other bits. Thus simply using these bits isn't enough to be a good programmer, but truly understanding all the bits probably is.
I'm surprised by how often you and I seem miles apart when we first comment on something but then when we peel back the layers, and maybe define some terms, we end up pretty close to each other.
Cheers.
Great post, this is a really good reminder. I often feel a fear of missing out by not learning the next hot thing. Ironically, learning how to use Linux better has been one of the most effective uses of my time for being more productive at work. Going back to the basics is important!
That's so true! If your application runs in a Linux environment, spending a little time over at tldp.org pays dividends!
As a PHP Developer, learning Linux/Unix commands and philosophy has been a real boon for my development speed.
Thanks for your comments, Andrew.
You've helped me make my point. You surveyed the landscape and chose to learn Linux because (I assume) you thought it would help you. That's excellent.
While learning a different language every year does not preclude you from being a good programmer, I think that not learning new languages whenever you can does make you less adaptable and more reactionary.
I have 10+ years of Java experience, but without learning other languages I would not have learned some key things about development: (Now please note, that I don't claim expert knowledge, but I know enough to follow along and google anything I'm missing.)
Here's a vague summary of what I gained from each (alphabetic, not timeline):
But the main thing I gained from all this is that the primary difficulty in learning new languages is changing paradigms the first time. Once you've done that, you realize that the Algol family tree is so similar as to be identical when compared with the LISP family. (And when you get a little comfortable with Prolog, you learn that there are still worlds to conquer and wilderness to explore!)
I understand that it's difficult to leave the comforts of familiarity, but I'm here to tell you that if you could do it once (to learn ANY programming language) you can do it again. If you "fail" to learn a language, you lose nothing! In fact, you probably will learn something about yourself if you are paying attention. And that's the key takeaway for "learn a new language every year". You don't have to reach the summit [of mastering a language], you just have to keep striving to learn new things.
Now I will suggest some baby steps to get you on your way to learning a new language:
Anyone have any more ways to encourage getting used to slow progress and systems appreciation?
Nice comments, Jon.
I think it really depends on what you did instead of learning that new language. That's was my whole point in writing this post. If you have x hours to learn something new, what's the thing that will give you the biggest bang for your investment? Maybe it's learning a new language but it just might be learning usability testing, or conversion optimization, or statistics, or any of a million other things.
I agree with one important caveat. Every developer should know more than language/product at each part of the stack well, and have built a non-trivial project in it, not to check items off on their resume, but to broaden their understanding.
In my experience one-trick ponies tend to be blind to the limitations of their preferred platform and often unnecessarily opinionated. If you love Ruby on Rails, go build something in Django or Node. If you like Angular, go try out React or Vue.
Every language and platform has its strengths and weaknesses and it's important to know both. In fact, one of the questions I ask people in the pre-interview screening is: "What's your favorite platform. What are three things you like the most about it? What are three things you dislike the most about it?". The best developers tend to have solid answers for both halves of the question.
Of course, once you have enough exposure to different ways of doing things, there are greatly diminishing returns.
I'm not arguing against learning multiple languages or stacks.
Everyone has a limited amount of time to devote to learning and all I'm proposing is that people think about what would benefit them the most and learn that instead of blindly following something misquoted from a book written almost 20 years ago.
I didn't think you were, I just wanted to explicitly make the point that learning a second language is hugely beneficial. I agree that trying to learn one every year is pretty misguided.
Cool. It's hard to communicate clearly in comments.
Cheers.
Thank you for the great post.
I agree with your opinion. Doing basic tutorial does not make sense for writing production-level code. We might get able to write "Hello world" but it does not help solving the real world problems.
Indeed, I also think learning other paradigm language is a good experience for developers.
As a PHP developer I have solved problems with Object Oriented approach for a long time. One day I learned Haskell for my hobby. Haskell is far from PHP so writing FizzBuzz was even difficult for me at that time.
As I learned Haskell's functional, declarative and type-safe approach I can write robuster code even in PHP now.
Thanks for reading.
That's awesome, Kaz. That's how it's supposed to work.