How It Began For Me

When I graduated college, I knew I wanted to be a game developer.

Since I graduated with a bachelor’s degree in Electronics, I only had rudimentary coding skills and was puzzled about how I should go about making one. This was in 2011, before the huge explosion of free educational video content on YouTube for all things under the sun, including game development.

So, after some quick research, I settled on Stencyl, a game engine written in Haxe and based on OpenFL, to make my first game. It uses Scratch, a completely visual programming, drag-and-drop interface (though you can add code blocks into the visual flow).

Stencyl calls the main components of the games “Actors”. Actors can have an appearance, multiple Behaviors, and physical properties.

In the beginning, I stuck to using the Actors in the demo projects that shipped with the engine. I updated their appearance using my own sprites. I did not change their Behaviors apart from changing a few of their properties. I also stayed as close to the built-in templates as possible.

I didn’t want to change a Behavior’s code and break something. I didn’t introspect much back then as I just wanted to get to a finished game as fast as possible.

Eventually, when I needed to implement my own functionality, I did learn more of Stencyl’s features, but just enough to complete my first few games.

A few months later, when I started my first full-time job, I was on a junior team maintaining a CRUD application written in Java. The project used a custom UI library built on top of Java Swing. It used Swing’s basic components and added tons of features to each.

By the time I left the project, I could answer any question about our UI library. However, I was pretty much clueless about Java Swing because, at the end of the day, I only worked with an abstraction on top of the Java UI framework.

If there was a bug in that library, nobody in my team was allowed, or even wanted, to touch it. As junior programmers, we pushed it up the ladder so that the seniors would manage it.

In a way, it was a convenient reason to shirk responsibility and not dig deeper than I needed to.

When I Finally Woke Up

In 2014, I hopped on a plane to go to the US as I had enrolled in the University of Utah’s game design master’s program, Entertainment Arts and Engineering (EAE).

It was there that I first realized that I could no longer escape from hard things.

The programming track had several assignments that were considered hard. Our seniors warned us about them. Our professors warned us about them. The administrative staff warned us about them.

There was no library I could use to finish the assignments, no ready-made code base I could rely on, and no one coming to save me if I didn’t submit them on time.

Plus, you can’t really use a library to create your own pixel shaders. You have to learn the underlying math and write them from scratch on your own.

That is when it struck me. I was, in fact, and had always been, a copy-paste developer.

It was a humbling experience.

By a copy-paste developer, I don’t mean someone who literally just copies and pastes code. I think of it as a distinction between those who can build applications using existing frameworks and the ones who go deeper and acquire the capabilities to actually build the frameworks that other people use.

I had always focused on finding ways to complete projects in the shortest possible time. I was so focused on building the MVP, shipping the game, and completing my work that I forgot to prioritize learning.

I had an unhealthy attitude towards approaching difficult things. If I could get around something without having to learn something difficult, I would always take the easy route.

You can’t do that with everything in life. But the modern programming landscape makes it exceedingly easy.

The Reason Why There Are So Many Copy-Paste Developers

If you want some functionality for your web project, game, or machine learning project, it has probably already been developed by someone else and posted under a generous license on GitHub.

You will also find countless libraries in pip, npm, or Maven that make implementing your exact need as easy as importing them and calling a few functions.

Even the way newbies are introduced to programming today is contributing to this.

Some people call it “Tutorial Hell.” It is when you watch or read a tutorial, copy the code, run it yourself, and, when you are done with it, have learned hardly anything at all. Apart from absorbing what little was demonstrated in the tutorial, you learn nothing about the language, framework, ecosystem, or domain.

Instead, some may even wrongly end up assuming they have learned something when they know very little.

It’s the Dunning Kruger effect en masse, but here, the ones who are affected are the millions of developers in the workforce today building software that handles sensitive data, mission-critical applications, and the world’s finances.

I also blame the rise of copy-paste developers on the ship-fast mentality. The need to quickly build something with as little effort and within as little time as possible is why indie hacker projects often end up with glaring security holes that developers with real-world experience can easily sniff out.

