<IANAL and this is all US specific>
Over all, I’d say don’t get bent out of shape about leaving code behind. If your code comes and goes with you, it’s probably a net loss for the employer: finding and removing all the depenencies and whatnot is a big hassle and introduces errors. For that matter dealing with code that nobody in the building wrote or maintains is also big pain in the ass. If yoi’re really trying to be helpful, integrate code into the studio infrastructure in a sustainable way. If you’re just doing it for your own convenience, make sure it’s not a violation of company property and keep it completely private, the same way an end user might keep their own shelves or buttons.
In the US, at least, you also need to be careful of your rights and responsibilities. Your employer owns everything you do for their project on site – and if it’s project-related they may own it even if you did it at home or offsite, depending on how your contract reads and where you are. They certainly own anything you make on their time - depending on the nature of your relationship with them, ‘their project’ may include stuff you think of as ‘on your own’. I’m not defending the law here but that’s how it often works – and even if when it doesn’t the prospect of having to go to court over it is daunting.
On their side they have issues to conisder too. If you bring in something on your own that somehow messes up their legalities or their project, they have a right to be pissed. For example, if you bring in a GPL’d tool without explicit permission from their legal people it’s bad news (I once watched 80 artists stand around idle while lawyers audited ther machines - no joke! - because somebody brought in a GPL tool which could theoretically have made the entire toolchain for a big, expensive AAA project open source.
if you have personal tools you want to bring in:
a) copyright your own stuff (it just takes sticking a notice into the code files)
b) ask about their policy and make sure you’re comfortable with it - they might try stuff like asserting ownership over your code if you change a few lines in the office.
c) make sure they are ok with you bringing in outside stuff for all the reasons above
One nice alternative is to keep all your code open-source with a non-annoying license (BSD or MIT) and get sign-off from your employers before using, This keeps the ‘ownership’ of the code very clear but doesn’t get in the way of use. If they say OK, you still own the code - and if they don’t, just write them a new one on their dime.
In general I take a pretty relaxed approach to this stuff in my own work - if I’m getting better as I go along, my code will probably be redone every few years anyway. Very little of what we provide is magical technology - most of it is good instincts, problem solving skills, and being there when things go wrong.
</IANAL>
Also: great discussion here