I know the company you work for owns the code and obviously you will get arrested if you try to sell it. But is it uncommon for developers to keep a personal copy of the code they wrote (for future reference)?

Apparently this guy was sent to prison for copying source code.

  • 13
    it might be a serious legal issue if you somehow sell/re-use it to the competitor company. – Yusubov Jun 25 '12 at 16:45
  • 19
    Note that in the linked article, it's a rather specific case as he walked away with code that was most probably covered by NDAs (considering the client), and even if it weren't, I'm not sure I'd take the chance of walking away with code that was developed for the freaking Federal Reserve Bank! You must not have it all there if you think nothing can go wrong with that and that there won't at least be a few influential people who wouldn't like this idea at all if they ever heard you've taken the code with you. – haylem Jun 25 '12 at 18:27
  • 10
    Assuming that it was work for hire, and that your former employer therefore owns the copyright on the code you wrote for them and has not released it as open source, I'd say that keeping copies of code you wrote is exactly as inappropriate as keeping copies of code your co-workers wrote. – Keith Thompson Jun 25 '12 at 19:18
  • 37
    @DavidPeterman - why wouldn't an employer who hired you own every bit of what you do for them? Do you think part of your house belongs to the carpenter who did the framing? – Reactgular Jun 25 '12 at 23:38
  • 10
    @MathewFoscarini I understand what you're saying, but I'm talking about the algorithms. That would be like saying the carpenter doesn't own the steps he takes to build the house – David Peterman Jun 26 '12 at 3:18

20 Answers 20


But is it uncommon for developers to keep a personal copy of the code they wrote (for future reference)?

I don't know how common it is, but common or not, it's still a bad idea.

Programmers often operate in the mindset that solving the same problem twice is a waste of time. We try to design our code to be reusable (sometimes). We build libraries of classes and functions to reuse at some point in the future. We sometimes even give our code away so that nobody else will ever have to write code to solve the same problem that we just did. So it may be understandable to want to take "your" code with you when you move from one job to another. But you still shouldn't do it, for the following reasons:

  1. It's not your code to take.

  2. The code you wrote for your former employer is part of the business they built. Their code is part of their competitive advantage. Sure, competitors could write their own code to solve the same problem, but they shouldn't get the advantage of building on work that your employer paid for, owns, and didn't authorize you to take.

  3. If they have any sense at all, your new employer doesn't want any part of the code that you took from your former employer. The more you "refer" to work you did for some previous employer, the more you put your new employer in legal jeopardy.

  4. If you ever accidentally let it slip at New Employer that you've still got a copy of the stuff you did for Old Employer, your boss at New will probably realize that you'll take a copy of their code when you leave for some other job. That might not sit well with him or her.

  5. Even if you're not cribbing actual lines or just vague ideas from your old stuff, just having your old stuff in your possession could raise suspicions that you might be using it for something. Imagine that Old Employer sues New Employer, and as one of a small handful of employees that moved from Old to New, you suddenly find yourself giving a deposition. None of you actually copied Old's code into New's product, but the lawyer in front of you asks: "Mr. SuperFoo, do you now or have you at any time since leaving Old Employer had in your possession a copy of any code that you or anyone else wrote while working at Old Employer?"

  6. You don't need the code that you wrote last month, last year, or longer ago. You solved the problem once, and now you know how to solve the problem again. Or, you may know how not to solve the problem -- your new implementation will be better because you have experience.

  7. There are better ways. It's hard to go back and learn anything useful by reading old code out of context. A diary or journal that describes what you learn, ideas that you have, etc. is far more useful later on.

  8. Even if Old Employer knows that you've got their code and is OK with that, you still don't want it! The only thing that can come of having it is a 3am phone call: "Hey there, SuperFoo? How are you doing? Listen, you've got a copy of our stuff, right? Look, we've got a problem with the system, and we've narrowed it down to a couple files that you wrote that our new guy just doesn't understand. I know it's late, but could you walk him through SuperDuper.pl?"

