developer productivityproject managmentsoftware design

Too Old to Learn a New Language?

The other day, a co-worker and I held a talk at the Java Forum Stuttgart. Our topic was the UI techradar we’re currently developing. So much of the talk was devoted to comparing UI frameworks, raving about Angular, about the advantages of programming your smartphone natively in ObjectiveC, and why it’s still a good idea to stick to Java and JSF.

All of a sudden one of the attendees asked a question I wasn’t prepared for. It was a good question, but I didn’t take it as seriously as it deserved. Even worse, I laughed it off. That’s something you must never do. When I noticed my mistake, it was too late to correct it. So I decided to blog about it. It’s a late answer, and I don’t know if it’s ever going to be read by the guy asking the question, but here it is.

The question was:

Angular and React may be great. But do you really expect everybody who’s crossed the 35 years mark to learn a new programming language each year, just to use the UI framework of the week?


I consider the question to be important. We must address it. What’s wrong with the question is that it focuses on age and on the programming language. There are many, many reasons why even good programmers fail in a new project. Recently, I’ve had a hard time in a pure-Java project. Programming Java since 1998 didn’t help me because the project setup didn’t meet my expectations. So let’s have a look at the bigger picture. And let’s act. If you see a co-worker struggling, help them. Either by coaching them, by starting pair programming or by simplifying the project setup.

Because that’s the ugly truth about all these fancy new frameworks, languages, and programming ecosystems. Each of them promises to simplify your life. But must of them don’t. Or they do, but they pay only after a long ramp-up time.

Back to the original question. Should you avoid adopting a new framework because your team members are too old to learn a new programming language?

Too old to learn a new language?

Truth to tell, I have two answers: Yes, you should. Learning a new programming language each year used to be possible in the 70s. In 2017, that’s demanding too much. But thinking twice, learning a new programming language usually is a piece of cake. The choice of language shouldn’t stop you.

Thing is, both answers are correct.

First of all, I don’t think there are many programmers who are too old to learn a new language. It’s true that learning gets harder when you grow old. The way our brain works changes. It has to change. The alternative is to forget what you’ve already learned. It’s easy to learn when you’re a child. There’s plenty of empty space in your brain, so it’s easy to re-arrange the neuronal net to store the new information.

Later, new information has to be stored in the same neuronal net. The more knowledge you’ve accumulated, to more difficult is it to re-arrange the neuronal net to store the new information without loosing the old knowledge. That’s the biological reason why it gets more difficult to learn.

Or just too busy?

But more difficult doesn’t mean impossible. In particular, it’s easy to learn a new programming language if you already know one or two languages. Usually, there are minor changes to the syntax and the semantics of the keywords. That’s not the real challenge. In 2017, it’s much more difficult to learn the new ecosystem of the new languages. Just think of the standard libraries. Most programmers know only a small fraction of these libraries.

Even so, in the age of, most people can manage. But they don’t. What wrong with them?

Well – nothing. Most people get a second job (for want of a better word) when entering the third decade of their life. They settle down to family life. They marry and they raise children. If they don’t, they usually find another way to participate in the social life of their city. They take over responsibilities. Children, in particular, are a full-time job. Shouldering two full-time jobs at the same time is quite a chunk to swallow. When your children get sick, your job ceases to be your top priority.

A state of mind

Sooner or later, everybody encounters such a phase. As to my conviction, it’s important to support your co-workers and to help them cope. Give them the opportunity to come back to the job after solving the difficulties. Next time, they’ll support you.

More often than not, that’s not how things work. Instead of being supported, “weak” team members become outcasts. Or they get lazy. They got along a lot of time without learning new stuff. After such a phase, which often exceeds ten years, it’s difficult to learn to learn again. Or to accept that it’s time to move on. When you’re told “you can’t do that” long enough, you accept that as a truth. In reality, it’s bullshit. It’s just a state of mind that blocks you. That, and the prejudices of your co-workers who don’t give you a chance to excel again.

Cutting a long story short, I believe it’s possible to learn new programming languages every once in a while until retirement age (and beyond). I’ve been working with many programmers near retirement age, so I know it doesn’t get easier. I also know you can’t do it during every phase of your life. If your kid is suffering from diabetes, or if your parents suffer from dementia, learning a new programming language becomes a no-go.

Is there a strategy avoiding learning new programming languages?

Should we avoid a framework because of the programming language?

