Copy & Pasta

Tae Kim · 8/13/2020 · 4 Minute Read

Pasta

The aim of this article is to encourage you to copy and pasta more! I truly believe that by doing so makes others feel confident, intelligent, and effective when working within your code. This article will guide you through my thoughts on why you should copy and pasta code!

(copy and pasta == copy and paste)

But... D.R.Y. ☔️

You might be thinking… wait… this guy wants me to copy and pasta code? But that's wrong! We should focus on the D.R.Y. (do not repeat yourself) principle. Duplicate code is a maintenance burden! This can't be right!

Woooo… saaaahhhh….

Image of Wooosaaaah

We've been trained to DESTROY duplicate code. Get rid of that shit! When we see two of the same lines in a Pull Request, your brain starts to tingle. We are trained to identify duplicate code and consolidate it in what's called an "abstraction". We're praised when we do this and looked down upon when we miss it.

Fuck that.

I'm here to tell you that copy and pasta'n code isn't bad. It has concrete benefits for you and the next developer to deal with your code.

Easy to Create ✏️

It's common to get a request to build Y that is similar to X. The code is already written for X, they just want to tweak this and that and use this data instead. Typical feature request.

So what could you do? You could take the time to understand X's code, integrate your "special tweaks" into X, extract it into an abstraction, use your new abstraction in X and Y, and hope you don't break X while doing this. Gosh… this seems like a lot of work and we could break something that's already working.

Well, what if we copy and pasta'd X's code instead?

We still need to understand X's code, I think that would be a good thing. But we don't need to integrate our "special tweaks" into X anymore, we can just modify the code to handle our feature. No more special cases, just the case we care about. And the best part, we also have no chance of breaking X. We're dealing with entirely separate code now, leaving X alone. This feels a lot easier and safer than creating an abstraction.

Easy to Understand 🤯

Now that we've done the copy and pasta, let's think about the next developer to have to deal with the code and how easy it is for them to get a grasp on what it's doing. Because we duplicated the code and modified it to handle our exact use case, there is no branching logic or additional parameters that are required when dealing with "special cases". This makes the code less complex and much easier to understand! That's a win in my book.

Image of winning

Easy to Modify 🛠

OK great, the developer can understand our code… but can they change it? Uhhh… yes! And they can change it without worrying! What would they worry about? Affecting other parts of the codebase.

Because we copy and pasta'd the code, X and Y have no shared dependencies. This means that when we make a change in X, it won’t affect Y. This is a great benefit because we don't have to worry about breaking others parts of the application. It's easier to focus on a single, small problem than juggling two or three or more at the same time.

Image of juggling

Easy to Remove 🔪

Removing code tends to be something that we as developers don't think about too often. We don't want our code to be removed, it should be built to last FOREVER! Ahh… if only we were that good.

But if we think about it technology evolves, requirements change, issues arise, and priorities shift. We may have built something awesome for the now, but in the future it could very likely become obsolete. When it does, how easy is it for your code to get removed? Will it take days for a developer to untangle it away? Or can they simply… highlight and delete?

Removing code is never that easy, but copy and pasta'n code instead of creating abstractions makes it that much easier. The duplicated code has less dependencies and is related to a single use case. If that use case becomes obsolete, they can target and remove that code independently of the rest of the codebase. No untangling required!

Image of delete

Final Thoughts 💭

I hope that this article has inspired you to copy and pasta more. It provides a ton of benefits for you and the next developer that works in the code. I really, really like that by copy and pasta'n code, we create less dependencies. This is the key to not creating spaghetti code!

Even though I bashed on abstractions in this article, they are not always bad. This isn't a "black and white" kind of thing and I'm not saying that you must ALWAYS copy and pasta code. I do think that you should try to copy and pasta first and over time create abstractions as you notice REAL patterns. The next developer will appreciate it :)

Thanks for reading!

Written by

Tae Kim

Tae is a Senior Software Engineer with over 7 years of development experience. He loves cranking on frontend code and talking about crazy ideas with his peers.

© 2020 Tae Kim Tech, LLC

All Rights Reserved.