Choose inspiration over imitation

This is a guest post from James Turnbull. Enjoy.

Dear new developer,

Steve Jobs made the phrase “Good artists copy, great artists steal” famous in the tech industry. However, there’s considerable debate about the origin of the expression. Ironically, he was possibly cribbing from Picasso, who might have been cribbing from Igor Stravinsky, William Faulkner, or perhaps T.S. Eliot. Of all the many variants, I prefer Faulkner’s “Immature artists copy, great artists steal.”

What does this phrase have to do with writing code? More than you’d imagine. As engineers, we’re often stuck on something, banging our heads against a wall over a block of code, or a problem we can’t solve. Some people go for a walk to overcome these blocks, and others take a shower or switch contexts. But many of us go searching the Internet for answers. We try Google, Stack Overflow, or Github for error messages, snippets of code, or implementations that might overcome our problem. When we find something that helps we take this code, often morph it a little, and then use it in our codebase:

Or in a code comment:

# From https://stackoverflow.com/questions/62048888/how-to-select-a-floating-point-or-integer-using-a-regular-expression-from-text
text.lines.find { |l| l[' Running Total '] }[/[\d.]+/]
. . .

But there is a lot of disdain, even hate, for this approach from other engineers. This hate is often combined with gatekeeper overtones or remarks about how this wasn’t how things were done when they were learning. I’ve heard it described as “copy-pasta coding” or “cargo coding,” or sometimes even described as outright plagiarism. So is it plagiarism?

To me, there’s a clear distinction between imitation and inspiration. When you go looking for that code, you’re looking for inspiration to solve the problem you have. It is rare to find the exact code you need that you can without modification, nor do you often find code can be used by simply copying it in place. By the very nature of trying to understand how someone else solved the problem, you’re learning, inspired by their creation. Later, as someone finds your code when they seek to solve the same or a similar problem, they can see your implementation and the original, and potentially receive further inspiration and insight.

There are best practices, though, that you should abide by when you use this approach. Firstly, credit the source of your inspiration, acknowledge the work of the original author, and help the next person who is following the same path to a solution. Indeed, if you feel uncomfortable about acknowledging the source of the code that inspired you, perhaps that’s a signal that you’re not doing right by the original creator?

Secondly, use the code as a learning tool; experiment and apply your knowledge and perspective to it. I recently found a Ruby method to work with a nested hash. I liked the solution but realized there was a way to make it more functional and easier to understand. So I took the code, modified it, and made it my own. In has been my experience that the best code results from code shared, whether developed with others or even code reviewed to get other’s perspectives. This process is how we learn to be better coders by learning the lessons of those who came before us and building upon them.

So ignore those folks who hate on this approach. I am sure they protest too much because I can guarantee they have done this in the past, and their disdain draws from the rose-colored glasses that inhibit memories of how they learned. Great artists don’t spawn from nothing, and “Great artists steal” is about finding inspiration; finding the key or the “eureka” moment someone else’s implementation sparks and using it as a starting point to creatively solve your problems.

– James

P.S. This post draws some ideas from Adam Kurtz’s excellent Things Are What You Make of Them and from numerous articles and interviews from the team at The Creative Independent. I strongly recommend both if you’re interested in understanding artistic creation and how great artists create.

James Turnbull is an engineering leader, author, and open source developer. James was the VP of Engineering at Glitch, a CTO-in-residence at Microsoft, CTO/Founder at Empatico, and CTO at Kickstarter. He was previously in leadership roles at Docker, Venmo, and Puppet. James was chair of O’Reilly’s Velocity conference, speaks regularly at conferences, advises a number of startups, and teaches engineering and technology skills. You can find him on Twitter.