I’ve already been there. During 2002 and 2010 I’ve been developing a full-stack framework for my former company. It covered everything from persistence to the UI layer. The two design goals were ease of use and “Java only”. Truth to tell, I still think this framework gives the company an edge over the competition, even seven years after I’ve abandoned it. Maybe Angular 2 and above allows for an even higher productivity, but older UI frameworks didn’t. The pure-Java approach was a big relieve to our seasoned mainframe programmers who barely managed to learn Java and object-orientation after writing Assembly language and procedural NATURAL code for three decades.

Under certain circumstances, it pays to select your UI framework to match the existing skill set of your crew. Like so often, it depends. There’s no silver bullet. What’s right for one team is wrong for another team.

By the way, that’s one of the reasons I like the idea of GWT. It allows you to use the same language on the client and the server. The JavaScript guys had the same idea. They call it isomorphic programming. It’s implemented by bringing JavaScript to the server (via node.js or Java’s Nashorn project).

Is it possible to avoid polyglot programming?

The catch is that nowadays it’s not possible to escape polyglot programming. Consider VertxUI, for example. It allows you to program web application without using HTML. You write your HTML page using the Fluent framework in pure Java.

But that doesn’t mean you don’t have to know what HTML is. Fluent may be a nice Java layer, but you can’t use it without learning HTML first. It’s only a shallow abstraction layer.

JSF is a larger abstraction layer. It’s possible to write a JSF application (almost) without HMTL tags. Component libraries like PrimeFaces and BootsFaces are powerful enough to allow for that.

But in practice, most teams find out that JSF is HTML in disguise. In most cases, it’s easier to use plain HTML instead of using a third-party component. By the way, that’s what made JSF 2.2 such a revolutionary update. It converted HTML tags and HTML attributes into first-class citizens of JSF. That, in turn, allows you to get rid of your component libraries.

Programming HTML natively has many advantages. There no translation between JSF and HTML. In other words, there are less nasty surprises. Plus, you can use many JavaScript frameworks. Getting rid of the abstraction layer gives you many freedoms. Most teams use their freedom to use another abstraction layer, like Bootstrap, Material Design or jQueryUI. But that’s not the point. The point is that they are able to choose their own favorite abstraction layer by abandoning the default abstraction layer of JSF.

Advanced APIs don’t protect you from learning the base technology

So you’ve started with an abstraction layer to protect your co-workers and yourself from the gory details of JavaScript, HTML, and CSS. A couple of years later you accept that your JSF application runs in a browser, and you start embracing it. The next step might be to abandon JSF altogether. That’s what many teams do: they migrate to pure browser technologies like Angular or React.js.

There are many examples like this. I’m fond of Hibernate. But when things get difficult, I always examine the SQL code Hibernate generates. Hibernate is a nice abstraction layer, but it doesn’t mean I can do without learning SQL. It’s sort of a trade-off. I’m a lot less fluent in SQL than I used to be because I hardly ever have to write SQL code. At the same time, I have to learn the Hibernate API. In theory, that’s easier than learning the base technology, but in practice, there’s an extra learning effort.

Polyglot Java programming stack

Looking at the programming stack of the average programmer, there are already many languages:

  • Maven is a special XML dialect.
  • Gradle uses Groovy.
  • The bulk of your application is written in Java.
  • The front-end part of your application uses HTML, CSS, and JavaScript.
  • The back-end part uses either SQL, REST, or SOAP. REST uses Json. SOAP uses XML.
  • If you’re into Continuous Delivery or Microservices, there are many more technologies, most of them with their own script language. Just thing of Vagrant and Ansible.

It’s not surprising that full-stack programmers are getting rare. Most developers have a hard time to wrap their head around all this stuff. The idea of using “just Java” is an urban legend. Most of us use multiple languages on a daily basis, and we do it with aplomb.

Playful JavaScript afficionados

When I entered the JavaScript world, I had a hard time. In my eyes, it’s moving way too fast. There was a similar period in the Java world one or two decades ago. The JavaScript community is moving even faster. The problem is that you’ve just managed to learn a technology only to learn that everybody else already has moved to the next technology. Of course, “everybody” refers only to the most active part of the community. It refers to the people who’re blogging, discussing in forums, or tweeting. Most projects select a framework and stick to it for a couple of years.

Sometimes you can’t do that. In particular, Angular followers had to be very flexible during the long pre-alpha phase (and even during the long alpha and beta phases). Countless are the breaking changes of the API. The Angular team switched the repository for TypeScript type definitions at least twice. Many Angular seeds have been developed. In my eyes, each of them was too complicated, so I was glad to learn about the Angular CLI which is a lot simpler.

