Article Blog Image

Don't Learn a Language

Programming

In my role as a technology leader, I’m occassionally asked by people looking to develop their career and move into software engineering:

What is the best language for me to learn?

My response is always the same, and has been for many years:

Don't learn a language, learn to program.

This probably requires some explanation to anyone who is not familiar with software engineering practices. Dedicating time to learning a specific language will ultimately be a limiting factor in your career progression. By specialising to the level of a specific language, you’re implicitly limiting your options. While this might not seem too big a deal in the moment, it will become important before too long. You’ve only got to look at the various reports available on the internet to realise the futility of this approach. As an example, the Fossbytes report for 2017 shows Javascript as top, no surprise there, more interesting are languages that appear further down, such as Go, and Swift. Swift, in particular, only came onto the scene in 2014, and is already showing in the lists. What’s more, where you look, and what factors apply, will give you a completely different view of the most in-demand languages, Techworld lists SQL as the top, and neiher Swift nor Go get a look in.

This just goes to show the fickle nature of programming languages and their favour with the community and industry. Any time spent focusing on learning a particular language will have an implicit shelf life, and then the cycle will start all over again. Of course, with each langauge you learn, the next typically gets easier, unless you’re leaping from procedural to functional, or similar, but it’s still a learning curve each time.

A far better approach to assuring your position in the future of software engineering is not to learn the details of a particular language, but instead to learn, and learn well, the lessons of software design and architecture, which can be applied easily irrespective of the language of choice.

I have, through my career, worked with in excess of 40 different programming languages. Does this mean I can fire up my favourite text editor and start programming in any one of them, of course, not, and I don’t need to. When I start a new project, I don’t begin by thinking about which programming language I’m going to use, and which language constructs or libraries are appropriate. Instead I think in concepts, forming the structure of the program at a high level, what interaction it needs with the external world, what data it might need to store, how it can process that data effectively. At this point, I haven’t even chosen a language. It may well be that the language is forced upon me by the nature of the project, but that doesn’t matter at this stage. Only when I’m happy with the overall approach, will I start getting into details of which language, which runtime, which libraries. The benefit to this approach is that I don’t have to keep the intricate details of 10’s of languages in my head all the time, I keep the principles, and enough high level information about language options to be able to make sensible assumptions. It’s Google all the way from there. Why retain the syntax details of Javascript or JQuery, when I can find them in a second when I need them?

Tags:
Home