A good developer knows two secrets of the trade – how to invent new things, and how not to reinvent the wheel. But when is copying code the smart and appropriate thing to do, and as importantly, when does building something entirely by ourselves qualify as a case of reinventing the wheel? The answer isn’t always as obvious as we’d like.
In this article we will look at four hypothetical scenarios, and for each of them we will consider two questions: whether copying is ethical in that situation, and also whether it is an efficient solution (the two are not always the same). Hopefully, by the end, you will have a good sense of where the line falls between reference and plagiarism.
Let’s begin!
Scenario #1: “When working on my side projects, I sometimes just copy and paste blocks of my past code, in order to solve a problem that repeats itself.”
Is this ethical? Yes, obviously. This is an example of copying from yourself, and as long as you don’t recycle anything you’ve used in someone else’s proprietary project, there is absolutely nothing wrong with it.
Is this efficient? This is a very common practice among people who are still learning how to code, but by the time you’ve reached a certain stage of maturity as at developer, you really should not be doing it anymore. It may be ethically acceptable, but it’s also a clumsy, rudimentary approach which will ultimately waste much more time than it saves. If you find yourself reusing the same block of code multiple times, then it’s either something so basic that you should turn it into boilerplate code (code that is designed to be reused multiple times, usually employed as the foundation of new projects), or else it’s something that you can turn into a function, or even a library, which can then be recalled whenever you need it. Even allowing for the time it takes to create said function/library, this way is neater, more elegant, and faster in every way.
Scenario #2: “There was something I didn’t know how to do, so I Googled it and copied the code I found from a blog that answered my question.”
Is this ethical? If you Googled for a solution and found a blog specifically dedicated to how to solve your problem (something like, for example, this one), it’s a safe bet that the blog was written for other people to copy from. The internet is full of articles and websites for developers that go into great detail on how to do specific things with specific languages, and while they rarely offer more than short snippets, there is no harm done in taking advantage of them. If you really want to show your gratitude, you may want to like, comment on or share the article in question – it’s what most content writers are looking for.
Is this efficient? Yes, but only under a strict and non-negotiable condition: that you understand how the code works before you copy it. Taking solutions from someone who offers them freely may not be wrong, but interpolating code you do not comprehend into your project is a surefire recipe for disaster. In fact, ‘copying’ in this sort of situation doesn’t really refer to ‘copy and paste’ (unless the snippet really is just a tiny snippet). It normally means copying the solution in the abstract, and then rewriting it in your own style, or even better, the style of your team (if they are already committed to an ES6 syntax and the example is in ES5, then it’s on you to rewrite it). This is how you can make sure that the code is something you can work with again in the future, and not just a patch for the circumstance.
Scenario #3: “My colleague and I are both working on the same project, and I copied something she did to solve an issue on my side.”
Is this ethical? This is probably the hardest one to answer. In principle, if you and your colleague are working on the same project, then whatever they did was done on company time, and the responsible and professional thing to do is to not waste company time by rebuilding something that is already there. So if copying helps you, it should help your colleague too. Having said that, the internal dynamics and etiquette of different teams can vary wildly from one company to another, and not all developers are team players. Some may see your imitation as an injury to their pride, or as an unfair attempt at getting a head with management. So if you mean to recycle something one of your colleagues did, it’s a good idea to discuss it with them first. If they’re smart, they’ll let you take what you need, or they will explain the good reason why you shouldn’t copy their solution. If they’re not smart, then respect their wishes and find solutions of your own, or else talk to management and bring up the issue of teamwork.
Is this efficient? The same advice from the previous scenario applies here. Only ever copy code that you understand, and understand well. Anything else, either study it first until you understand it, or else do not touch it with a barge pole.
Scenario #4: “I’m working on a difficult project for my company, and it has to be finished this week. I happened on a piece of code that was open source software, and so I used it in my project to expedite my work.”
Is this ethical? Absolutely not. Under no circumstances should you see it as acceptable to take open source code and paste it into your project. Open source software is available to the public, but this doesn’t mean that it’s not licensed – and failure to comply with a licence could easily lose you your job, and, in the event of a lawsuit, bankrupt your company too. The conditions attached to licences can be variable, ranging from simple accreditation by anyone using the code, all the way to making your own project open source too. But one thing is certain: if the project you’re working on is proprietary (meaning it is owned by a private entity, including yourself as a free agent), then you certainly won’t be allowed to use licensed code. The only exception to this is public domain code, that is to say, code on which its creators relinquished all copyright claims – that can be copied freely. Even then, it’s a good idea to make it clear where it came from.
Is this efficient? Assuming the prospect of jeopardizing your job and your entire company doesn’t scare you… the answer is still no. There are proper ways of taking advantage of open source work, and this involves not just complying with the law, but also using said work the way it was meant to be used. This usually means importing an open source library, not copying its contents. And doing things the right way is ultimately going to be beneficial for you too, as these libraries will be kept updated externally, which in turn will make them much easier to maintain.
Conclusion
Developers are notoriously susceptible to imposter syndrome, so it’s worth reminding them that using another person’s solution to solve a common problem is not only acceptable, but an ordinary practice that is part of the profession. The days of the developer as a mysterious keeper of secret knowledge are long gone – today, coding is about teamwork and collective progress as much as it is about the creative individual.
At the same time, coding has its own code of behaviour (no pun intended), which means you can’t just do (and take) anything you like. So consider the context, learn its rules, respect its laws, and give credit wherever credit is due. And you’ll be fine.