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 StackOverflow.com, 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.
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.
Advanced APIs don’t protect you from learning the base technology
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 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.
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.
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.