A successful graduate-level software development training programme is a surprisingly difficult undertaking to get right. Many variables must be juggled, and any one of these, if ignored, can cause a programme to fail.
You might think, with all the hype around AI, that such initiatives might be ideal for development using a tool like ChatGPT, Gemini, or Perplexity. However, in practice and from experience, that couldn't be further from the truth! That's not to say that AI can't play a role in such a programme—for example, to help with marking, providing reference information, or even outlining approaches - but it's not suited for developing the entire curriculum.
In this blog, we will explore what it takes to deliver a thriving training programme from the perspective of both the classroom instructor and the commissioning organisation as a whole.
Getting Started
The first thing needed for a flourishing new graduate training programme is a thorough understanding of the environment, learning goals, and typical project requirements of the commissioning organisation. What do their fresh cohort of employees need to learn, to understand, and to be able to do?
Note these three aspects. It depends on what the organisation is looking for - typically, they seek well-rounded developers, ready to engage successfully and effectively within the real world of commercial software development with production-ready skills. Underlying this, they want their new starters to understand why they are doing what they are doing, how it fits into the larger picture, and what the consequences of not adhering to this might be. For example, why it is necessary to write a suite of tests that will allow a developer further down the line to modify the software and have a level of confidence that the code still works.
Therefore, determining what the delegates need to know to meet these goals is a major part of a successful programme. This, of course, involves the course designers and the organisation's stakeholders, such as engineering, development, maintenance, deployment teams, HR, etc., all working together to determine what the optimised programme needs to achieve. Of course, there will be differing emphases and needs from each, and balancing these is where a truly good training team will excel.
A Balance of Activities
As suggested above, balancing the needs and requirements of different departments can be difficult. But this is not just related to the technologies, procedures, or processes of the organisation; it can also impact the fundamental way in which the programme is run.
For example, one programme we were involved in had a very high emphasis on testing the delegates. This produced a large number of metrics for the HR department, who could highlight those who were achieving very good scores and those who were not progressing so quickly. But a training initiative isn't just about excelling in exams per se; at the base level it's an indication of whether someone can pass a test, but in a real-world context, is that individual progressing and gaining new skills? It is quite possible that at the start of a programme, someone may be struggling, but by the end of the programme, they are blossoming. Tests do not tend to help with such a progression; in fact, they can result in very high levels of stress and associated fatigue, neither of which are conducive to engaging your cohort of learners.
Equally, the software development department may feel they just want delegates to learn to programme in the current flavour-of-the-month programming language. However, over the course of a developer's career, programming languages are likely to change, so understanding the fundamentals of different approaches to programming may be more important. Of course, focusing purely on the theory and concepts without giving time to practical sessions where those concepts can be explored is also a flawed approach.
As with many things in life, moderation and balance are the key. For example, testing at every opportunity will probably be overkill, but not including any form of validation may allow delegates to think they don't have to focus.
Achieving a suitable balance can sometimes rely on a feel for what will work and what won't depending on the audience. It should also take into account the existing knowledge, skills, and experience of those coming onto the programme.
During the Programme
Every run of any training programme will be different. This is because those attending the training will have different backgrounds and experiences, different prior knowledge, and different abilities around absorbing the concepts being presented.
Any instructor worth their salt will adapt to the demands and needs of the delegates, spending longer on some topics or exploring additional examples as needed to help the delegates' understanding.
In many cases, a group of delegates with perhaps less technical backgrounds will need more support early on in a programme but may well have caught up with those with more technical knowledge by the end of the programme. So it is not even a consistent need to always go at the same pace or present every concept throughout the programme at the same depth.
Informal discussions (around the coffee machine) or during lab sessions also allow the instructor to explore concepts and ideas further, either individually or in smaller groups, which can allow delegates to open up about their questions or confusion. These often 'unseen' sessions can be equally as valuable, if not more to the delegates than the more formal timetabled sessions.
Of course, as a programme progresses, an experienced trainer will pick up on those delegates who need additional support, whether that is emotional, technology-related, or just general encouragement, and provide what is required.
Career Planning
Given the above, a human instructor can be very well-placed to identify those who might be good leaders, software architects, testers, UI designers, or analysts. These traits go beyond the purely academic and direct success in the technical aspects of a programme.
This writer well remembers a delegate on a graduate programme from the noughties who was not the best programmer in his year, but he had this ability to work with people, to organise a team, and essentially to get the best out of his peers. He went on over the years to get promoted again and again, and the last we had heard of him, he was CEO of a technology-focused company. However, at certain points, if we had gone on his purely technical ability, you might well have expected him to have dropped out of the industry altogether!
Team Building
Software development is typically a team effort! Which is exactly what is typically not taught within our educational system! In fact, within our educational system students are told not to work together, not to collaborate and if they do, they will be penalised. Of course, there are those examples everyone can point to where students have to work in teams or collaborate, but they are notable because they are the exception rather than the norm.
This can become so ingrained that it is hard for new graduates to adjust and successfully collaborate. On one graduate programme, one of the delegates refused to share his code with his teammates during a group project exercise. He considered it his code, and he didn't want them copying him – it had to be pointed out to him that the code was in fact the ‘teams’ and as a result the ‘companies’ code not actually his! It also had to be explained that they would all succeed together or fail together and that they were all responsible for the solution! This actually took some time to get through to him – time he had on the programme and time the instructor was able to give him.
The vast majority of commercial software development is a team effort - in my experience, this is somehow not taught within our educational system! In fact, students are often told not to work together, not to collaborate, and if they do, they may be penalised. Of course, there are exceptions to this, but they are notable because they are the exception rather than the norm.
This can become so ingrained that it is hard for new graduates to adjust and successfully integrate into their team. On one graduate programme, one of the delegates refused to share his code with his teammates during a group project exercise. He considered it his code, and he didn't want them copying him – it had to be pointed out to him that the code was in fact the team's and as a result, the company's code, not actually his! It also had to be explained that they would all succeed together or fail together and that they were all responsible for the solution. But the time afforded by the programme and in one-to-one interaction with me helped him overcome his initially narrow viewpoint.
AI and Training Programmes
AI is the solution! Now, what's the question? It is not that long ago that several organisations were touting AI as a replacement for their staff, whether that was to answer customer queries, design software, write software, test software, create images, etc. Around the same time, AI was also being presented as the ideal tool for creating training solutions! While it is certainly possible for an AI system to be used to help someone learn the very basics of Python for example, that is not the same as having a classroom-based instructor who can work with the delegate to help them gain a deep understanding of the concepts needed for high-performing and robust solutions to difficult problems. For a start, many AI systems require the user to ask the 'right' questions in order to whittle down the correct response and get a successful outcome. Which is fine once you know the questions to ask, but harder when you don't know what you don't know - and the right questions to ask!
A classroom instructor can also work with the subtle nuances implied by a student's question, which can reveal a misunderstanding or confusion over some point or idea. They can work with the room to help everyone grasp a particular approach, technology, or idea. That is, they can support and help the students develop and allow them to succeed where an online automated learning system would just let them fail – as it would not 'understand' their needs.
The Instructor
Of course, as an instructor, one of the greatest things about such a training programme is seeing a group of ‘fresh faced’ graduates, some or all of whom may have been non-programmers or non-technologists, grow and develop. Seeing them become the developers, testers, analysts and administrators that they have the potential to be is a privilege!
Of course, as an instructor, one of the greatest things about such a training programme is seeing a group of 'fresh-faced' graduates (some of whom may had little prior IT experience), grow and flourish. Seeing them become the developers, testers, analysts, and engineers that they have the potential to be is a privilege!
Summary
In summary, a training programme is hard to get right and easy to get wrong. The human instructor is key to its success. They are able to get to know the cohort, understand their challenges and help achieve their potential. In return the instructor has the satisfaction of seeing the programme delegates develop and grow and leave the programme capable of contributing to their organisations real world projects.
Would you like to know more?
If you found this article interesting you might be interested in our Graduate Training Schemes.