The software development unit agrees to train and drill together. What is the curricula? What is a good schedule?
First, let’s look at the curricula. A well-rounded development team should understand the following:
Language(s) | IDE (Visual Studio/VS Code) |
S.O.L.I.D. | TDD (including mocking and faking) (refactoring) |
Dependency injection | Network security |
Internet security | Identity and Authentication (SSO/2-factor/3rd-party) |
Clean Code | DevOps (pipelines/CI-CD)(repositories) |
Azure serverless functions/apps (or AWS if so inclined) | Business domain |
Most software developers may know their language and their IDE. A good software development unit should not overestimate their skills in any of the other areas. Even if they’re already exceptional, there’s always room for improvement.
Good training should occur for a day every two weeks (or more often if the unit finds a deficiency).
Good drills might cover the following:
- Refactoring
- TDD
- Lambdas
- Kata
Drills, even during days when developing, should occur every other day.
A month-long calendar might have these training and drill items. Blue items are drills and should not take more than about 30 minutes. Rose items are training and should not be longer than three hours.
Monday | Tuesday | Wednesday | Thursday | Friday |
TDD Drill | Refactoring Drill | |||
DI Drill | TDD Pairing Day | Kata | ||
Refactoring Drill | Lambda Drill | |||
Kata | DevOps Pipeline Training | Kata |
All together the amount of training and drill in 20 days of software development should cover about 10 or fewer hours. That’s about six percent of a software developer’s month. And that will bring the lowest performer up, share knowledge across the entire software development unit, and provide necessary breaks from software development that can be a strain if not broken by non-development tasks.
What About The Big Stuff?
Sometimes an individual or entire team should take days, or even a week or more, for targeted training.
When a new member joins the software development unit, the investment in their future of a week of the unit’s time may mean the difference between clean integration of the new member or a long-term friction between all unit members.
This doesn’t have to be a whole-unit training, although it might benefit all if the new member joins just in time for Node.js training, or introduction to functional programming. But more often than not, let’s imagine a one-week welcome training involving all members, one at a time.
Let’s consider a four member unit. The three current members are Red, Blue, and Green.
The fourth member joins and regardless of his or her experience, the first week might be scheduled as follows:
Monday | Tuesday | Wednesday | Thursday | Friday |
Domain | OO | Pairing | DI | Pairing |
Platform | TDD | Pairing | DevOps | Business Domain |
Project | Iteration | Pairing | Serverless | Security |
No single training session should last more than one hour. In this way, Red, Green, and Blue only volunteer five hours of the week to training the new member. The rest of the time the new member should be busy getting access to repositories, network resources, non-technical resources and support, and all the things a new member must do. And their formal training time covers fifteen hours; less than half their week. This way they don’t get any more overloaded than they must.
Training like this, on a one-on-one basis, introduces and enforces individual relationships even before the whole-unit training and formal software development begins for the newest member. In all cases during the week, the pairing is more of a “watch and ask questions” than “we expect you to contribute.”
Were each member of every team welcomed in this way, new members would become integral members much faster.
What Does This Look Like In Real Life?
Who knows? I don’t think it’s every been tried outside of the Rangers, SEAL Teams, or Airborne. But it works for them.