And now, the thrilling conclusion to our tale. After completing a hiring wish list, meeting a prime candidate and considering what goes into a training plan, the startup WidgetCo and its new hire JavaGuy were ready for their first day. The first draft of WidgetCo's training plan looked like this:

Give him an assignment, and be around to answer questions.

That is a recipe for failure. The basic idea is sound: Let the candidate learn by doing, and answer any questions he has. The devil is in the details, however. Which assignment? How does WidgetCo make sure JavaGuy is asking questions and not merrily coding away -- badly? How does WidgetCo make sure that JavaGuy isn't sitting there completely lost? More thought was needed. For WidgetCo and JavaGuy, the training plan needed to emphasize speed of learning and self-direction. WidgetCo hired JavaGuy specifically because he was someone who had a long history of learning and he wasn't shy, either. The company didn't have the resources -- people or money -- to create a long, structured training process. Instead, it emphasized pairing, code reviews, structured assignments and good online tutorials and books. Ultimately, WidgetCo's training plan looked like this:

• Week 1 - Focus: Learn WidgetCo's tools and code base. Activities: small, supervised changes; intensive learning.
• Week 2 - Focus: Learn development practices. Activities: Build a larger feature; participate in the development process.
• Week 3 - Focus: Interfaces, particularly in financial services. Activities: supervised architecture, interface-related change.

So how does that plan break down in reality?

Day 1: Plunge in Head First

The trick for Day 1 is to keep JavaGuy excited, and get him productive without completely overwhelming him. WidgetCo wanted him to go home tired and excited, not to convince him it was too difficult for him to learn. Day 1's goals were:

• To download, install and build the project.
• To run all the tests.
• To walk through the stories and team activities together.
• Welcome lunch (and NOT pizza, please!).

By the end of the day WidgetCo's existing developers, Mark and Jeff, had JavaGuy's environment fully configured and he was running tests and reviewing code.

Week 1: Small, Defined Tasks and Learning the Dev Process

For most engineers, including JavaGuy, "reading the code" is not only unproductive, it's frustrating. It sure doesn't feel like you're accomplishing anything. So WidgetCo focused on providing JavaGuy with tasks that were structured so he could succeed. "Learning the code base" would happen as he accomplished the tasks. The goals for Week 1 were:

• Pair with Mark and Jeff to see how they think through problems.
• To successfully accomplish several small tasks (think defined bugs).
• Self-directed learning.
• Bring JavaGuy into the development team practices.

Week 1 activities were:

• Daily standup.
• Weekly team lunch and "week in tech" review.
• JavaGuy leads a code review for one of Mark's pull requests. Jeff will also review it so they can discuss not only what they're looking for but what they find.
• JavaGuy gets his first assignments, in this order: (1) a small, straightforward bug; (2) another small bug; (3) a feature worth 1 point in the backlog; (4) his choice of bugs or 1-point features for the rest of the week.
• Jeff and JavaGuy pair to deploy to staging. This will make sure WidgetCo has set up accounts correctly and show JavaGuy how WidgetCo deploys.
• Leave JavaGuy alone with the books and the "good online tutorials" page on the WidgetCo wiki. Some breathing space will be welcome for the whole team.

Week 2: More Development Practice

Week 2 continues the focus on WidgetCo's development practices, and hands JavaGuy larger and more complex assignments as he starts to get more comfortable. This week's development practices include test driven development (TDD) and larger features requiring small amounts of architectural decisions. The goals for the week are:

• To accomplish a reasonable size (read: 5-8 point) feature.
• To explore test driven development.
• To learn WidgetCo's monitoring tools.

Week 2 activities are:

• Test Driven Development pairing session.
• JavaGuy reviews every pull request, with backup review by Jeff and Mark.
• JavaGuy is assigned a 5-8 point story, which includes making some implementation choices that iterate on the current architecture. Mark will review JavaGuy's proposed implementation plan after he's considered it (but before he has started writing code), and Jeff or Mark will check in with JavaGuy a couple times a day to see how it's going.
• Mark reviews WidgetCo's monitoring tools -- NewRelic and the ZenDesk reports -- with JavaGuy.

Week 3: Interfaces

Week 3 begins to focus on WidgetCo's interfaces, both current and upcoming. This starts to lean on JavaGuy's interface design and development skills, even as the implementation gets more involved and more complex. The goals of the week are:

• To learn about interfaces in this industry.
• To review and understand the implementation of the current interfaces.
• To learn how WidgetCo has developed and tested third-party interfaces so far.

Week 3 activities are:

• A four-hour brain dump from the sales guy on interfaces used by current customers and potential client interfaces. By this time, JavaGuy has seen some of the code, and the conversation helps him understand the "why" and the business needs behind the code.
• A solid day reading the history, specifications and regulations of the two biggest interfaces. (JavaGuy drank a lot of coffee that day.)
• JavaGuy is assigned the top interface story. Jeff pairs with JavaGuy to review how they test the interfaces, since it's a little weird.

Overall the training plan tries to teach JavaGuy a lot, and quickly, but without completely overwhelming him. At any point, the goal is for JavaGuy to understand about 50 percent of what he's doing and have the rest be new to him. During week 1, JavaGuy is learning the system and the language (50 percent learning), but is also tackling straightforward problems with obvious solutions (the 50 percent he's comfortable with). During week 2, JavaGuy is building on his knowledge of the code base (the 50 percent he knows) while tackling more complex problems and new development practices (the 50 percent he's learning). During week 3, JavaGuy is way out of his comfort zone working with more complex architectures (the 50 percent he's learning), but he's doing it through the lens of an interface (the 50 percent he's comfortable with). This balance -- learning a lot but from a base of knowledge -- is key to a good training plan. But the most important part of our story is the ending. It's now been about four months and JavaGuy still works at WidgetCo. To be fair, the training plan didn't turn out exactly as they'd intended. JavaGuy struggled a bit during week 2, so they decided to repeat the week. Mark was out sick for part of week 3, so Jeff did more of the training than originally planned. Overall, though, everyone's happy. JavaGuy now tackles the next features on the list, and is working on implementing a major new interface for a potential client. Mark and Jeff are learning a lot, and have added some stories to the backlog to clean up their existing interfaces based on some of JavaGuy's feedback. A few code reviews produce the comment, "that's so Java of you!", but it's all in good fun. The bottom line: JavaGuy is a great new member of the team.