In this article, you'll learn more about how building up a wider range of programming culture will help you do an even better job as a programmer.

Many projects and jobs in our developer lives follow this pattern:

I — The excitement phase,
II — The learning phase,
III — The comfortable phase,
IV — The “It’s time to move on” phase.

All the following is directed at you if you are in the phase IV and feel like it’s time to move on from your project / position / job / company.

A couple of months ago I was in phase IV in my previous job, I changed jobs, and now I work at Doctolib. What makes my story uncommon is that I changed lives in the process.

I’ve been a C++ developer for 10 years, very involved in the C++ community, regarded as an expert in many C++ circles. During those years I worked in applicative development only. That means pure software development as opposed to web development.

Now I’m a web developer at Doctolib, which means that I work on a frontend sending HTTP to a backend, with React components and Javascript, Ruby on Rails, PostgreSQL and Redis, along with HTML and CSS. I knew none of that when I was a C++ developer.

This is, technology-wise, a new life.

What I learned from this career move is that changing technical environments was the most efficient boost in programming skills I’ve ever seen.

More precisely, a language change makes you less productive for a short period of time, because you need to get used to it. There is an “Adaptation” phase where you’re less productive than if you had stuck with your previous language.

The “Adaptation” phase is very intense in learning. You learn things just by showing up at work, and your skills then grow very fast.

This boost happens when working in an environment with a different programming language, and not just a new project, new company, or new people.

Those also make a developer grow, but picking a new language at work, and one that is different from those you master brings you unique advantages.

I’ll explain in detail what changing languages brings you that boost your programming skills. But first, let’s clarify a common misconception: when you get a new job with a different language, you don’t go back to square one.

You don’t start from scratch

Being a C++ developer when I was looking for a new job, I focused my search on C++ offers at first. I thought that given the time I had invested over the years in mastering C++, it would be a shame to throw this knowledge away and start all over again as a junior developer in a new language.

But this is a wrong perception, and our recruiters often see this misconception in the mind of software engineers especially in Europe:

This is a misconception because there is a stunning amount of things that don’t depend on the language when you write code.

For example when you write C++, you’re asking yourself the same questions than when you write Ruby or JS:

• What abstractions should I define in my code?
• What goes in the interface? What goes in the implementation?
• Should I extract this code in a function? In a class?
• How can I write an expressive if statement?
• What is a reasonable way to test this code?
• What part of the code should get a certain responsibility?
• Which piece of code should depend on which?
• What’s a good name?

Those topics relate more to software craftsmanship than a particular language. This means that once you master them in one language, you don’t have to learn them again. The only part that remains to learn is the tools that the new language gives you to express those intentions.

Another way to put that is that an experienced developer knows what they want to say in code. The remaining part to learn in the new language is how to express it. And that’s lots of new knowledge — and fun.

Another interesting phenomenon is that programming languages are like spoken languages in that the more languages you know, the faster it is to pick up a new one. This means that your first programming language may have been tough to learn, but your future ones will get easier and easier.

An additional perspective on programming

Working with a new language doesn’t just make your knowledge grow. It gives you a new perspective on the Grand Scheme of Programming.

This means that what you know in a given language improves how you code in other languages.

Let me give specific examples based on my personal experience. To sum up my language span so far I’ve had the opportunity to get:

• a 10-year background in professional C++ and side projects,
• a couple of months of Ruby on Rails and React JS in a professional environment,
• a couple dozens of hours of Haskell on side projects,
• a trailing sequence of other languages I tried out.

Here are some of the unique things I learned in one of those languages and that changed my way of coding in all the others.

The emphasis of functions in Haskell made me learn and rely on the C++ standard algorithms library.

Ruby, being “optimized for programmer happiness” and Rails, being designed by the “principle of the bigger smile”, are very pleasant to work with and showed me what beautiful code looks like.

The point-free programming idiom of Haskell made me use `&` and `method` in Ruby.

