I used to copy/paste code all the time. Whenever I needed a quick solution to a problem, I used to jump on Google, hit the first link that seemed to solve my problem (and that was usually a link from StackOverflow), then check out the most voted answers, and then copy/paste code from the answer that seemed to be the best one out of the two or three most voted variants.
And it worked great for a while. Until it didn’t.
My code started breaking in unexpected places. And initially, I wasn’t sure why.
I don’t have time
The reasoning behind copy/pasting code was “there should probably be a better solution out there than the one I could come up with, and it’s going to be faster to just copy/paste that instead of doing my own thinking”.
And I’m not saying there’s anything wrong with that. It’s probably true. It’s highly likely that there’s a better solution out there than the one I can come up with in just a few minutes.
Also, the one that’s out there has the advantage of being vetted by the community. While if I come up with your own, I might not be so sure that it’s the best way I can solve the problem.
The value of speed
For some reason I cannot seem to remember now, I used to think that if I built my code fast enough, I would make my managers happy, and also look like the smartest person in the room.
That’s two stones with one bird. How could anyone say no to that?
Well, if that was all there was to it, it would make a lot of sense to continue doing it. But it’s not all sunshine and rainbows.
Speed alone doesn’t help much
As I mentioned before, my code started to break in unexpected places. Even though I was writing a lot of code a lot faster, I had to go back and fix bugs a few times before I could release a new feature.
So it seemed that if I added up all that time spent fixing bugs, I wasn’t getting that much of a speed bump, nor was I looking like the smartest person in the room anymore.
So, where were those bugs coming from anyway?
I didn’t know what I was doing
Obviously, I was the one fixing those bugs, so I discovered something interesting in the process.
The code that was usually causing those bugs was the code that I have been blindly copy/pasting from StackOverflow.
And the keyword there is blindly. I used to think that if others have already reviewed it, it has to be great. And it probably was, in the right context.
But the context I was in did not fit perfectly with the solution I’ve copied. Even if that solution was perfect for a different context, it was not perfect for me.
Making sure I knew what I was doing
It turns out trust is not the best way to judge code quality. It’s a lot better to find the right solution that fits your current context than to find a quick solution.
Even though I still go to StackOverflow, I now do it to look for ideas.
And if I find a good one, I might copy it and adapt it to my needs. But only when I fully understand what it does and how it does it.
If I don’t know the what and the how, I prefer to write my own solution from scratch than to trust that the code is going to work. Because I now know that it probably won’t.
How do I know the difference
If I cannot tell the difference between code that I trust, and code that I write myself, it usually means I don’t fully understand how it works. That could be either because I’m using a new method, or that the copied code is too clever for me.
So to be 100% confident that my solution is the one I want, there’s one more thing I need to do.
I need to solve the problem before I actually solve it
What I needed was to define the solution before I even started to look for how to implement it.
In other words, I needed to write down the behavior I needed (by writing a test) for the problem I had, before I started coding.
This process dramatically increased the quality of the code I now write, and it decreased the number of bugs I have to go back and fix.
But most importantly, because I have to fix fewer bugs now, I spend a lot less time on every feature. Which means I can ship faster, and I still might look pretty smart for doing that.
