Lack of Training Culture: Why the Cultureless Don’t Stand a Chance

Last Monday, I published an article on Heise, “Mangel an Fortbildung: Warum die Kulturlosen keine Chance haben” that got almost 300 comments. Here is my English translation of this article.

The article is intentionally provocative because training culture is my crucial motivation and my heart’s desire.

It’s a disaster waiting to happen: a significant lack of training culture exists in the software industry. As if that weren’t bad enough, add to that the demand for high-quality software, and the complexity of software will increase dramatically soon. The problems are pre-programmed.

The significant lack of training culture, described below in four points, refers to the software industry alone in this text. But it can easily be generalized to the entire industry, as software is increasingly becoming the value driver of our economy. And it applies to both the employer and the employee:

Learning is not an integral part of the daily work routine

Learning needs to be an integral part of the daily routine. The software industry is very complex and dynamic. Therefore, the question must be answered repeatedly: Am I using the right technology? Asking yourself these questions requires an open culture.

This training culture is characterized by the fact that it welcomes and supports further training. It does not regard further training as a cost factor but as an investment in its and the company’s future. The responsibility rests on the employer and the employee.

First, the employer must view training and the culture of continuing education as valuable assets. Employees are the employer’s most important asset and a guarantor of its continued business success. There are many ways an employer can support its employees. These include:

Freely available learning materials such as books, magazines, or subscriptions to learning platforms.
Educational programs such as mentoring, training, or regularly scheduled internal professional development sessions
Participation in conferences and trade shows
Presentations inside and outside the company at conferences

But the employee also has a responsibility. First, he may have to convince his employer that building a training culture in his or her company is an investment with a very high dividend. This conviction is necessary because people not involved with software often need help to correctly appreciate the systemic challenge of software. Moreover, he knows the culture and the challenges of the company perfectly.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Embedded Programming with Modern C++": January 2025

"Generic Programming (Templates) with C++": February 2025

"Clean Code: Best Practices for Modern C++": May 2025

Do you want to stay informed: Subscribe.

If no training culture is established in the company, this will have very negative consequences. In the medium term, good and outstanding software developers will leave the company because they seek an environment to improve. They are eager to learn. Only the bad programmers will stay because they cannot find a new employer, and their motivation is mainly limited to job security. This effect is reinforced by the fact that excellent software developers only want to work with excellent software developers.

In the long term, a company without a training culture will eventually have only poor software developers. At most, those can maintain legacy software but no longer bring new products to market. Ultimately, however, the product can no longer be decisively improved, so Darwin strikes in the long or short term.

It usually takes three years before a lack of training culture leads to a company employing only bad software developers. I have, unfortunately, witnessed this process several times.

The employer does not support learning

Employers need to support their employees’ learning. If not, the following fatal automatism sets in:

A software developer is doing what he loves and is eager to learn new techniques and programming languages to meet his daily challenges. His challenges are very high. These concerns include the design of the software and its security architecture, secure communication between components across computer boundaries, or multithreading with its inherent complexity. He must maintain and improve old software and implement brand-new products simultaneously. Often his projects are “bleeding edge” and require his full potential. Software is his passion.

His passion is so great that he must invest much of his free time to continue his education. Every two years, he has to question his solution strategies. He has to know and apply the proper techniques to find the best and most elegant solution. However, this challenge becomes too great if his employer does not support him, and the learning rests only on his shoulders.

If the software developer cannot keep up with the current state of programming art, there are only two options. He invests more time and effort in his spare time to fill the ever-growing gaps in his knowledge. Or he can look for a new employer who supports his passion and invests time and money in his continuing education.

Motivated and good programmers have many opportunities in the market. And they benefit companies that invest time and money in learning immensely: After a few years, he is no longer a good software developer but an excellent one. Now the new company reaps the rewards: excellent programmers pass on their knowledge as mentors, they ensure a good reputation for the company and become a magnet for exceptional programmers.

Employees are hired for their skills, not their motivation

An employer should make hires based on the motivation of its prospective employees. Otherwise, there is a risk of fatal automatism.

My experience is that employees’ willingness to learn new techniques and improve themselves often is independent of their level of education. Often, the experts have the wrong attitude and have completed the “learning” stage of life. This means much money has been invested in the wrong people and goals.

Often, experts are proud of their expert status. They don’t want to feel like apprentices. And they already think they are the best. Therefore, a company’s goal must be not to hire the best but to create an environment where employees can become the best. Some companies have already embraced this shift in mindset. Rather than looking for the best software experts – who don’t exist anymore anyway – they are looking for dedicated employees and establishing an advanced training program.

Expertise in the software industry has a half-life of two years. Companies should therefore invest time and money to create an environment in which continuing education is an integral part of employees’ working hours. This “training on the job” is far more effective and sustainable than just looking for and hiring the best for a lot of money.

We have forgotten how to learn

Learning is like a sport. First, the basics must be learned. This includes techniques and personal strategies on how to learn. Then, exercises must be applied daily to maintain the ability to learn. Even if the first part of the learning journey has been mastered well at school, university, and as a newcomer on the job, the second phase begins as a professional. It requires daily practice.

The senior professional may think that daily learning is no longer necessary. It hits him all the harder when fundamentally new challenges suddenly arise. This may be a new programming domain, a new technique, a different programming language, or even a new programming paradigm. Now is the time to start all over again and learn.

Lack of daily practice causes many to unlearn. At the very least, it no longer comes naturally. And before you know it, it may be too late for you.

What change do we need in our software industry?

I was once tasked with changing the development process of a software team. The goal was to shift from control-based leadership based on orders to be completed to trust-based leadership. Naively, I thought this would unleash the team’s full potential. I was wrong as I could be. The team had worked in a control-based structure for at least three years. Over the last few years, they learned only to implement orders from their superiors. The result was stagnation. Team members forgot how to organize themselves. This story applies to learning in general: When practice is lacking, learning must be relearned.

Daily learning must become an integral part of the work culture. Learning is a process that is never complete. It is a critical factor in our success. Whether a daily learning dose of one hour or a weekly learning dose of eight hours: The happy medium depends on the domain and the level of training of the employees. We still have a lot to learn.

I’m curious to hear your thoughts and want to keep the ball running. Please write an e-mail to Rainer.Grimm@ModernesCpp.de and state if I can quote you. I will write a follow-up post about this crucial challenge in your software domain.

Modernes C++,

Post Views: 1,852

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS