Over the last few years I’ve expanded the programming languages I’ve worked with. There have been business and technical requirements driving this but it has been remarkably beneficial to my skills as a developer as well.

By learning other languages I’ve found two huge benefits that stretch across all my development:

• It has taught me to think about problems in different ways. Different languages often have different approaches and mentalities to problem which can cross-pollinate for better code across the board.
• It has shown me what is common and important in software design. For example coupling and cohesion is important everywhere and different languages may be able to teach you something different about why.

So how have I started on these languages?

Picking the Problem and the Language

For me, this has been a gradual process so it hasn’t been an option for a big-bang swap over. Taking weeks out to learn the language through formal methods.

Instead I’ve either been problem-led or language-led. That is, sometimes I’ve had a problem I’ve needed to solve which existing languages weren’t great at, or I’ve decided I want to learn a language so I’ve looked for problems it can solve.

The problem and the language are symbiotic. Certain languages are good at certain classes of problems and so matching when you are first learning makes it far easier to pick it up. You will also get more support and more done in a short amount of time.

The Best Problems

There are a few problems that I’ve found as a good way to get started:

1. They should be real problems – maybe this is a personal preference but I struggle without having a real goal or comparison in mind.
2. They should be small – At least to start taking more than a day at a time on a project like this is challenging and you don’t want to end up taking 6 months to see if you can make progress.
3. You should understand the problem well – You really want to make the work about the language. I’ve made this mistake a lot, for example trying to learn Rust on embedded systems when I didn’t know much about either. It becomes hard to know if you are struggling because of the language or the problem.
4. They should be off the critical path. I don’t think you have to wait to be an expert before using a language in production, but to start with you don’t want a project depending on your work. They should be tangential to the main project so if you don’t get finished it doesn’t impact any projects.

Let me give you some of my stories which will make some of these examples clearer.

Committing to Rust

I’m very excited about a language called Rust. Compared to LabVIEW, it has a much broader reach. Using Rust allows me to work on high performance embedded systems across multiple platforms with modern tooling.

In this case I decided first on it as a language and wanted to evaluate whether I should commit to it as a core part of my work. After working through the basic exercises in the Rust book, I started looking at how I could evaluate it properly.

The first thing I used it for was a device emulator. For testing a project we wanted to fake a device which normally I would do with a simulated class. However since I wanted to try rust I tried (and succeeded!) in writing a basic simulator in Rust, streaming random data over the network.

If this had failed, I would have fallen back to a simulated class but it worked well while never putting the project at risk. It also isn’t something that ended up in production.

I’ve also built some prototypes in Rust.

Another interesting example that was my final test before committing to Rust as a primary language was to rewrite some processing code from another project. The fascinating thing with this was that it showed me a totally different way to approach it. This approach will make it back to the final project in C for a big performance boost!

Learning Python

Python has been another interesting exercise but one where the problem leads for me.

I originally picked up Python supporting some code from a customer which let me see where it’s strengths lie.

The nice thing with Python is the speed of development so I’ve found it great for prototypes or quick scripting.

So to learn it better I started by just using it for prototyping some data analysis. I had a customer that needed to do some data exploration and I knew this is a strength of Python. So I fired up a notebook and worked my way through the problem (with a lot of Google-fu to understand Pandas).

In this case the notebook provided a report and was not used again afterwards. So there is no risk of having to support the code in the long term.

I then move on to using it to script some system testing. Again this wasn’t on the critical path of the project, but supplemented the main application.

Getting to Production

So we aren’t collecting languages for the fun of it. How do we get to using these in production? I’ve followed a few patterns to help which boil down to taking on gradually more risk.

• Starting with testing and support utilities allows you to get longer term experience of running the language without putting the main project at risk.
• Look for smaller components that fit the language really well. For example you might just call the processing routines in Python from LabVIEW.
• Whats the difference between prototype and production ready code? Often error handling. Make sure you have a good grasp on how that works in the new language first.
• Test, test, test! This should go for all production code anyway, but make sure you use good testing procedures around the new code and the integration to catch problems early.
• Be prepared to throw it away. Don’t bet the project on it the first time. I had this recently where I developed the UI in a new web framework but I couldn’t get it quite right. So I had to throw it away and rewrite in LabVIEW.

I hope this helps give you some ideas on how to take on that next language and quickly get to writing useful code.

I’ve really enjoyed this journey and it gets easier and easier over time. I can now choose languages to fit the problem I have instead of the other way around and have learnt so much in the process.