So, I just received news that I have to train current developers on our current code base and architecture to bolster our ranks and make products faster. Problem is, I know I am not a good teacher and both of these programmers are current employees but with more experience than I (however, different projects, frameworks, and languages). I am working with my Architect on this, but I was wondering if there were a few tips for on-boarding new members on a project?

I know I usually just jump in and learn as I go after reading the documentation on the current design/etc. But, these programmers are a bit "set in their ways" if you will.

Again, any tips on how to train other programmers? Topics I should hit and stress? How I should present it?

The answer is unfortunately dependant on the code base, the type of work they're going to be doing, etc.

Generally, when I'm training a new developer, I will walk them through a few critical code paths, showing the major components/subsystems and how they interact.

For a more experienced developer, I'll probably spend less time explaining the basics (they can figure that out themselves) and more on the "gotchas" in the system ("X must be initialised before doing Y").

As frob said, giving them a few simple, low risk tasks is the best way to let them familiarise themselves with the system.

Another option is to get them to refactor that thing that is pretty hideous, but you never get time to fix.

It's difficult to put new developers on refactoring tasks because they generally require a lot of intimate knowledge of the code being refactored and how it interacts with everything as a whole. It's often also difficult to make the case for refactoring to the customer because they might not see the tangible benefit, so if it's going to happen at all you want it done by someone who can do it in a timely fashion. It's asking a lot of a developer to refactor code they don't have much (or any) experience with, learn everything they need to as they go along, make sure they do it correctly and not break any existing functionality, actually *improve* upon what's already there, *and* not take too long with it because there are other critical issues to address. At the same time, if you just give them menial labor like "change debug message X to Y", then they won't learn much about the particulars of your codebase, or be adding much value to the product.

That's why I would only do that in the case of experienced developers. And the whole point is that because it is generally non-billable work, you can get it done while the developer is learning the system (a time when they are generally not very productive anyway).

Addtionally, I wouldn't put them on a system critical path, and in an ideal world, there would either be a suite of unit tests around said functionality or I would ask the devs to write a wrapper around the existing functionality, unit test that and then do the refactoring work.

But again, it depends on the codebase and the type of product being worked on.