What is the process for leaving a company (or even a group/division) in terms of code support?

Is it best to handle all questions? Do you give the remaining developers access to yourself as a future resource? If so, is there a way to not give full access?

I've experienced first hand where answers about the general software arthitecture from the initial developer would be invaluable.

I understand that if serious assistance is needed, than it becomes a typical case of employment negotiation as a support contract. However, should serious assistance be required, what steps can you make to ease that process of contacting you?

I was thinking of doing something like making a (YOUR_NAME)_codesupport @ (YOUR_FAVORITE_EMAIL_CLIENT).com address.

My Situation Specifics:

I'm a co-op student, and as such bounce around companies on 4-month stints. This means introducing myself to a lot of new code bases, as well as leaving a fair share of orphaned code behind when I leave a company. I feel bad if I leave junk code around.

  • 2
    No offense, but I doubt you're going to achieve anything significantly complex in the span of 4 months that any experienced developer couldn't handle. Jan 4, 2013 at 9:48
  • 1
    @Caleb has the right answer. Except - you're a co-op student, which means you hope at some time to get a full-time job in this field, and you're working with companies part-time to get both experience and contacts. So temper the "@#$@$#@% off, I'm gone" attitude with a little "Hey, I'd love to work with y'all in the future". Jan 4, 2013 at 12:03

5 Answers 5


How do you support your code post employment end?

You don't. That's why it's called the end.

If they'd be surprised to see you walk through the door and start using their equipment a month after you left, you should be surprised to have them call you up and ask a bunch of questions a month after you left.

Okay, more realistically, depending on the situation, you might offer to answer questions by phone or e-mail for a bit, especially if you a) would like to go back there, b) are friends with the people who work there, c) are still depending on them for a good review, d) feel pretty confident that the company won't abuse your goodwill gesture, and/or e) the company is willing to compensate you for any non-trivial additional support.

This means introducing myself to a lot of new code bases

That's a good skill to develop -- you'll need it.

as well as leaving a fair share of orphaned code behind when I leave a company.

Part of your job while you're still working there is to document what you've done, or at least make sure that some of the other people working there have a clear understanding of it. That's something that's in the company's interest, and they should make sure they have what you need while you're still there.

I feel bad if I leave junk code around.

Don't write junk code in the first place. If your previously-good code becomes junk (obsolete, no longer needed, etc.) before you leave, then clean it up before you leave. If your code isn't junk when you leave, then what happens to it afterward isn't something you should worry about.

  • 1
    Considerations B and D are the only ones that will prompt me to leave contact information. I didn't really do my job at the exit if they frequently need to call me later. Great answer.
    – user53019
    Aug 24, 2012 at 3:18
  • 2
    Often companies make it the responsibility of the person leaving to train up their replacements and blame the person leaving for any knowledge gaps afterwards. However, it is really the responsibility of the replacements to ensure they have the required knowledge to do their job. Unfortunately, few companies realize this.
    – akton
    Sep 3, 2012 at 7:20

Normally you prepare for this about 2 weeks before your scheduled end date. Plan some time for a knowledge transfer to another member of the team and try to make sure that they can support the code before you've packed up your desk. Don't set yourself up to be on perpetual support by putting your contact info in the code. If the situation is so serious that no one but you can fix it, they can probably get your contact info from HR.

  • 5
    Yeah, but in reality its the reason you give notice to your boss. Its they're job to ensure they are covered before you end up leaving.
    – Doug T.
    Aug 24, 2012 at 1:16

Train up the person replacing you as much as you can (if there is someone).

I find it best to leave documentation with the code, preferably checked into source control if there isn't a central documentation system. Whatever you do, document as much as you can about:

  • How to get a completely working system up and running on another developer's computer
  • How to build
  • How to deploy

Put a copy of everything in a central place.

Email all the details to any stakeholders.

I always make sure they understand they can call me if they have a question, like where did this go, etc. It's quite common for them to call you later and ask if you want to do work on the side if they're in a bind. That's up to you based on your new situation and employment contract. Nothing wrong with saying, "sorry, I just don't have the time right now." It's almost always true anyway.

  • 2
    "Take a copy of everything" but be sure to follow applicable employment law. Some firms forbid this, and you can create more problems by trying to be helpful.
    – user53019
    Aug 23, 2012 at 21:26
  • 1
    I don't think he means "take a copy with you." Most firms have an archive where they keep copies of software releases. Aug 23, 2012 at 21:46
  • 2
    @GlenH7 - I didn't mean you should take it with you. I'll edit to clarify. Aug 24, 2012 at 0:00
  • There was large thread on whether or not to take code with you. The legal concerns (IMHO) are the biggest issues. Your edit makes your intent a lot more clear, thanks for putting that in. I'd upvote your answer again, but, um, the system won't let me for some reason. ;-)
    – user53019
    Aug 24, 2012 at 3:16

Few things I would like to mention.

In business, money is above sentiments. The employer usually do not have the same sentiments you have from your own side. Once you leave the company, the deal is done. The negotiations and the notice period stuffs are steps to mitigate their risks.

Of course people helps each other with their personal choices but companies really don't expect you to come back fix the things for them even you wrote in the past. But there are exceptions but it depends on how you're important to the work.

One of my friends had left his company 1 year back and recently he was contacted by one of the project managers to fix an issue with the code he wrote few years back. Considering the turnaround and the complexity to fix the issue, he was the easiest option. Finally he helped them to fix the issue; but on his personal interests and ethics. And note that several employers can't agree with this. i.e he's going back to his old company and fixing issues.

Things you've to notice is that,

  • Those who do serious business act professionally in this situation. They don't want you anymore.
  • The highest chance to get a call from ex-employer is a personal call. Usually it will not be an organizational decision to approach you and fix the code. Also they do respect your time and current assignments before asking your time.
  • Corporate companies maintains at most secrecy for their code and design. They don't want to expose even to ex-employees.
  • Mostly the employees who quit the company will be joining in companies with similar domain. And the ex-company and the new company could be competitors. If you're holding patents and the based on the nature of the company's operating principle, most of the companies won't allow ex-employees to work with them even if the ex-employee wants to.
  • In your specific case, I suspect how a 4 months stint can make you very critical to the organization and project unless until you're giving them radically something new born in your heads.
  • +1 for addressing the legal risk of the company exposing code to ex-employees no longer under contract. I never thought about how support could hurt a company until now
    – James
    Aug 24, 2012 at 13:28

all the things the others said and then:

Consider co-programming.
Sit with two people behind one desk. Program everything in pairs. when one of them (you) leaves, the other one stil has all the knowledge.

There are plenty of other advantages, but that's another topic.

  • I really like this Answer! I would add a link to make it look pretty.
    – Malachi
    Jan 30, 2013 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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