We've been exploring the tale of the startup and the engineer, and how their fates became entwined. First, we looked at the hiring wish list -- the job description -- drawn up by the managers of  WidgetCo, a company focused on Ruby on Rails. Next, WidgetCo met an engineer, and although they weren't perfect for each other, they all took the plunge: WidgetCo hired a "trainable" Java engineer with a lot of skills with some differing technologies. WidgetCo knew they'd have to train him. Here's how it went. Dec. 3, 2012, was Java Guy's first day. He showed up at the office at about 9 a.m., brandishing a small library of Ruby on Rails books and a willingness to learn. In the month since he'd received his offer, Java Guy had been very busy. He'd given notice at his old job (three weeks instead of the usual two, to help them finish a big project). He'd bought a subscription to an RoR podcast series and was following along with the exercises. He'd  also started reading about the interfaces that WidgetCo had discussed during his For its part, WidgetCo was ready for him. He had a desk — OK, it was a folding table — all set up with a brand new laptop and monitor. Zack, the team lead, was sitting at the next desk. It was time to teach Java Guy how to be a Rails engineer. Since WidgetCo is a small company, it doesn't have a formal training program. Fortunately, its does have a strong sense of teamwork and a culture that encourages learning. Let the retraining begin!

But First...

Before we continue, let's take a look at on-the-job training in general. When training, there are two areas to consider: what to train people on, and how to train them. Together these are the inputs to a good training plan. Understanding what to train on is often the first consideration. In principle, it's pretty simple: Get them up to speed on all the gaps between their current skills and the skills they'll need to do their new job. In short, everything from the job description that you didn't get is now a training opportunity. In practice, you're not going to train someone on every skills gap. Some things the trainee will learn on his own. Some things won't be as important as they'd seemed earlier. There will also be some new things — new needs or new skills — that you didn't anticipate didn't anticipate. Nonetheless, when creating your training plan it helps to start with the skills and technologies listed in the job description.

The Question of How

The "how" of training is less prescribed. There are many possible methods, from classes to books to online tutorials to one-on-one mentoring to throwing the trainee into the deep end of the pool and hoping he doesn't drown. For the trainee, preferred methods are based mostly on ways he learns well. Some people simply learn better in a classroom, while others do better learning from books or by writing sample applications. For the company or person doing the training, other considerations will drive the training options:

• Budget: This tends to eliminate options quickly. Classroom training and conferences in particular cost several thousand dollars each.
• Timing: Many training methods are available all the time, but some — again, classes and conferences in particular — are less frequent. Other methods, like code reviews or pair programming, are only feasible if there's a team member with a lot of availability. Depending on where the team is in a release and development cycle, spending time on intensive personal training sessions may not be feasible.
• Availability of training options: For some technologies or some practices, there are no online tutorials. Reading the spec is about as good as it gets. For others, there are a plethora of options.
• Intensity: Training is useful, but at some point the trainee has to start actually working. The training plan needs to balance learning with having a productive team member. That means you can't schedule all-day training sessions for months or even weeks. It's unproductive and likely to demotivate the trainee.

Within those considerations, consider the following options:

• Read the code: This is probably the most common option, and it's very attractive for the employer, mostly because its low cost and reasonable efforts for the existing team. The gist of this approach is that the trainee is given access to the code, assistance compiling the project, and told to have fun. It can be helpful, but it's not very directed. Still, it's a good option for someone who understands the technologies and problem space, and is simply looking to learn the particular implementation. It's not a good way to learn new concepts, because it's hard for the trainee to get any feedback or to know whether he's learning anything useful.
• Classes: In large companies, there's often internal training designed specifically for new hires. Even if it's optional, take advantage of it. In smaller companies, classes are usually external. They range from semester-long college courses to one-day or partial-day sessions offered by local user groups, training companies or consulting firms. Classes offer structured learning and frequently include tests and certificates (great for showing to HR), but can be expensive and sometimes slow. This approach is best reserved for learning major technologies that have widespread adoption, usually languages or frameworks.
• Online tutorials and katas: These are basically classes, just in a different format. The online format may be more aligned with the trainee's learning style or schedule.They also tend to be much cheaper than classroom training.
• Books: Books are great for reference and for conceptual understanding. If you're trying to teach someone about object-oriented programming, or patterns, get that person a book. "Cookbooks" and references are also useful for people learning a new language or framework. When the trainee has conceptual knowledge but needs help with syntax, a reference book is ideal for very targeted learning. However, they tend to lag technologies due to their publication cycle, so be mindful of versions and age, and consider ebooks for languages or frameworks that change rapidly.
• Code reviews: Code reviews are targeted reading of the code with feedback. Having the trainee perform a code review requires them to read some code, understand it and question it: Under what circumstances will it break? Is there a better way to accomplish the objective? Could it be structured better? Does it have the appropriate level of defensiveness? Asking those questions explicitly and then getting feedback is a tremendously valuable learning experience. Not only is the trainee learning the standard technology concepts and practices, they're also learning the way those practices are applied in the particular environment.
• Pairing: At some point training turns into doing: working on the company's product. After all, the trainees was hired to get things done, not just learn things. Working alongside an existing employee, sharing the screen and discussing the thought process involved in accomplishing a task provides a very rich opportunity. This way of training is targeted toward the company's product more than any other method. It provides a lot of applied learning, revealing the nuances of your particular implementation of a technology or concept. It's very time-intensive for both people involved and requires room in the schedule for a short-term productivity loss, but it's low cost and highly effective.
• Structured assignments: With this approach, the person is given a task — fixing  a bug, adding a feature — that will help them learn the code base. Structuring assignments from something straightforward and isolated to something more complex helps guide them through the code, learning one piece at a time until larger and larger sections are apparent. This method suggests a series of tasks in increasing order of complexity: (1) fix a bug in a single area, (2) modify an existing feature to extend it based on a currently implemented pattern, (3) implement a new feature following a currently implemented pattern and (4) modify or implement a new feature using a new pattern or variation on a pattern.

A successful training plan considers what the trainee needs to learn and combines several methods to encourage the learning of concepts and product-specific or company-specific nuances. Next time we'll look at WidgetCo's specific training plan, and how Java Guy did with it.