Take the 2-minute tour ×

Assume that you're a sole developer leaving a job. What kind of information/material, outside of the code itself, should you create and leave behind for your replacement?

An obvious answer is "whatever you would want at a new job" for sure, but it's been a while since I started a new job, and I forget what the most important things that I needed were back then.

I'm thinking:

  • accounts/passwords
  • location of equipment, backups, software CDs

What else?

share|improve this question
I'd leave them a checklist –  gnat Feb 1 '12 at 22:05
I will leave an opportunity to become a hero ... oh and lots of TODO in my comments. –  Job Feb 1 '12 at 22:22
Possible duplicate of What should I do to leave a job professionally? –  MichaelT Feb 2 at 17:56
add comment

11 Answers

  • Accounts & Passwords
  • Server information
  • Good code
  • Documentation
    • Database diagrams & explanations are amazing
    • List of oddities in the code
  • Procedures
  • Explanation of manual processes, or occasional, non-obvious, work
  • List of programs they used or found helpful
  • Contact information ;)
share|improve this answer
list of source control locations! –  HLGEM Feb 1 '12 at 22:07
@HLGEM if the code they use already is in source control you just have to check the remotes –  kyrias Mar 31 '13 at 15:39
@Demizey, Maybe your source control is easier to understand than ours, but I just transitioned from ope project to another and I had to show my replacement the many different locations she should put the code depending on whether it was a one-time data fix, an import, an export, a report, a change to the application or a client customization. And when you work on a cross-functional team as I do, I have maybe 30-40 different places in source control to know about. –  HLGEM Apr 1 '13 at 13:45
I'm happy I answered this. I recently left the job I was at where I wanted all of this, and this gives me a good checklist of what to write up. –  Slokun Apr 4 '13 at 20:47
add comment

A strong cup of coffee and an apology note.

Is what I wish I was left.

  • Documentation. How hard is it to write a few comments? Build notes, deployment notes, moving the system notes. What to do when you restart and everything is gone.
  • Papers. Write up why it's being done this way so I don't have to wonder why you aren't doing it another way. How does the backup system work, how does the server respond to loads, testing, test cases, use cases.
  • Notes. "When using the database, don't ever say SELECT * FROM clients. We aren't sure why but it dumps the database".
share|improve this answer
add comment

My email address, or perhaps even phone number.

In my experience it's difficult to get every detail written down, so the best thing is to be available (to a certain degree) if your successors need more information.

share|improve this answer
e-mail sure, but rarely do I ever give my phone number out to anyone that I don't know well personally. –  Steve Evers Oct 8 '10 at 19:58
Good point, I toned down the part about phone number. –  Vetle Oct 8 '10 at 20:04
This might be a political issue whether you can do that or not. –  user1249 Jan 31 '11 at 22:00
@ThorbjørnRavnAndersen Political or social? –  Aaron McIver Feb 1 '12 at 22:45
add comment

Documentation of the programs you have written e.g. their purpose, location of source files for future development, passwords, etc..

This can either be within the code as a comment or outside in plain sight.

share|improve this answer
add comment

More than just documentation, I'd like to know why certain decisions were made when they were made. We're using SWIG currently on a project and one of the other developers wanted to know why we just didn't use Boost::Python. The simple answer was that the customer did not allow the use of Boost at the time. Now is a different story.

Such things will help them not only in understanding the project but also what limitations/constraints/challenges your implementation overcame. It'll give them a starting point for future maintenance and feature augmentation.

share|improve this answer
The key advantage with having a recorded “why” is that it allows you to revisit the decisions when the constraints change. Heck, it will help you understand what those constraints actually are. Very valuable. –  Donal Fellows Mar 31 '13 at 17:41
add comment

If it is a desktop program, how to build the entire system from scratch (may be several separate programs), how to create a package for distribution (what dependencies it has, e.g. versions of .NET), and how to deploy it to servers for download if that is applicable, or burn it to a CD or DVD.

If it is a web-based program, FTP and (if applicable) SSH access to the server, and what tools are used to locally create and test the code.

If it is an embedded system, complete instructions on building the binary image, what tools are used, how to download and flash the code into the product, how to set up the filesystem on the device, if any.

share|improve this answer
add comment

One thing I didn't see anyone else mention (although I might have overlooked it) is to document how to setup a dev environment. I realize that most of the time it's just install a few things, get latest, compile and you're done. However sometimes there's more to it than that (SharePoint is one situation that comes to mind) and documenting what flux capacitator has to be configured in what way will be very helpful for the poor soul following you.

share|improve this answer
add comment

I just recently left a job in similar circumstances to you (I wasn't the only developer, but there was really only two of us, so I had quite a lot of knowledge that the other guy didn't have (and vice versa, of course)).

In terms of the normal documentation stuff, it's important to document an overview of the whole system. Individual components are already documented in the code, but the interaction between components and why this does that or why this needs to talk to that component are important and not always easy to figure out just by debugging/looking at the code.

Then, for about a month before I left, every time I did something that only I could do, I wrote down exactly what happened, what I had to do, and why. This was usually a case of "there was a bug in xyz component, to fix it I knew to look in file abc because of X, then I had to do this, this and this".

Of course, I left my email address and phone number in case anything came up that they couldn't figure out on their own. I got a few calls in the first few weeks, but they slowly dropped off.

share|improve this answer
add comment

We'd all like a complete data flow diagram of the system with a list of functional requirements. More than likely you never got that when you wrote the system in the first place ! Like most places the best documentation is probably the code itself so what I would love most is well documented code. Lines and lines of comments in the code explaining what you are trying to do both technically and functionally.

share|improve this answer
add comment

The #1 rule for documentation is not what it does but why. What's the backstory on the programs that run, and what they do?

share|improve this answer
add comment

I think what I would love to see in documentations besides the usual would be what features were left out. Like why certain ideas were NOT implemented or a certain platform or method NOT used (which was otherwise an obvious choice).

This makes sure that the successor always knows what not to do or if he is more capable then maybe he can come up with a work around and make certain features work.

This is especially applicable to open source projects. Can save a lot of time and brain power!

share|improve this answer
add comment

Your Answer


