Even though it is of course impossible to really provide an answer to that question (given how vague the formulation is), we can at least say that we've all seen this happen. On StackOverflow, dozens of questions are asked everyday by people only looking for ready-made solutions to their problems, be it for homework or just plain work. So, it would appear that people do, indeed, copy and paste code instead of writing a solution of their own.

One could argue that in order to obtain some code one can paste straight into a source file, one must first be able to explain the problem in very clear, unambiguous terms. This requires understanding the problem well enough to do so. When a problem does not need understanding, chances are that the solution doesn't need any either (and as such, falls outside the scope of the original question). A good point, but there is more to the question.

But now, we need to take a closer look at the question: most of the time, it's the younger generation that is singled out as giving in to copy and pasting. Is it truly the case? Once again, it's not exacty easy to find statistics on this, but it's fair to say that the population making up the older generation of programmers probably did exactly the same thing in the past. Certainly not all of them, and they might not do it today, but it's likely they did copy and paste code to get the job done. How can we be so sure of that? Well, we only have to remember the end of the 90s, and the beginning of the 2000s. Back then, the Web was exploding and everyone was busy writing their boo.com clones and such, and this meant typically writing DHTML code that would work with Netscape and Internet Explorer, among other things. And back then, Internet was ripe with sites providing "code snippets", some companies would disallow right-clicks on their pages, hoping to prevent developers from stealing their Javascript secrets and book publishers would offer all kinds of "Cookbooks" to programmers.

This last example is worth detailing a little, as the formula for these books was exactly what happens today on StackOverflow: each chapter would open with a question asking how to do some specific task, and the answer would be provided in the form of a complete, working example. There would sometimes be some additional discussion, explaining some aspects of the solution itself or opening to other questions. But fundamentally nothing that a good answer on StackOverflow wouldn't provide, only with professional editing. And these were not bad, lazy publishers: the very much revered O'Reilly used to have a sizeable catalogue of cookbook-style books, and even launched a series of books following this very format.¹

So, if even the old-timers have been doing it in the past, why are they remarking this copying and pasting only now? One reason could be that it's because they don't do it any more today. But then, what does it actually mean, to copy and paste code? Why would it be bad practice to copy and paste code, instead of writing a solution of your own to every problem you encounter?

Answering these two questions requires asking yet another one, that of interrogating the nature of the activity of programming. I will not try to provide a thorough answer to that question right now (I'm saving this for another essay), but after years spent building teams, I believe it is safe to say that there are different kinds of developers, each with their own sets of motivations. Some work as developers for the money or the job security, some find great and intense pleasure in the practice of code and most are somewhere in-between on this spectrum. Focusing only developers showing genuine interest for coding, my experience is that one major motivation is their desire to learn. To them, coding is a way to exercise their intellect, to stretch their mind beyond what they know, to develop an understanding of the patterns underlying the problems they seek to solve.

In doing so, they need to identify the structure of the problems they work on, and turn these insights into experience, a wealth of devices of understanding they can reuse again and again, enriching and refining them each time they attack a new problem. The cyclical nature of the activity suggests there is something more than simply solving a stream of unrelated puzzles: there must be a progression not only in the output, but in how the input is prepared, taken in and digested. In other words, to these developers, the nature of programming is to continuously learn how to learn.

So, what does it have to do with the original question, one might ask? If to develop is to learn, and more specifically, to learn how to learn, then we must remember that for a learning method to be effective, it must help build and exercise critical thinking. This means seeing the patterns, the structure, the reason for why things are the way they are. Like any skill, this one requires progressive training: being confronted with code, again and again, and spotting the similarities and the differences, and then trying to figure out why.

The next step is to excercise critical thinking: to identify in the solution what there is to learn. And this is what in the end is going to scatter developers across the spectrum I talked about above. Some are not going to find it interesting, while some others will eventually find it addictive. Over time, they will not need to copy and paste code as much, as they develop their own experience, and as such, actually learn. Instead of copying and pasting from external sources, they will gradually copy and paste from their own experience, as the keen eye it takes to make good use of one's own experience is the same one trains looking at other people's code. And then, eventually, they will become old-timers, will forget how they started and will lament that all the younger generation seem able to do is copy and pasting code…

Coding, like any craft, comes with practice and observation. Practising copying and pasting can help young developers hone their observation skills during their apprenticeship, and good developers always remain young enough that they keep learning all their career. They take, take apart, take in, again and again.