Improving Your Skill Set: Tips for Learning New Programming Languages

I spend a considerable amount of my time with scientists who are staring to learn to code (either IRL or online), often in the hopes that it will open future research and career doors. One of the major barriers I have found in my own experience, as well as observed with others, is learning and implementing new programming languages after I already learned one. If we are honest, learning a programming language is very challenging but also incredibly rewarding. So do we really want to go through that again with a new language, and will the new language open as many analytical doors as the first? This week I was to discuss the process of learning new programming languages, and offer you some tips on learning a new language, if that is something that interests you.

Why Learn a New Programming Language?

Once you know how to program with a language like Python or R, why bother learning other languages? This is a logical question, and one answer is that different languages can offer you very different strengths and weaknesses. Some languages are faster than others, some implement more responsible memory usages, some are just easier to read and write (we're looking at you, Perl), and some have stronger communities to support your applications (e.g. many scientific applications are supported by the R community). Being familiar, if not proficient, in multiple languages offers the ability to take advantage of the strengths of multiple different languages, and apply the tools that are best fit for the job.

Another reason for learning new languages is the fact that most languages are not around forever, and eventually become replaced. This makes "keeping up" a very valuable skill. Yet another good reason for learning new languages is that the exposure to different structures allows you to think about all of your code and data in new and challenging ways. This is a great exercise for becoming a better all-around scientist.

Don't Sell Yourself Short

Through various conversations and my own experiences, I have learned that it is really easy for us to sell ourselves short. We see a new and unfamiliar language and think, "I can't learn how to use that; I barely learned the language I know now." The fact is that the first language is the hardest, and you will be surprised how much faster you will pickup new languages. So we really need to "go for it" and check out the new languages we think will be helpful. The worst thing we can do is disqualify ourselves before giving it a try.

Skills For Learning New Languages (In 30 Minutes)

Last week I gave a presentation to my lab about this topic. The main goal being to illustrate how each of us can learn new programming languages faster and more effectively than we give ourselves credit for. To this end, I proposed that we break into small groups (although you can do this by yourself as well) and solve the following simplified Fizz Buzz test.

Write a program that prints the numbers 1 to 100. Print the word "FIZZ" next to every number divisible by 7, and the word "BUZZ" by every number that is not divisible by 7.

The trick here is that we solved the problem using Julia, a language that nobody else has used in our lab (if you want to do this yourself, pick a different language if you are familiar with Julia). I mentioned to the group that, when I start familiarizing myself with a new language to solve a specific task, I begin by breaking the problem up into smaller, "Google-able" problems. These can then be solved and put together to form the overall code. Smaller problems within our Fizz Buzz test include:

• How do I print words and numbers?
• How do I create a string of numeric ranges (1,2,3,...)?
• How do I loop tasks?
• How do I perform conditional evaluations?

After going through this, we broke up into groups and everyone was able to solve the problem within 30 minutes. When we came back together, we discussed our solutions while reflecting on the following points:

• How did we break up the tasks?
• What was the most challenging part of the problem?
• What does the solution look like (show the code to the rest of the lab)?

And there you have it. After about a 45 minute meeting, everyone in the room was able to solve an analytical task using a totally new language. I definitely encourage you to also give it a try. If you run into problems, or have more questions about how you can use this approach as a teaching tool, reach out in the comments below, Twitter, or email (my contact info to the right side of the page). As always, please also reach out if you have any other questions, comments, or concerns. I always love hearing from people.

I also wanted to include a note about the state of this blog. You may have noticed that posting has become less frequent lately. I have a lot of other projects going on right now, which are awesome but also mean I don't have a ton of time to devote to blogging. I look forward to getting back into a more regular routine, but for now the posts are going to be more spread out. Thanks for reading!