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.

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.

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.

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.

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.