Managing, supporting, and facilitating training for software developers isn’t easy. Such is the pace of change that it can be tough to ensure that not only do your developers have the skills they need, but also that they have the resources at their disposal to explore new technologies, try new approaches and solve complex problems.
Okay, sure: there are a wealth of free resources out there. But using these is really just learning to walk for many developers. It’s essential, but it can’t be the only thing developers have at their disposal. If it is, their company is doing them a disservice.
Even if a company is committed to their team’s development, how to go about it still isn’t straightforward. There are a number of barriers that need to be overcome when it comes to technology training and learning. Here are 5 of them…
Barrier 1: Picking resources on the right topics
The days of developers specializing are long gone – particularly in a small tech team where everyone has to get stuck in. Full-stack has ensured that today’s software developers need to be confident on everything from databases to UI design, while DevOps means they need to assume responsibility for how their code actually runs in production. The days of it worked on my machine! are over.
Read next: DevOps engineering and full-stack development – 2 sides of the same agile coin
When you factor in cloud native and hybrid cloud, developers today might well not only be working on cloud platforms with a bewildering array of features and opportunities, but also working on a number of different platforms at once.
This means that understanding exactly what your developers need to know can be immensely difficult. It also means that you have to set the technology agenda from the off, immediately limiting your developers ability to solve problems themselves. That’s only going to alienate your developers – you’re effectively telling them that their curiosity, and their desire to explore new topics and alternative solutions is pointless.
What can you do?
The only way to solve this is to ensure your developers have a rich set of learning resources. Don’t limit them to a specific tool or set of technologies. Allow them to explore new topics as they see fit – don’t force them down a pre-set path. The other benefit of this is that it means you can be flexible and open in terms of the technology you use.
Barrier 2: Legacy software and brownfield projects
Sometimes, however, you can’t be flexible about the technology you use. Your developers simply need to use existing tools to manage legacy systems and brownfield projects (which build on or demolish existing legacy software).
This means that learning needs can become complex. Not only might your development team needs a diverse range of skills for one particular project, they might also need to learn very different skill sets for different projects.
Maybe you’re planning a new project built in React.js – great, get your developers on some cutting-edge content. But then, alongside this, what if they also need to tackle legacy software built using PHP? It’s fine if they know PHP, but what if you have a new developer? Or what if they haven’t used it for years?
What can you do?
As above, a rich set of training and learning resources is vital. But in this instance it’s particularly important to ensure developers have access to learning materials on a wide range of technologies. So yes, cutting-edge topic coverage is essential, but so is content on established and even more residual technologies.
Barrier 3: Lack of time for learning new software skills and concepts
Lack of time is one of the biggest barriers to learning and training in the tech industry. At least that’s the perception – in reality, a lack of time to learn is caused by resource challenges, and the cultural status of learning inside an organization.
If it isn’t a priority, then it’s often the thing that gets pushed back as new day to day activities manage to insert themselves in your team’s day or existing ones stretch out to fill the hours in a way that no one expected.
This is risky. Although there are times when things simply need to get done quickly, overlooking learning will not only lead to disengagement in your team, it will also leave them unprepared for challenges that may emerge throughout the course of a project.
It’s often said that software development is all about solving problems – but how confident can we be that we’re equipped to solve them if we’re not committed to making time for learning?
What can you do?
The first step is obvious: make time for learning. One method is to set aside a specific period in the week which your team is encouraged to use for personal development. While that can work well, sometimes trying to structure learning in this way can make it feel like a chore for employees, as if you’re trying to fit them into a predetermined routine.
Another option is to simply encourage continuous learning. That might mean a short period every day just to learn a new concept or approach. Or it could be something like a learning diary that allows developers to record things they learn and plan what they want to learn next. Essentially, what’s important is putting your developers in control. Give them the tools to make time – as well as the resources that they can use quickly and easily, and they’ll not only learn new skills much more quickly, they’ll also be more engaged and more curious engineers.
Barrier 4: Different learning preferences within the team
In even a small engineering team, every person will have unique needs and preferences when it comes to learning. So, even if all your team wants to learn the same topics, they still might disagree about how they want to do it.
Some developers, for example, can’t stand learning with video. It forces you to learn at its pace, and – shock horror – you have to listen to someone. Others, however, love it – it’s visual, immediate and, you know, maybe having someone with a voice explaining how things work isn’t actually that bad?
Similarly, some people love training courses – the idea of sitting with someone, rather than going it alone – while others value their independence and agency.
This means that keeping everyone happy can be tough. It might be tempting to go one of two ways – either decide how you want people to learn and let them get on with it, or let everyone go it alone, but neither approach is ideal.
Forcing people to learn a certain way will penalise those who don’t like your preferred learning method, hurting not only their ability to learn new skills but also their trust with you. Letting everyone be independent, meanwhile, means you never have any oversight on what people are doing or using – there’s no level playing field.
What can you do?
The key to getting over this barrier is balance. You want to preserve your team’s independence and sense of agency while also having some transparency over what people are using.
Resources that offer a mix of formats are great for this. That way, no one is forced to watch hours and hours of video courses or to trawl through text that will just send them to sleep.
Equally, another important thing to think about is how the learning resources you provide your team complement other learning activities that they may be doing independently (things like looking for answers to questions in blog posts or on YouTube). By doing that you can allow your developers some level of independence while also ensuring that you have a set of organizational resources and tools that are available and accessible to everyone.
Read next: Why do IT teams need to transition from DevOps to DevSecOps?
Barrier 5: The cost of technology training and learning resources
Cost is perhaps the biggest barrier to training for development teams. Specific courses and events can be astronomical – especially if more than one person needs to attend – and even some learning platforms can cost significant amounts of money.
Now, that’s not always a problem for engineering teams operating in a more corporate or enterprise environment. But for smaller teams in small and medium sized businesses, training can become quite an overhead.
In turn, this can have other consequences – from a complete disregard and deprioritization of training and learning to internal frustration at who is getting support and investment and who isn’t, it’s not uncommon to see training become a catalyst for many other organizational and cultural problems.
What can you do?
The trick here is to not invest heavily in one single thing. Don’t blow your budget on a single course – what if it’s not up to scratch? Don’t commit to an expensive learning platform. However good the marketing looks, if your team doesn’t like it they’re certainly not going to use it.
Fortunately, there are affordable solutions out there that can ensure you’re not breaking the bank when it comes to training. It might even leave you with some cash left over that you can invest on other resources and materials.
Learning new skills isn’t easy. It requires patience and commitment. But developers need support and resources to take some of the strain out of their learning challenges.
There’s no one way to meet the learning needs of developers. But Packt for Teams can help you overcome many of the barriers of developer training.
Learn more here.