Let it go. You don't need it.

  • 7
    Moreover, if the media you keep the content on gets lost or stolen, it's a whole lot of trouble. To tell the truth, I prefer to avoid having any kind of VPN connectivity or sources on my personal PCs if at all possible. Your PC might be a part of the botnet without you even knowing, why risk it? – Coder Jun 25 '12 at 17:40
  • 8
    Excellent answer! I was actually offered a copy of the code (or continued access) when leaving my old employer. I refused, exactly for reasons close to number 8. After all, there was a reason for resigning from them. If I still wanted to fork for them, I'd stay :) – harald Jun 25 '12 at 17:42
  • 79
    +1: You don't need it The hard part is figuring out what to write, not actually writing it. If you write it a second time, it will probably be even better. – kevin cline Jun 25 '12 at 18:31
  • 6
    When I solve a problem with my code I tend to write out the solution to a blog. Not source code from my work, but generic code that follows the same pattern (simple one line or a few lines to accomplish the goal-- not behemoths of code). I find this to be a great method for storing what I learned at previous jobs. +1 for bullet #7! – Gaʀʀʏ Jun 25 '12 at 19:28
  • 11
    Shouldn't there be a threshold of some kind for the amount of code that qualifies? If I use for (int i=0; i < N; ++i) in my code, it surely is not illegal to use it elsewhere at another company... – vsz Jun 25 '12 at 22:08

I always keep a copy of the code I write and take it between jobs. Subsequent employers never get to see/run the code, but I use it as a reference at home: 'Ah yes, didn't I do something similar to that on Project X?'.

Is this legal? Depends on jurisdiction and circumstances, but it is fairly common. Morally, I have no problem with it, providing you aren't simply giving code to new employers... It's a reminder and a demonstration of what you have done, rather than a free resource for your employer.

[The flip side of this is the inevitable shame that comes along when you look at older code: 'What was I thinking?? Why on earth did I do it that way??']

  • 35
    +1 And it's not even relevant whether it's legal. Many of us do it anyway. It doesn't harm your previous employer (you're not selling the code to a competitor), and it can't be regulated anyway. In a way, if you "remember" how you solved a problem for a previous employer, you are "stealing" this secret for them -- in a way which cannot be regulated until they invent mind-control ;) – Andres F. Jun 25 '12 at 17:13
  • 89
    @AndresF. That's nothing but a rationalization. The code is your old employer's property, your memories are not. If you remember how you solved a problem you don't need the code, so what's the point in taking it? – Caleb Jun 25 '12 at 17:32
  • 10
    +1 for making the moral argument. Personally I follow this, mostly because the majority of my code is not domain specific. I remember how I solved something, but not necessarily the nuances of it. – Telastyn Jun 25 '12 at 18:13
  • 46
    In the case of a company accusation of IP theft, having a copy of the code is going to act as a big aggravating factor against you. Having the memory of it is not. That's the difference. – Oleksi Jun 25 '12 at 18:15
  • 13
    @Caleb Regardless, many developers do take chunks of code after they leave. This is an entirely separate action from using this code to compete against or hurt your old employer, and is usually taken just as reference, as in "how the hell did I solve this problem/configure this piece of software before? Rail against it all you want, but it's still a widespread practice, and not actually hurting anyone. You can bury your collective heads in the sand, or claim it's wrong, but it still happens. Especially with outsourcing/offshoring -- if you think it doesn't happen, you're in for a surprise! – Andres F. Jun 25 '12 at 20:15

This is a very bad idea. That code doesn't belong to you (legally speaking) and having possession of it can get you into a lot of trouble. This becomes even more true when you move to a new job and still keep that source code around. Even worse if it's a competitor. Your company would not be happy if you had access to their source code when you don't work for them anymore.

It's all about managing your risk. It's obviously expected that you retain things from a previous employer that you can use somewhere else. This is why they make your sign non-compete clauses that last X months/years after you leave them, however having possession of the code makes you more vulnerable to someone accusing you of blatantly copying the company's code (even if you didn't, and just used the same ideas). Is having the code worth managing this risk?

