This is to cover development related training, (so no Human Resources (HR) training is listed here).

Why training does not occur

The industry is full of companies that do not invest in training for their developers. There are many reasons training does occur and for every company these reasons may be slightly different.  Here are some that seem prevalent.

1. There is an assumption that developers do not need training.
2. They assume developers train themselves.
3. They cannot afford training.
4. They haven’t even thought about it.

Of course, many software development companies provide excellent training, so this article may not apply to them.

Why you should train your developers

Training is extremely important and this article exists so that if you are in a software company that is failing to train your developers, your development department can take steps to improve this.

To make correct decisions

Many software development companies fail in many areas. Training will not guarantee success in these failed areas, but it will increase your odds of success significantly. Often developers are treated as experts and analysts for tools and processes to perform their jobs. Developers often get to choose their source control tool, 3rd party libraries, the branching strategy, and more. Unfortunately, most developers are not trained System Analysts so they do not actually have an expertise in how to locate multiple products that feel a need, research which is best, and choose the one that is best for the company. Instead, the choice is often made because it is the first tool or process the developer found or already knew about that works for their very narrow need at the moment.

If your developers are well-versed in a topic and know the options and the pros and cons of each option, they are more likely to make correct choices for your company.  Ask yourself and your team about your current tools and processes. Is your development department just using these tools and processes because they are the most common, or because a skilled analyst determined that process fit your business?

When you hire a new employee, or when you implement a training program among existing employees, it is difficult to know where a developer stands in regards to training. If you want to find out where a developer is at, and help them move to the next level, you need a tracking system.

To grow as a developer

You may find that developer grow at a fast rate their first few years. But then, this growth may stop. A developer’s skills may stagnate. They know enough to do their job so they don’t continue to learn.  This is a problem because new technology always comes out and new tools are released to aid in their job.

To maximize productivity

A trained developer should produce code faster and with higher quality.

Software Development is always improving and something that may take a day today, might take 30 seconds and one line of code a year from now due to either a new tool or a new library.

To improve quality

There are a lot of bugs per lines of code and training, especially on quality topics such as design patterns and unit testing, can really improve the quality of a product.

How to track a developer’s training

I designed a simple tracking system. I made a list of topics (which are by no means complete) and subtopics. I gave each sub topic three levels to show continued growth.

The following is a spreadsheet version of the simple Developer Tracking System I created.

As a Google Doc: Developer Training Tracking Checklist
As Excel: Developer Training Tracking Checklist
As Excel (inverted) Developer Training Tracking Checklist – Inverted

Basically, the items that you should train on are as follows:

Here is the key:

Key or Legend

Training Topic = A broad general development topic. Example: Source Management
Sub Topic = A more specific development topic. Examples: Source Control Tool, Chosen Branching Strategy
Level 1 = Often over the shoulder training of a new hire. A basic overview that is enough to get them working. For example, what are the basics for using TFS. 1-4 hours. All level 1 trainings should be provided within the first three months or at first use. Level 1 can be marked off without training if the employee demonstrates they are already at a higher level.
Level 2 = Usually in a formal training or an online training. A more in-depth overview of the sub topic. 8+ hours. All level 2 trainings should be complete by the end of year 1. Level 2 can be marked off without training if the employee demonstrates they are already at a higher level.
Level 3 = Expert level training. This could come from combining a few trainings, such as one or more Text Books, Online Research. 24+ hours. Level 3 trainings take time. The should begin after the first year of employment (unless a job requires it occurs earlier) and one or two should be completed each quarter. If an employee thinks they are already at a level 3, they should create a portfolio of information describing why they are at level 3 and present to a peer group of four or more individuals. If at least three of the four agree, then Level 3 is passed.

Training Types

FT = Formal Training. Hopefully in a classroom by a technical trainer.
OR = Online Research. Employee reads blogs and articles about the subject and indicate the articles and blogs read.
OT = Online Training. A formal training delivered online.
TB = Text Book. A book about the subject. Indicate which book. Also, the book should be read by multiple developers who should meet every other week to discuss the topics in the book.
ST = Shoulder Training. A person trains from over the shoulder. You may want to track who provided the training.

Hopefully if you are a VP of Engineering or CTO of a development company, you can take this and implement this in your environment.