The strong typing of C++ of C++ enum classes made me avoid duplicate strings in Ruby and JS.

The convention-over-configuration motto in Rails showed me how decoupling glue code from business code looks like.

JS objects made me comfortable working with JSON in all other languages.

The fact that Ruby and JS have no static types, whereas C++ and Haskell have as much static typing as it gets, made me see where types are useful and where no types frees you.

Passing objects from backend to frontend looks like duck-typing on steroids compared to C++ templates duck-typing, but C++ concepts (“concepts” is the name of a C++ language feature) look like duck-typing on steroids compared to passing object from frontend to backend.

Compiled languages like C++ VS interpreted languages like Ruby showed me the trade-offs between development speed and execution speed.

Ruby dynamic metaprogramming expanded my view of C++ static metaprogramming.

C++ taught me how exception safety can structure your code design.

The Rails ecosystem for testing opened my mind on testing.

And the list goes on!

I could never have learned the above takeaways by sticking to one language, even if I spent 30 years in it.

Discovering a new language in a professional environment expands your view on programming, and shows you things that you would never have thought possible coming from another language.

To make the most of this experience though, the best is to choose a language as different as possible from the one you’re working on. For example, don’t choose Java or C# if you’re working in C++, don’t choose Ruby if you’re working in Python, and so on.

Big learnings also come by exploring a new paradigm, for example functional programming if you haven’t had a chance to try it yet, or moving to a typed language if you’re familiar with untyped ones.

Get better at the difficult topics

There are difficult topics in programming, that don’t depend on one particular language, and that I’ve always struggled with.

Changing stack sheds a new light on those topics and unlocks new ways of approaching them.

I’ll take two examples of such difficult topics: componentization and testing.

Most companies that get big face these two questions at some point:

• In order to keep growing but maintain a manageable cognitive load, how can we break up our software into components?
• How can we keep growing and have a maintainable test suite?

These are advanced programming topics, as there aren’t tutorials out there to solve those questions the same way as how to write an if statement or catch an exception.

What’s more, there is a lot of confusion around these two topics in the software community, and when management asks you to somehow figure them out, that adds stress to confusion. I’ve always struggled with those two topics.

Like every company, Doctolib wants to scale its code and its test suite, so when I joined I faced those challenges again. But the situation was different. I had faced them in C++ in the past, and now I was seeing them in the light of Rails and React, and in Doctolib tech environment.

Testing C++ code or breaking it up in components is quite different from doing it in Ruby, but there are some similarities. Seeing the differences and the similarities offers a 20,000 feet view on componentization and testing. And that clears up a lot of the confusion.

What exactly I learned about componentization and about testing are the topics of entire blog posts (which I’m currently writing). But the point here is that seeing a difficult problem in two different languages brings invaluable insight.

Learning at work as opposed to learning at home

Learning a new language can happen in two contexts:

• At work, if you’re moving to a project using a language you don’t know
• On your personal time, on side projects at home or in meet-ups

Learning at home gives the most flexibility to try out languages and drop them quickly. But learning at work is how you get the most out of a language.

Indeed, working with a language in a professional environment gives you many hours of practice, every working day, for a long period of time, and you get to work on Real Problems. What’s more, new colleagues at work are an infinite source of learning through pair programming, mentoring and informal conversations.

If you’ve been feeling comfortable with your current language, now is the time to move on, change projects, maybe change companies, and work in a radically different language. That will boost your skills and your joy in programming.

We’re hiring at Doctolib, but we’re only accepting developers with a strong experience in Ruby on Rails and React JS.

No, I’m joking. We welcome software engineers who want to boost their skills by moving into a new stack. We’re looking for people who are motivated to learn. Check out our jobs page.

I also encourage you to subscribe to our tech newsletter. Every Tuesday you’ll get 12 selected resources on React, Rails, software engineering best practices, and geek stuff. This is my personal go-to resource on those topics.