Copy. Paste. Code?
Copy. Paste. Code?
How do you feel about copy/pasted code? Author Bill Sourour argues that's been the name of the game for some time and it's all good... that is, so long as you fully understand the code—particularly how it fits into your application—and are prepared to work with it in the future.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
"What percentage of your work would you say can be achieved by Googling for solutions, or libraries, or just posting on Stack Overflow?"
I was asked that question on social media recently. Ever since starting Dev Mastery a couple of months ago, I get a lot of questions over email and through Twitter and I always do my best to provide helpful answers. I found the above question particularly interesting and I’d like to share my answer with you here.
My first instinct when I saw it was to go into a sort of old man rant…
"Back in my day, we had to actually know what we were doing, we couldn’t just Google the answer! Kids today!! Arggghhh!!"
Of course, this doesn’t make any sense. First off, “back in my day” there were only a handful of libraries and commands you needed to know to be considered a decent programmer. If you cared about getting better, you had a well stocked bookshelf. Plus, we had mailing lists and newsgroups to go to and ask for help whenever we got stuck. It took longer, and didn’t have any "upvoting" functionality, but in principle, it was the same idea.
Today, with the wealth of information out there and the incredible pace of change, it’s impossible to just know everything and never Google or ask a question online. The trick is to do it in a way that leads to progress and not in a way that leads to problems.
Ideally, finding a quick answer or code snippet solution is the beginning, not the end, of your quest. If you just search for and blindly copy/paste code, in the best case scenario you’ll never get any better at writing code or solving problems (solving problems, by the way, is what your job is really about—great coders solve problems for a living). In the worst case scenario, you are going to seriously shoot yourself in the foot.
Here’s the deal, the best code is code that works well consistently and is easy to change. To achieve that, you must understand how each part of your app works and how it fits together with every other part of your app. Trying to change, improve, or extend code you don’t understand is very difficult, but trying to debug code that you don’t understand is a special kind of flaming hell. That sense of relief you got when you managed to just copy & paste some code, make it work, and move on, will pale in comparison to the wrenching frustration of trying to figure out what’s broken later. Trust me, I learned this painful lesson myself long ago and I’ve watched many, many programmers learn it since. Not fun.
"the best code is code that works well consistently and is easy to change"
So, what should you do? If finding the code snippet is the beginning, what’s the end game? The end game, of course, is understanding. Look carefully at the answer and the code you found and ask yourself, "Do I get this?" If there is any word or concept that is brand new to you and that you are not sure of, research it until you feel like you’ve got it. Then, try using the concepts you just learned to solve a different, related problem or try changing the code and predicting how it will react. Does it work like you expect it to? Can you change things and re-apply the knowledge? Yes? Great, you’ve got it! Not only will this make you a much better programmer over time, this will save you so many problems you can’t even begin to imagine!
I’m on a mission to help as many developers as I can. You can help me by recommending and sharing this article so that more people see it. For more advice like this, I invite you to sign up for my weekly newsletter at devmastery.com.
Published at DZone with permission of Bill Sourour . See the original article here.
Opinions expressed by DZone contributors are their own.