Surely the useful stuff you got from writing the code is not the exact syntax; it's the knowledge you gained. It's probably not worth dealing with all this legal stuff.

  • 9
    It's not a bad idea, unless there are strict security checks at your office (like disallowing email and pendrives). Nobody is going to search through your home computer anyway, and it's understood that developers take knowledge away from their past jobs. You cannot prevent that, and it would be unreasonable to do so, whether the code is "remembered" or copied verbatim. What you can do as an employer is enforce no compete clauses or NDAs or whatever legal mechanism is available in your country. – Andres F. Jun 25 '12 at 17:17
  • 14
    @Malfist No, you don't. IANAL, but it's pretty well established that, in the US at least, the work products that someone pays you to create are their property, not yours. See work for hire in Wikipedia. – Caleb Jun 25 '12 at 17:43
  • 5
    @Malfist Again, no. See the link in my previous comment. – Caleb Jun 25 '12 at 17:45
  • 4
    @Malfist: "if you're the sole developer, and they didn't make you give up your copyright, you can take the code with you when you leave (I always do)". Not sure your contracts reflect the majority of the reality though. Most contracts for software hire will explicitly say that you need to deliver all source and binaries, and pass ownership and copyright over to them. Which is pretty normal for freelancing. You can negotiate that, but it's pretty much de-facto clauses that I expect to see in contracts (both for internal or freelancing contracts). – haylem Jun 25 '12 at 18:19
  • 5
    Let's hypotetically consider a developer who remember any single line he wrote during his career. Would it be illegal if he used this memory while working on future projects? Why are you making distinctions between remembering your code and saving a copy of it in your private hd? If you're allowed to take example from your experience you should be even if it's written in your notebook instead of being stored in your brain. And if you're not allowed to re-read your old code, that you saved in your PC, then you shouldn't be either allowed to "remind" it, which obviously doesn't make sense. – Nadir Sampaoli Jun 26 '12 at 7:21

It's not uncommon.

I have a copy of almost1 every piece of code I've written professionally, and certainly all the code from my current projects, regardless of who wrote it2. Along with the code I have a huge pile of legal paperwork clearly defining what I can and cannot do with it. Just having the code is not the same as trying to profit from the code.

That said, it's a legal issue, and legal issues tend to be extremely complicated and localized. If in doubt, you really need to talk to a lawyer. I may keep my code around, but I'm 99% certain I won't get in trouble for doing so.

1 What's missing is mostly what I didn't care to archive. Only one small project's code is missing because of legal reasons.
2 Nature of the projects and my role in them, I'm one of the guys that need to have at least an idea of what goes where, even if I wasn't involved in building a specific module.

  • 4
    @haylem I'm never in the company's premises ;) – yannis Jun 25 '12 at 16:49
  • 3
    yet I'm sure you know what I meant, and that it probably doesn't matter much where you physically are :) – haylem Jun 25 '12 at 16:52
  • 3
    I heard one developer speak at a WordPress conference and he said something like "If I do contract work for you I make sure you know that you own the code I write for you, but that doesn't mean that I haven't learned anything new by writing your code." – programmer Jun 25 '12 at 16:56
  • 3
    @Caleb Having the proper documentation may be uncommon (I don't know), however I don't think keeping copies of the code is. I just happen to have both ;) – yannis Jun 25 '12 at 17:41
  • 2
    @Krelp, encryption keys, like keys to safes can be compelled via a subpoena. – Malfist Jun 25 '12 at 17:43

I see your arrested Chinese man and raise you with a "code is not property, therefore cannot be stolen".

Ref.: Code 'not physical property', court rules in Goldman Sachs espionage case

With that said.

  • Do I keep code I write? Absolutely.
  • Do I keep full projects? Absolutely.
  • Do I make sure I thumb drive my code from my work PC onto a home machine? You betcha!
  • Do I ever re-use that code at another company or in a personal project. Nope.
  • Do I often look at old code and go WtF!? All the time.
  • 14
    +1 Hehe, a nice, honest answer. The best part is that it's true you actually never go back to old code. You just feel safer if you take it with you, never to look at it again in your life! – Andres F. Jun 26 '12 at 3:07
  • Wasn't this a major issue in the recent Oracle v Google case too? – robertc Jun 29 '12 at 13:05
  • 1
    Totally agree with you. I'm doing the same. It's a very good reference. – Andrea Girardi Jul 3 '12 at 8:11
  • 2
    code is not property, therefore cannot be stolen is a terrible summary of that Goldman Sachs case. The Russian guy was acquitted, not because he didn't do anything wrong, but because his theft didn't qualify under the law the prosecutor was trying to use against him. That didn't mean he didn't violate his contract with GS, or violate IP laws. Please read the article more carefully, and maybe take in some of the comments below. – Nate Feb 16 '13 at 3:31
  • Related article: Did Goldman Sachs Overstep in Criminally Charging Its Ex-Programmer?. This is also a good example that even if you win in the end, the legal battle itself can hurt a lot. – CodesInChaos Jun 7 '14 at 16:41