And, yes, there were one or two changes of the programming language. AngularJS started with JavaScript and Dart. The second version started with AtScript. Later AtScript was replaced by TypeScript. That’s a pattern not limited to Angular. Using a language other than JavaScript has become popular in the JavaScript world. Many teams using other JavaScript frameworks experiment with Babel in order to benefit from the latest ECMAScript versions.

Is the language the problem?

All this doesn’t make learning a new UI framework easier. By now you’ve got the gist of it. Learning a new framework is difficult. Whether you’ve got to learn a new programming language or not – well, that’s almost the wrong question. Learning a new language adds to the learning curve. But you should look at the bigger picture. I understand why people are concerned about learning a new language. It’s the central API. Everything starts with the programming language. But then, most programming languages share many common traits, so experienced programmers are able to learn the new programming language quickly.

Maturity and stability

I’d prefer to focus on maturity and stability. If you’ve got a team of university students, stability isn’t much of a topic. Feel free to choose a volatile and innovative framework. If you’ve got a team with many obligations out of office (such as raising children or geriatric care), try to choose a framework that doesn’t reinvent itself every week. I believe (or hope?) that the Angular team has learned their lesson, so I recommend Angular for teams preferring stability. As far as I know, React.js is fairly stable, too. If you need even more stability, choose JSF, Spring MVC, or JavaFX.

Learning a new language with a new paradigm

There’s a corner case. Sometimes learning a new programming language is an impossible task. I’ve spent many years trying to teach seasoned mainframe programmers how to use Java. No go. To my astonishment, many of them couldn’t wrap their mind around object orientation.

I believe that one of the problems was the mindset. After raising children and after using the same programming language for twenty years, they’d lost the hunger to learn new stuff. Things like that happen.

But there’s a second, deeper answer. Learning a new programming language is easy if it follows the same programming paradigm. Learning a new programming paradigm is much more difficult. Switching from procedural programming to object-oriented programming proved to be difficult for my former co-workers. I know I can’t wrap my head around PROLOG. I understand the general principles, but I can’t apply them. I’ve also some trouble with functional programming. I use it when it’s appropriate, but my younger co-workers deem it appropriate much more often than I do. They even re-implement those algorithms I’ve deliberately written procedurally.

Choosing a framework hardly ever means adopting a new programming paradigm, but you should keep the paradigm topic in mind. Adopting a new programming paradigm is one of the hard changes.


I’ve already talked about how important empathy is. Watch your team and listen to them. See to it that they manage their tasks. If they don’t, ask yourself (or them) why they don’t. Maybe they need help. Maybe you need to simplify the project setup.

If you’re an architect or an influential team member, try to simplify both the architecture and the project setup. Programmers have a tendency to add new libraries to your project every couple of weeks. You shouldn’t forbid that (because that kills their motivation). But talk about the benefits of the new library. Make them convince to accept the library. Is the functionality already covered by another library? Does it make life really simpler?

You should also check the optimization goals. I know teams caring a lot about clean code and 100% test coverage. But nobody notices that it takes ten minutes to compile the program and to get it up and running in the application server. As a result, most team members never start the application server. Instead, they write unit tests. The reason for the slow compilation times is that the team has added to many fancy tools. There’s Flyway, there’s Hazelcast, there’s ActiveMQ, there’s Swagger, and so on. Each of these tools is valuable, but putting them all together kills developer productivity and raises the learning curve. You don’t have to be old to fail in such a project.

Wrapping it up

The question I was asked at the Java Forum Stuttgart was a good question. Having to learn a new programming language just to use the UI framework of the week is demanding too much of your team. On the other hand, learning a new framework is always hard. The programming language is probably only the tip of the iceberg. So I recommend not to look at the programming language but at the entire iceberg. What’s the total cost of ownership? How difficult is it to learn the API? Do we need new tools and IDEs? What about the ecosystem?

And maybe much more important: is my team ready for the change? The answer depends on many things. Age is only one of them.

Dig deeper

Where do all the old programmers go? on Hacker News
3 Myth-Busting Reasons to Start Coding Even at an Older Age

2 thoughts on “Too Old to Learn a New Language?

  1. A well written article.

    We, a small team of developers, use mostly JSF with a bunch of libraries, deployed on Apache Tomcat. Most wars with, JSF, Primefaces, Hibernate, Deltaspike, Weld, Liquibase/Flyway – to mention some are 100Mb big and the deployment time is under 30s.

    Polygot-programming is really a pleasure. AOP, OOP, FP makes the code so much cleaner and easier to read for others, that I would rarely switch back to one paradigm again and for us, there is really no reason switching to a JavaScript framework at time and the future. Almost every problem can be solved with Java. Sometimes is a bit harder but if you know your tools, it is done quite fast.

Comments are closed.