Well, it’s a tricky situation. The code of ethics says you are not supposed to deny your employer the fruits of your work for them. If you run as a consultant, you can have tiered levels of service, but if you are an employee, it’s murkier. Your memory is your own, but computer code is arguably a trade secret, and most contracts you sign will require you to honor that. The code of ethics requires you to honor your employment contract, provided it does not require anything illegal.
My general approach to this is to make some kind of modification to the the model that makes an employer’s model uniquely theirs. Then, if I need to reuse the main ideas, I can modify them again in minor ways so that neither employer has an exact copy of the original model nor an exact copy of each others’.
An employer will typically have a contract that assigns them the intellectual property you develop for them, and they will typically tell you to hand over the source code or be terminated, at which point you have to figure out if you have anywhere to walk to. This is one reason why my libraries are strongly segmented into parts that are data-gathering and munging, versus parts that are the main trading logic. This way, I separate the parts that are my employer’s intellectual property and competitive advantage, versus general data gathering and processing stuff, and therefore try to avoid things like “We are going sue you for robbery of trade secrets, because you used a for-loop to scan for bad data points, just like our code does.”
So far, it’s worked well, and I try to act in good faith by telling clients that I develop code that meets their requirements to the best of my abilities, and that almost always invovles making their code unique in some significant way.
The other thing you can do is document the key ideas of your code that show up in the public domain (such as in the Journal of Portfolio Management and such). This makes the code simply an implementation of prior art, and therefore weakens the “trade secret” defense. As long as your employer can’t argue that you’ve stolen their code verbatim, you can point to the components of prior art in the public domain and re-implement them.
Finally, you want to archive the stuff you develop so you can demonstrate that you developed them before your relationship with various employers, just in case.
None of this is watertight, and an employer with deep pockets that wants to make your life miserable can still do it, but generally, acting in good faith and customizing code to meet their needs as specifically as possible is a good way to ensure that the code that one employer recieves is meaningfully different from the code that others receive. At the end of the day, there aren’t all that many new ideas in asset management, and one’s view of how best to implement them evolves over time anyway. Often times, you’ll find that an employer doesn’t want to change their current implementation, but your ideas have evolved, so if you move to a new employer, that is sometimes the opportunity to implement improvements that your old company didn’t want to implement.