Here's a simple question for you. Go to your boss and tell them: "I have a copy of all code I wrote while I worked here. Only code I wrote, not other peoples. This is for my own education, and I will never give it out".

Their next actions will dictate (yes, that word does exist in North America/World) if you are in the wrong or right in their eyes.

Regardless of your own "ethics", you work for an employer. If they deem that what you are doing is wrong, then it is wrong based on their ethics. As they pay you, and you are employed by them, then it is in your court to either agree with them, or disagree, which could get you fired.

Now it's a question of integrity. I've let a previous employee's take some of our code, but I have vetted all of it first.

Just because you believe you are in the right, does not make you in the right. Usually software developers sign contracts when they are employed. If you signed one, you need to live by your word.

  • "while I worked here" implies the person in question is no longer your boss. If it's your former boss, why would you care to ask him? – Alexander Jun 30 '12 at 19:53
  • Why? Contracts? Integrity? – Ryan Ternier Jul 3 '12 at 15:42
  • You can keep code you wrote while not using it for anything and still both uphold your contracts and keep your integrity. – Alexander Jul 4 '12 at 8:27
  • 2
    If you sign a contract that states all code is the property of your employer, you taking it home is a violation of that contract if they do not know that you have it, or gave you permission to have it. It's effectively theft. Yes it's "code", digital 0's and 1's, but in most cases it's black and white. – Ryan Ternier Jul 5 '12 at 16:39
  • It's the classical "piracy is theft" discussion. – Alexander Jul 6 '12 at 6:18

is it uncommon for developers to keep a personal copy of the code they wrote