I also blame the current job market.

Recruiters hesitate to hire freshers unless they build a portfolio of projects. It is practically a requirement for landing a job today. When all you need to impress a would-be employer is a bunch of projects, you are going to find the quickest way to do just that.

If you are not self-aware, and frankly how many 21-year-olds are, you can quickly delude yourself into believing you are an expert when you are, in fact, just standing on the tip of the iceberg.

Because in a real-world application, the bugs that give you the most trouble are not going to be the steps that handle CRUD operations. They are going to come from a poor understanding of something as basic as equality in Javascript or a bad config file where some flag was set to a wrong value.

These are things that you never get around to learning because you are stuck in the loop of constantly building new projects.

Not to say everyone falls into this category. Eventually, the crème does rise to the top and makes sure that good software keeps the world running. Otherwise, most of us would fall back into the dark ages overnight.

Weeding Out Copy-Paste Developers

The rise of copy-paste developers is also why I understand why FAANG and equivalent companies insist on harder and harder DSA interview screening tests even though many senior developers hate them.

Programmers who got hired in the past, when it was a relatively nascent field, finished college with a love for the art of programming and learned directly from the source. There were no YouTube tutorials or Udemy courses that taught those developers new JavaScript frameworks in 6 hours.

Companies today are just adjusting their hiring practices to filter out candidates at a time when there is an abundance of half-baked over-confident developers.

And because you can’t copy-paste a solution to a custom LeetCode Hard problem.

You can rest assured that someone who can do LeetCode Hard problems can learn your company’s proprietary framework, but you can’t rely on someone who “knows” a framework to solve a real engineering problem.

The thing these companies are looking for is a candidate’s commitment to learning and upskilling themselves as the times change.

So, How Do You Fix It?

I like to think that everyone starts as a copy-paste developer but only the smart ones transcend this stage.

I am not preaching from a high horse. I still choose to be a copy-paste developer sometimes, depending on the project. I’m just asking others like me to come to the same realization that I have. In fact, I feel vulnerable putting this out into the world.

To succeed, first, you need to look deep inside and ask yourself — is there any code that you believe you won’t be able to write? If the answer is yes, you probably are a copy-paste developer. Only once you have accepted it, you can take the steps necessary to remedy it.

The direct approach to fix this is to, frankly, RTFM. Front to back. No exceptions.

Pick one thing you want to learn. Create a plan for learning it. And stick to the plan.

You can’t learn a programming language in a 30-minute video. You can from a 12-hour video but only if you are ready to watch those 12 hours over and over again until they are second nature to you.

And you have to be ready to be constantly learning — have the growth mindset, like Satya Nadella says, instead of the fixed mindset.

The fixed mindset is what made me a copy-paste developer in the first place. It is like learned helplessness.

When I was developing games in Stencyl and later Unity, if there wasn’t a ready-made asset that could do what I wanted, I would just find a design solution around it. I had just mentally created compartments where I knew I could do A, B, and C but believed X, Y, or Z were just out of my league.

If you mentally give up against a challenge that you have already determined to be too difficult or time-consuming to overcome, you’re stuck in the fixed mindset.

Closing Words

Learning happens when you stop focusing on deadlines.

Sure, we had deadlines for our assignments at the University of Utah. However, I realized that if I optimized for the deadlines by just doing the bare minimum to meet them, then I would miss out on why we were required to do those assignments in the first place.

We were there to learn, not just finish assignments and get a degree.

And learning is the first step towards breaking out of the fixed mindset.

I learned a lot at EAE but the most valuable lesson I took away was the belief that if there is some code — any code — that can realistically work, I can code it.

Believe me, once you master your craft, everything that you want to do — like ship fast, ship better features, ship unique features — becomes easier than ever.

And the most rewarding aspect of breaking out of the copy-paste developer trap is that you can apply those lessons to other things in life.

When life throws you lemons, you won’t just be content with making lemonade. You will uproot that damn lemon tree and plant something much more satisfying in its place.