| "They don’t tell you that a lot of programming skill is about developing a knack for asking the right questions on Google and knowing which code is best to copy-paste." No, no, no! This always frustrates me. This is not 'coding' (maybe it is, and we should be doing less of it, and more programming). This is gluing together pre-coded snippets and trying to make it work. Continuing to do this is an impediment to getting better. Thinking that somehow this is what 'coding' is, is missing the point. I will read a stack overflow page perhaps in a search for some direction, look at all the 'solutions' like surveying a landscape of others approaches to the problem. Then I'll throw them all away and code my own. Possibly it will share a lot with one of the answers, what I would consider a good approach. But a literal copy and paste just doesn't happen. I would consider a copy and paste a recipe for inviting trouble, because you haven't really reasoned through the problem yourself, and thus don't really understand the solution intimately. Programming is a process of mental reasoning around your problem with an eye on the form of reasoning computers use, so you can express that reasoning to the computer in the language you're using. Because computers don't reason like humans 'reason' (ie. humans don't really 'reason'...), knowing how a computer reasons and behaves is alien and takes time to understand and learn and it takes time to become quicker at comprehending this. This is the path of becoming a better programmer. Gaining that experience so the process is less alien and you more easily can fathom how a computer will respond and behave with a certain approach of laying out of the logic you are trying to express. Copy and paste doesn't help you at all with this. In some cases it may prevent you learning essential lessons and hinder your improvement. |
Generally I agree with this, but there is a way to use copy-pasta as a learning tool. If I find a code sample that does what I want but don't understand it, here is what I do:
1. Add a comment with a link to the source for reference.
2. Rename the variables.
3. Comment the parts that I understand.
4. Flag the parts I don't understand with a simple // ? comment.
5. Research the parts of #4 until I understand them, and then update each comment accordingly.
#2 is incredibly important to me. I've been doing some walk-through tutorials lately (e.g., http://learn.knockoutjs.com), and if I use the same variable names as the tutorials suggest, then I'm just transcribing. The code doesn't stick in my head, and I'm not really learning as much. But once I start changing the variable names, then it sticks.
#3 might seem like a waste of time, but I've found with conceptually difficult code, having the #3 comments helps keep me grounded if my brain gets too muddled.