If you end up in a situation that main developer of project you are working on decides to leave.
He has all the knowledge, been in project from it's very beginning. If you are lucky you might get something like two month of him still on a project, if not it might be just a month leave notice.
What are best practices for knowledge drain, transfer?
What has proved been usefully for you in past? Pairing, presentations, documentation?
If you have enough time, get him to fully document the system, then go through both the system and documentation with him to ensure you understand both.
Don't rely on the fact that you will remember details. Take notes on everything he says during your transfer meetings.
I was pairing with a colleague in recorder sessions. He was giving me detailed explanations, walked me through the code and mapped features of the application with the code. After he left I spent several days in transcribing these recordings and making technical documentation which was used where I left the company some time after
Documentation is essential, but it should exist prior to anyone leaving. However, somebody leaving should trigger a cycle of editing/reviewing/updating.
Docs alone are incredibly dry however, and presentations are just a slightly more animated way of boring your soon-to-be-former colleagues, so in my experience the only thing of any real value is hands-on code walkthroughs, driven by the learner not the leaver in as small groups as possible. It is essential that the learner sees the code running, with breakpoints, exceptions, unit-tests and end results.
(And FWIW I believe all projects should be UML class diagram documented - boxes and lines are what I want to see when I'm learning an architecture)
I think regularly scheduled knowledge sharing sessions between paired developers works well. Make sure that at least 2 coders have some experience with each part of your code base.
We made a Knowledge Sharing Chart which listed each developers name in the margin and each project across the top. We put a green symbol in the box that would line up the primary developer with their project and a yellow symbol that would line up the secondary developer and that same project.
It was easy then, to go down the line of each project and ensure it had at least 2 marks. If it didn't then at our next major meeting we would let the developers decide which project they were secondaries on, but they all had to be a secondary developer on at least one project. This way they are learning about the projects they have some interest in and working with the developers of their choosing.
Some large or system critical projects had 2 or 3 secondaries. Each month we would schedule in knowledge sharing time in two hour blocks. You'd swap between going to your secondary project and people coming to your primary.
If possible i would say bring another senior/colleague who might be working on the same thing to the passdown meeting. Get the person to do a walkthrough of business logic and then the code if possible. the other person is important to provide a second opinion as they might catch some points that you missed out due to experience, etc.
And i echo Galwegian on Taking notes of everything down. just make sure that you keep them in legible writing :) And do a review of the material if possible after the meeting after like a good break in between, 1-2hours for the material to sneak into your mind. Then ask the person again whatever you don't understand on the next meeting.
I learn that if you leave too long before you review the material it's giong to be pretty much greek to you by then.
Just my two cents.
As well as static documentation as to what the project currently is, I also produce a record of what demos/experiments were performed and what decisions were made. The trajectory of the project matters, in terms of knowing what was already tried and failed, and what parts are in technical debt and why.
Don't believe that documentation is going to buy the knowledge accumlated by this developer.
I think the only way to get a real knowledge transfer is to have someone work in pair with him on the project doing actual work. He will then discover the small tips necessary to work in the project. I remember a case where our emulator does not work correctly in step-by-step but you can get it to work using breakpoints. This is a typical example of things you only learn by doing.
After the other developer has become more familiar with the project and way of using it, just review all the code, documentation. But the best is always if for each part of the project, they can do a small enhancement to use all the tools and discover all the quirks.