Answering the question directly, I'll say in my experiences this is uncommon. The exception to this that I have seen is people who do a lot of freelancing and they keep the code on hand for their client's future maintenance and enhancement projects, and I would imagine that this is clearly stated in the contract (though I am not in the habit of reviewing my friends' freelancing contracts, so who knows). People I know who work in larger companies have never admitted to keeping code from former employers.

I know I wouldn't because I can't think of a single situation where it would be useful (not to mention that I'm pretty sure my current employer prohibits such things - I would just have to look up the documents to be certain). The code I've written/fixed is usually so specific to a particular business requirement that I can't imagine it ever coming up again in the future in such a way that it would be easier to re-use the old code than write new code.

  • 3
    As a freelancer, I'll keep all code around. Reusing it is extremely unlikely, but to eventually mantain, I'll keep it (for example if the employer hires somebody else that screws up the code and hires me again to fix it). – Camilo Martin Jun 25 '12 at 23:48
  • 1
    In my freelancing I find there's a lot of code that is commonly reused. How many times do I end up writing the same user login code before I just reuse it. While I keep code around for maintenance, the common areas of code are typically copied. If I've found some code that is essentially the same between two projects, I make a copy of it in a generalized form and I'll copy it into other projects as needed. – Chris Jun 27 '12 at 15:13

Back in the day it was common for developers to have their personal library of routines that they would use to solve problems at the current job. The source would stay behind when the developer left, but any enhancements also went with him.

This resulted in a win-win situation. It was also just a subset of all the code written.

Of course most of what was in personal libraries would be in standard libraries today.

  • In some environments, there is a clear delineation between Library or Component code, or Classes explicitly designed for reuse (parsers, etc) and those which are Problem Domain specific. The code which is problem domain specific (XWare's major inhouse app or commercial entity) might not be useful outside that place, but the low level or reusable component/libraries may indeed be very useful indeed. – Warren P Jun 28 '12 at 22:31

Under an employer to employee relationship in most parts of North America it is illegal to transfer or transmit digital material (i.e. source code) from your employers equipment without prior legal authorization from the employer.

Part of the legal laws relating to the definition of an employee in the work place, is the description that the employee does not provide his/her own working equipment unless otherwise stated in the employee contract, with exception to trades which require the employee to purchase their own equipment (i.e. construction worker).

Most employment laws in North America define the employer as the principal risk taker in an employee to employer relationship. The employee is paid for his/her time while the employer provides materials, equipment and controls the work related activities of the employee.

At what time during this relationship does it make it OK to steal valuable material from the employer, who has paid for and taken risk in having said material created?

The key problem with this was the question "source code that you wrote?". No sir, it is not you who wrote it. Under guidance of your employer it is them who wrote it. You are just the hired hand who typed it out. There is no court in North America that will side with you should your employer take legal actions to secure their property. Just copying the source code to a USB thumb drive can get you into hot water.

With that said, if an employer allowed you to use your own equipment (i.e. laptop) or transmit the material, then it's a different matter. The employer must notify you upon termination that any materials should be returned/destroyed.

Just thought I would post this answer, because it seems like some people thought this was a gray area. I really don't think if you're a developer, that you should be going around the Internet posting that you keep copies of employer's materials. I mean, you clearly already knew the answer to this question because you created a new member account just to ask this question. ;)

  • The employer must notify you upon termination that any materials should be returned/destroyed. Is this really true ? Is the employer under legal and/or contractual obligation to do this ? – Radu Murzea Jun 26 '12 at 14:08
  • The employer is not under legal obligations to do this, but he can request at anytime that any materials belonging to them be returned from an employee, unless an agreement between the employer and employee exists that allows the employee to keep said material. – Reactgular Jun 26 '12 at 14:47

I've done this in the past a few jobs ago.

However I've never once gone back and looked at it. I've occasionally reused ideas and things I learned but I've not once found a reason to go back and look at the code.

So I wouldn't bother any more. It's legally dubious, and I've never actually found it useful in practice.


Sure. I like to keep a copy of all the work I do - whether it's writing code or otherwise. Call it a scrapbook, if you like. Breaking the rules? Perhaps.

The comments about competitive advantage are irrelevant unless your next employer is a direct competitor. If you move from a phone company to a software house, or from a game developer to a database developer, it doesn't matter. If you're actually planning to reuse code - well, that's a different story.

Interestingly, you often hear about web developers bringing a "box of tools" with them, with a standard set of JavaScript libraries and CSS stylesheets. But I haven't seen that mentioned here.


I have just recently deleted all the old code I kept from my previous employer. I only kept pieces of code that I thought were good for future reference. I've actually found that I've moved on considerably since I left and I've never referred to the old code. I've found/discovered/learnt far better ways of solving the same problems.

It was a nice little trip down memory lane though :)


I think there needs to be a distinction between a design-pattern and actual code (copying line-by-line)

Writing down some psuedocode something like - this is a great way to lazy load X in Y is one thing. Writing down all the code is something else.


With your employer's permission publish the neat re-usable code as open source projects for other people to use. Then your employer can also benefit from contributions by other people to this code.

This way you can keep the code legally, build a public portfolio of code you've written and the code can benefit other people.


For a different number of reasons, like working from home, you might as well already have a copy, and I for one wouldn't go deleting these after a job, why do that? It doesn't go against my beliefs or something.

But, regarding using it, it is not so useful as a blog post!

Bottom line: write your code, blog about the problems you've faced and how you solved them (especially when it's generic and broad stuff), and don't mind to keep a (possibly encrypted) souvenir from the last job.


In finance the CFA addresses this issue. You are not allowed to take information related to clients or your work for the company (in this case code). But nothing prevents you from memorizing what you can and then writing it down later.

Not sure how legitimate that is, but I think your best bet is to leave your source code but write down your ideas and how you did it as soon as you get home. Stealing is stealing and in court all they are trying to find out to decide is if you copied the code or not.

  • Keep in mind some employers will make their damn best to stop you from "writing down your ideas" when you get home. The lose scenario for them is not copied code, but competition against them -- and for that, ideas are far better. Not sure if it's enforceable, but some try bullying you into thinking they own any ideas you may have during work hours. – Andres F. Jun 26 '12 at 3:10
  • 1
    @AndresF. I once worked at a hedge fund that tried to prevent this. They honestly could not prevent it so they made people sign non-compete contracts and paid for them not to work for 1-2 years after they resign. Although extremely expensive(you are paying 2 years salary to someone who doesn't work for you), it makes your knowledge stale when you leave and useless as competitive threat. – Lostsoul Jun 26 '12 at 3:34
  • +1 for ideas only and not the code. Was involved with a company who sued an ex-programmer for stealing code and selling a similar product. The judge ruled that because the bugs were identical he must have stolen the code. – jqa Jun 26 '12 at 14:27
  • I've seen many employers require a new employee to agree in writing that they will not engage in other business activities while employed by the employer, and any other projects the employee does on the side are also property of the employer. I think this subject in it self is a whole other issue, but these agreements are there in most employment contracts. – Reactgular Jun 26 '12 at 15:00
  • @MathewFoscarini I agree. At my firm we require employees to have written approval before engaging in anything that they receive a benefit from(includes side projects, charity work,etc..). If you fix your neighbors car and he buys you a beer, it would quality although employees realize we most likely wouldn't pursue it. – Lostsoul Jun 26 '12 at 16:36

If you are saving your code with the goal of reusing it later, I have two issues with that:

  • If the code is domain specific, it is probably also proprietary. Anyway, no two businesses or problems are exactly alike and trying to fix one problem with the solution for another is not a good pattern.

  • If the code you are saving solves a common problem, you should question your approach. Why are you spending a lot of effort to solve a common problem when they are likely existing (and better) open source solutions?

    If you believe that you have the best solution to a common problem, you should really try to share you code publicly on a public repository and/or code blog when you write it, not keep it to yourself. Your boss should not object to sharing a generic library or force you to reinvent the wheel (if he does, find a new job).

If you are saving your code because you want to show it to a potential employer or to improve your skills, I suggest you contribute to an open source project instead.

  • 1
    The second item assumes that there would be an open source solution, which is far from certain. But most importantly, some of the code I've retained is code that demonstrates how I've used 3rd party components/services. For example, if I develop a decent payment solution that integrates with Paypal, I'll take the code to refer to later - so I don't need to re-invent the wheel next time. – cjmUK Jun 26 '12 at 12:36

I haven't yet kept any code that I've done for employers. Freelance stuff I've kept (it can be hard to support a client if I lose my code).

However, I'm considering keeping the code that I have made for this employer. The reason is that I'm a web developer, and I've developed a lot of client-side things that look rather pretty. I didn't design them, but I implemented them and often came up with the idea. I would like to keep a copy of this stuff to build an online portfolio. As we all know, sites don't last forever, so I can't realistically count on my work staying online. Having a backup copy would allow me to have a portfolio online.

I know that designers often keep copies of their work (even if it was work for hire) for portfolio purposes.

I'm not sure what the legality of this is (it is not explicitly mentioned in my contract).

  • 4
    but what are your thoughts on this? Please don't openly invite a conversation on your answer by introducing another question. You tell us if we should keep a copy of all the code we write. You can improve the answer by editing it. – maple_shaft Jun 26 '12 at 11:07
  • 1
    I think there is a difference in keeping the original source files (in your case graphics files like .ai or .psd) vs having a screenshot of the final product for your portfolio. You should still ask your employer for permission, but they should be more agreeable to the latter. – Sarel Botha Jun 26 '12 at 18:01
  • Because the work is often interactive in nature, a screenshot is not going to cut it for a portfolio. That would only show the design (which mostly is not mine). I could take a screencast of me using the work in question, but that still doesn't convey things like latency, performance, cross-browser compatibility. – Xandor Schiefer Jun 26 '12 at 18:55

Well, for developing the business logic for my company, I can't keep the code because it's illegal & personal property of the company. As the developer, I know how to develop that logic, so I can keep that logic in my mind. Basically by default it is stored in your mind, and if you need it next time, then automatically you should implement the logic/better logic than the previous one. It's the human nature & intelligence. :)

But the issue creates when you develops some utility logic, they are re-usable & always important, you may need it frequently in different projects. So you should want to keep it with you.

I have an alternate solution to that. Just create a without source/documentation JAR for thos utilitiess and add it as an external third-party JAR in your project. Probably by doing this you can confirm your responsibility as well as your self satisfaction that you have the code ;)

  • 1
    The other approach for this is that when I encounter a useful/reusable bit of code that I'd like to "take with me" ... I simply go home, and write a blog post about the particular API or technique that has interested me. This blog post of course does not reference my employer, nor does it use, line by line, the code written on my employer's dime. – Joel Martinez Jun 28 '12 at 21:41
  • If there are rules, then their must be an anti-rule. Which you can use in favor of you. Their are different techniques to achieve this. Most important thing is- keep the job clear. – Soumyadip Das Jun 29 '12 at 8:00

I don't keep code for a simple reason: The company paid me to write the code for them. I give them my code, and they give me my paycheck. The guy who made my lunch, does not get to keep part of it for themselves, why would code be different?

Also, the point made before, I walk out of job, all those headaches stay there, new job, new start, but with a bit more experience and understanding of the types of problems in that old job's domain.

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