What should I do to leave a job professionally? [duplicate]

Question

Given that the current employer knows and has been given appropriate notice ahead of time, how can a programmer make a clean job transition from his old job? What things should the programer consider? How should one tie up unfinished projects? For example, should one make a list of places they have password access, or a master password list to hand over?

When I say "clean transition", I mean where one would leave the company without leaving any messes, drama, or headaches, and still enabling the company to hire someone to replace you and continue work without problems. (For example, suddenly disappearing and not returning is not a clean transition, nor is encrypting all one's code into types of food).

Answer 1

It is advisable to organize your work during the entire time in that fashion that your sudden demise would not wreak havoc on the company operation. One should always keep this in mind. Keep things clearly and logically structured, report your progress regularly and check things in promptly.

What you could do specifically in your last days:

• Prepare a list of credentials which are supposedly unknown to those to replace you

• Prepare a status report concerning your projects and their status

• Document any open and outstanding issues that you intended to take care of at some future point of time

• Ask your superiors if there is something specific they want you to document

• Ask your superiors if there is any tutoring they want you to give to anybody involved

• If you were involved in dealing with customers and external parties it might make sense to notify them of their upcoming contact change. But ask for a permission first, sometimes your superiors don't want the customers be notified of people leaving.

That pretty much covers it.

Answer 2

Lets face it, we all have documentation debt. The last two weeks is a good opportunity to get those last few items into writing or into your co-worker's heads. If you create a document, make sure you review it with the intended recipient to make sure it's understandable.

Confirm that all the code you were working on compiles, is checked in, and if possible passes any unit tests.

Create a list of duties you fulfilled while there, including the unpleasant ones you don't want on your resume, and provide it to your superiors. This will allow them to make sure all your tasks are covered, and hire an appropriate replacement.

Ensure that all your data is backed up and made accessible to your co-workers.

Make note of the phone numbers of people you want to keep track of!

Answer 3

I can never forget this post by Mike Hofer in "What's your most controversial programming opinion?" whenever a question along these lines is asked...

Your job is to put yourself out of work.

When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.

If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.

Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

I believe that ideally, both on an individual and a team level, all software should be written to be as easy to pick up as possible. Literally: if the entire team gets food poisoning and dies when going out on a team lunch, the company should be able to hire a new team of developers - and the project should be so clean and well documented that the new people can step in and get to full productivity within a couple of weeks.

So essentially, I think it's more of an "ongoing process" thing than anything you should have to do when quitting. It's not always practical in every single moment, but I believe it's best to work as if you might be dropped off the job at any moment. Code, document, and adhere to processes such that any decent developer could step into your shoes at any time, and not tear their hair out at anything because it's too obtuse.

Answer 4

One thing I like to do when switching jobs is spend some time during that last week making a TODO list for the developer that will be taking over.

Explain where you're currently at in the schedule, why you've made some key architectural decisions and where things need to go.

Obviously things like passwords - how to run the build process - etc should be easily available.

Answer 5

I would add @Developer Art's list:

Make sure everything is checked in source control (with comments) before you leave (it's really annoying when someone forgets to do this).

Make sure they know specifically what is what is not finished in currect projects as part of your status list.

If you have emails that will be pertinent to the next person being assigned to the projects that your boss does not have, forward them to him.

Even though manaegment should know where things like project requirements and source control files are, it is helpful for them to have a summarizing document that they can give to the next person assigned rather than having to create that themselves. Think of all the things you would want to know about an ongoing project in your new job and put that in a document for your boss concerning your current projects. If you are on more than one project, do a separate document for each.

Answer 6

As far as passwords go, there are two considerations. I generate new random passwords and change them, and at the same time write a list. That way I know that they have ongoing access and we both know that I don't.