Ask HN: What do you think of reusing code you write between diferent jobs?
8 comments
I use the same movements to fill and reprime oil burners every day.
Why can't someone re-use the knowledge they have to write code that has the desired functionality?
Why can't someone re-use the knowledge they have to write code that has the desired functionality?
My solution is to have side-projects that are open source, which I reuse across multiple jobs. Wherever possible, I get permission to "contribute patches to Open Source projects" included in my contracts, and thus grow the body of reusable code over time.
It usually takes some nights and weekends to get the initial body of open source code written, but since it is usually more-or-less a clone of something I've previous written and want to use again, it is fairly mindless effort.
If you're in a position where you retain the IP for what you write, (I assume you're permitted to use open source?) you could just do whatever tidyup is needed, and push it to GitHub, ready for reuse?
It usually takes some nights and weekends to get the initial body of open source code written, but since it is usually more-or-less a clone of something I've previous written and want to use again, it is fairly mindless effort.
If you're in a position where you retain the IP for what you write, (I assume you're permitted to use open source?) you could just do whatever tidyup is needed, and push it to GitHub, ready for reuse?
This is a good idea, I should definitely consider this. I do enjoy having the full "exclusive" licensing rights to my code, but in many situations in the future this probably won't be possible, especially when working in different domains.
There a difference between best practice architecture and copying code: No one will sue you if you implement things the same way in different projects, but if you copy & paste a large amount of code from one project to another it might be problematic.
An employee also owns the copyright to his/her code (at least in most European countries), the company often just gains the exclusive right to use that code through the contract with the employee (or the law, in some countries). So whether or not it is you intellectual property does not matter that much, what is important is what's actually written in your freelancer contract. If you build a custom software system for a company I'd assume they will not simply let you sell "your" exact code to their competitor afterwards, at least if it's something that has some inherent competitive value (e.g. not simply an off-the-shelf solution like a CRM or website). Most companies make sure this can't happen even when working with a freelancer, so have a close look at your contract (if you have one). If there's no explicit contract it'll depend on the country you're in.
An employee also owns the copyright to his/her code (at least in most European countries), the company often just gains the exclusive right to use that code through the contract with the employee (or the law, in some countries). So whether or not it is you intellectual property does not matter that much, what is important is what's actually written in your freelancer contract. If you build a custom software system for a company I'd assume they will not simply let you sell "your" exact code to their competitor afterwards, at least if it's something that has some inherent competitive value (e.g. not simply an off-the-shelf solution like a CRM or website). Most companies make sure this can't happen even when working with a freelancer, so have a close look at your contract (if you have one). If there's no explicit contract it'll depend on the country you're in.
I don't usually sign contracts, when I do it's mostly NDAs. Often times the code has inherent competitive value. When not under an NDA, I'm well within my legal rights to reuse all of my code at any time, I could put everything I write on GitHub tomorrow with a GPL license and there wouldn't be anything stopping me legally (I would never do this, of course). When under an NDA but not granting exclusive usage rights, I'm not sure how that plays out, but I haven't ran into that situation yet. I'm in a very, very niche position.
I do appreciate the word of advice, and will make sure to look out for it when I do need to sign contracts for long-term work.
I do appreciate the word of advice, and will make sure to look out for it when I do need to sign contracts for long-term work.
In the US, most code written by an employee is considered a “work made for hire”, and the IP devolves automatically upon the employer. This is also usually written as a clause in most freelance/consulting contracts.
I looked into this a while ago. If I'm recalling correctly, code in particular is treated legally akin to a literary work, so it wouldn't be "work made for hire" by default. I might not be recalling correctly.
A couple of things.
It's cheaper and lower risk to hire a contractor to provide a solution to a problem when the contractor has domain knowledge, tools and code to provide a solution. Forcing him to create a solution out of whole cloth is just dumb. More expensive and comes with a much higher risk of failure and slipped deadlines. There are a ton of customers that only care that a solution was provided and have no economic interest in the software itself.
Working with a codebase you're familiar with has a few advantages. You are using a worked out API which allows you to customize it without writting yet another broken wheel API from scratch. You know where bugs are, and you often avoid exposing existing but unknown bugs due to habit[1].
[1] I learned this a along time ago watching technicians use buggy software. Over time the number of crashes and bug reports declined not because the bugs were found and fixed but because the techs unconsciously learned how to use to software in ways that didn't expose bugs.
It's cheaper and lower risk to hire a contractor to provide a solution to a problem when the contractor has domain knowledge, tools and code to provide a solution. Forcing him to create a solution out of whole cloth is just dumb. More expensive and comes with a much higher risk of failure and slipped deadlines. There are a ton of customers that only care that a solution was provided and have no economic interest in the software itself.
Working with a codebase you're familiar with has a few advantages. You are using a worked out API which allows you to customize it without writting yet another broken wheel API from scratch. You know where bugs are, and you often avoid exposing existing but unknown bugs due to habit[1].
[1] I learned this a along time ago watching technicians use buggy software. Over time the number of crashes and bug reports declined not because the bugs were found and fixed but because the techs unconsciously learned how to use to software in ways that didn't expose bugs.
Code that's in production use is proven.
Conventional wisdom is that you can always improve your code, but sometimes it's already as good as it will get. I'll only rewrite code if I find I can improve it considerably. I always try to write the cleanest, best code possible, and I think I do a pretty good job at it.
Though I have been thinking that if someone competing with someone I'd already been paid to deliver code for, they could ask for (almost) the same exact features, possibly giving them a competitive advantage. I could obviously decline, but where to draw the line would be iffy.
For context, my situation is special in that I do contractual work, and all of my code remains my intellectual property, so it's all unquestionably legal. I do tell clients that I reuse my code often, though I don't go on a monologue about it. All code is written by me. This is more a question on "if you could, would you?".