In recent months I've been working on a project, and two weeks from now I'm leaving the company. I've scheduled a 4-hour training session next week in order to train my colleagues (the team leader and fellow programmers) on this project. One of the programmers has already written some code in it, so I'm not leaving the team with zero knowledge, but I'd like the others to be experts as well. The project has a few thousand lines of code, it includes some concepts which are new to the team (such as ORM and IoC), and due to its central role it will probably be heavily maintained in the future.

So far I've written two presentations about different modules of the project, so these presentations can be used both for the current session and for training programmers that will come to the team in the future.

From your experience, how can I make this session fun and effective? I really want this application to be maintained well, I'd like to leave a "fine legacy", so that the code will be maintained in the same spirit that I intended it to be.

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – enderland, durron597, Snowman

5 Answers
5

You will not make anyone an expert on any system in 4 hours, but you can certainly provide them the basic information that will allow them to self-instruct towards mastery in that span.

Presentations are beneficial so far as the diagrams provide good reference material, but if you look at it objectively, how much has any presentation really ever taught you? You'll probably conclude that you haven't learned anything from presentations, you've learned by doing.

The most effective method of getting them to learn the code of the project is to walk them through it. This is more about you coaching and them clicking through and being able to ask questions. It would be handy to have visio (or similar) diagrams of any interactive systems for particular processes (WCF services, data connections, etc) or other reference materials about how the classes and objects should interface together (perhaps a class diagram showing your object heirarchy).

A single 4-hour session may not be ideal, but if that's what you have to work with then so be it. I suggest you break your 4-hr chunk into manageable chunks of time to allow for time away from the computers/presentation, questions, etc. Each chunk should cover a module of your project and should have a very specific goal (e.g.- At the end of this session you should understand the data control class structures).

If you have a set of business requirements you are programming against, make sure the team has a complete list of accomplishments for each item. If some of them are complete only on paper or in your mind, write these notes down in a comprehensive list. It will help the team understand decisions you've made if they know the path and direction you were taking to complete the requirements.

Focus on the concepts that are new to the team. Provide external resources they can reference for learning more about these concepts. Hopefully if your team has established standards, practices and patterns, there should not be a lot of new material to cover.

In the four hours, focus on getting them a view of the basic premise of the design and the technologies in place. Metaphors for how you approach it, common places to find issues, points of brittleness and places to look out for. When I really understand a piece of technology, I can usually give some metaphors and funny examples that will give people a way to approach it. Plan to have a white board around so you can draw some pictures.

Plan this as 1 hour of you talking, and 3 hours of you getting interrupted and answering questions. Let the team drive you - and if they aren't, focus on drawing them in with areas you think are likely to impact them in the future. They should have a vested interest in learning how to maintain this, since it sounds like they will have to!

If you think it'll go this low - have examples close to hand so they can see the code and configuration and discuss it.

Spare the details

If you have some good, detailed how to steps or other long explanations - write them down. Put them in a shared workspace and mail the team. I often phrase these as "break the glass in the event of emergency" - what to do when you have a crisis that looks kind of like this... that'll get them through the first few panic circles, by which time they will hopefully be familiar enough with the technology that they can really take ownership.

At the beginning of the session ask for their expectation and collect all the questions which are there in their minds (don't expect only for impressive questions). Your presentation should go in way that it answers all their questions.

Rather than using slides, walk through the code and the live application.

During the code walk through, explain design decisions and invite feedback on the code. Cover high level components first and drill down when important. Explain the why of the code that is hidden in your head. Perhaps explain some alternate approaches that you didn't use; why didn't you do it that way?

During the live application walk through, don't get bogged down with every detail but show the main components and sections. Show a few (but only a few) interesting details. Tie those back into the code walk through with references ("here's that code we saw that did such and such in action").