How deep do you take your coding into a company?

January 27th, 2010

Every developer has personal code they use everyday, but what happens when you are hired?

How much of your "brains" do you take into a company? This post explains how to determine what code you can and cannot take into a company if you already wrote it prior to being hired.

But first, let's get this out of the way.

Disclaimer: I am not an attorney. I do not know enough about the legal system to give legal code advice. I don't even play one on TV. This post is meant for you to think about what personal and legal obligations you need to pursue to protect yourself. I would contact an attorney to discuss Intellectual Property (IP).

If you're a seasoned veteran coder or freelancer, you undoubtedly have a library of routines that you saved and use on a regular basis (and I'm sure it's absolutely phenomenal), but while you are coding at a client location, how much "new code" do you write for a company as opposed to using your own library?

The easy part is already done.

When you have a coding library in whatever language you use, this is your utility belt. You're ready to take on the world and you know your code is finely-tuned, thoroughly tested, and refactored beyond belief and ready for prime-time.

That was the easy part.

The hard part is weighing the options of when to use your library in a company.

Knowing when to use your library

As soon as you step foot into a company, any code you write is property of said company (I learned this lesson the hard way when I was younger).

If you are using simple routines or small methods that are a line or two, you can more than likely use that little routine over and over again.

The problem comes into play when you have a number of multiple routines you built that work together to form a whole component. Sure, as a standalone method, it still does the job, but it works better when working with other routines.

Your routines are cogs!

Let me give you an example.

Let's say you built a routine to send an email. One method, one function. That's it. The email routine is called from your application and it sends out an email. Simple, right? Anyone can build it.

The routine is tested, beat up, refactored, and even in production in a number of your custom systems. This is just one cog in your library.

Now, you build a template system around your email component. Then you add a scheduling routine that knows when to send these templates and a newsletter component. Don't forget the email tables to keep track of the subscribers. Next thing you know, you have a subscription system in place that evolved from a simple email routine.

Congratulations! You have a subscription system that any company would be willing to purchase from you. These are the types of services or libraries that a company would invest in instead of paying huge dollars to build one (the old Build vs. Buy).

Anyone can write an email routine, but it's what you do with that routine is where companies will look to save money. The coupling of your creativity and programming skill is what will drive your coding success. If your library is already battle-tested and honed to perfection, you're telling me a company wouldn't be interested in the software to build their own subscription service (described above) that will save them development costs?

I seriously think they would "buy" instead of "build."

Conclusion

Bottom line: Not many companies will care about a small routine that you pick off the Internet from a fellow coder/blogger and build into the current system. Heck, developers are already doing that same thing right now.

However, companies will care about an entire software package or routine you built that is currently driving their business forward.

My advice is to first talk to an attorney to find out what can and can't be done by both parties: you and the company.

Secondly, seriously talk to your boss about the code and discuss your options. Who knows? He may write you a check for the code/product within the week.

Share your thoughts on this. Do you take some personal code into an enterprise to speed up your development?