Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Thanks!

share|improve this question
add comment

5 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

Stick with the big picture

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.

share|improve this answer
add comment
  1. 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.
  2. Give more focus explaining basics and big picture. Don't go into details.
  3. Just let them know where all to start to debug.
  4. Keep asking questions, encourage them to ask questions while presentation is going on.
  5. Don't make session too long. Give breaks.
share|improve this answer
add comment

In addition to the other answers, if there are any current bugs on the code you're going over and there is time allowed, perhaps you can go over how you would fix one or two of them.

Not only does it give them some idea about what kind of issues there are and a chance to go over some of the code, but it gives the others an idea on how you would go by to debug an issue.

share|improve this answer
add comment
  • Have multiple talks, each only an hour long.
  • Make lots of eye contact with each developer in your audience.
  • Talk clearly and not fast.
  • Go silent when appropriate to let minds clear and concepts sink in.
  • 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").
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.