The Absurdity of Software Engineering Training
Photo by Cam Ballard @cam_ballard on Unsplash
I’ve been wondering about training recently.
In my opinion formal training is a great way of getting better and getting that little leg-up to get up to the next level as a software engineer.
So why are companies disinterested in providing any training to hard-working software engineers?
The Training Game
I decided to play a fun game. I thought I’d count up how many hours of formal training I’ve received at work and (spoiler) it doesn’t total an hour for each year of work.
My experience of formal training is such that my enthusiasm for the same has waned.
Here are some of those experiences
The Two-Hour Wonder
A new technology was introduced into our little corner of the software engineering world.
My manager decided the whole team would have a two-hour session on the technology. At that time, we were far from able to do anything over scratching the surface of the technology and was more a cursory glance at something shiny.
It took so long to arrange that the API we wanted to use, was obsolete and the session degenerated into a simple Q and A session.
The Day-Long Distraction
We received a “free” day of training from a third-party vendor. Instead of inviting the employees who used the technology we decided to invite the wider team.
The only real issue is the wider team didn’t use the technology. I think the attitude of the company was that the training is free, everyone should have knowledge of the technology.
The session was a day-long distraction rather than something to learn from. I’d rather have spent the day staring at the wall to be absolutely honest.
The Subscription Nobody Used
The pièce de résistance in my training journey is a subscription to a set of videos. Focusing on a technology we don’t use and recommended by someone who thinks the technology sounds cool, represents an almost criminal waste of time.
The only thing less used than this subscription is our innovative ideas Slack channel.
Why is it Happening?
Honestly, in my current position, we get nothing. We get no formal training and no time. Even our meeting-free Fridays are used for meetings.
So, I do have sympathy for companies who at least try to give their developers a hand in terms of training.
However good training is something more than tossing a few hours of random training at developers in order to keep them sharp. That can even be destructive in a developer’s learning process and journey.
You need to consider:
Relevance
A developer’s daily work
Supported by the developer
Training has to be more than a token gesture or a check on a manager’s to-do list.
The Cost of Poor Training
Productivity
If you want to kill productivity, simply ensure that developers lack the tools they need to do their job.
Leave developers to figure out things on their own and make mistakes that can be avoided with foresight and training. As developers become more frustrated their morale will drop, and overall, the pace of project delivery will drop.
A well-trained developer is a productive developer. A poorly trained developer might just end up writing blog posts about the absurdity of it all.
Staff Retention
I’ve seen a number of instances of staff leaving from their position because there is no training and no hope of progression.
Leaving developers to figure stuff out rather than having an impact on your product by bringing fresh thinking to the team is an efficient way to increase the staff turnover rate.
A Better Approach
We need a structured, relevant and personalized training program for software developers. Even better if we could integrate that into our work and schedules.
Imagine a training program where we aim to bridge the gap between current knowledge and the next level for software developers? That is what we should work on as an industry.
We need
real courses
real mentorship
time allocated during work hours
personalization
Sure, this requires communication and thought. But isn’t that what we are paid for?
Conclusion
There are plenty of people selling courses and ideas on how to be a better developer.
I still believe the best way is for developers to have engaging work and get involved in that code and how to make it better. Only with engaged staff can you get to the point where training will really make a difference to the performance of any particular software developer.