Now I do understand many won't do so. But they already do the same, just slower, with their current method.
I admit, there few times I copied but I can count on fingers the number of times I used something from stackoverflow in my entire career (I'm not counting situations when I read somebody's explanation, but didn't use their code, which is just an example of how it works). From posts that I see people write as if they do that daily.
Also SO is only an example. There are many sites, and I call BS anybody who doesn't Ctrl + C once in a while, be it from the docs.
And if you want others to grow, make sure your answers give knowledge without giving solutions.
And still I copy paste.
I've never had the luxury, I mostly work on low level stuff and at best, SO is usually only helpful in pointing me in the right direction.
Maybe it's the language you work with?
If I copy and paste React code from SO it'll 100% break my app due to incompatible abstractions, so it doesn't make any sense to do it. However if I need a complex generic Typescript utility type, copying things verbatim is usually fine.
* Just to clarify, I'm not saying SO is bad, but just specifically the practice of blind copy/paste without reasoning about & understanding the code you've copied. SO moderators encourage/semi-enforce descriptive answers for this reason; to add context to the solutions provided.
Even if you just limit it to people largely taking solutions wholesale from SO, I still think that it’s a good jumping off point. Of course it’s a mistake to not make any modifications or look deeper than the whatever is in the snippet, but the snippet is often much better than what a noob would come up with.
Also, it’s an opportunity for learning new patterns that you might not have come up with yourself.
I would respectfully disagree on this point. Anything that perpetuates doing this in any way will always have a negative impact on code quality. If an engineer is copying solutions wholesale, even if those solutions are robust and high-quality, that's an indicator of the approach they have to producing code on a daily basis, which is going to have a much larger overall impact than that 1 answer on SO.
SO is imo a net positive benefit to the community, but only by virtue of them doing other beneficial things that balance out with the harm of copypaste programming. But I don't buy that copypaste programming is benign.
> Also, it’s an opportunity for learning new patterns that you might not have come up with yourself.
Blind copypaste is by definition not an opportunity to learn, because you need to understand (hack/fork/adapt answers given) to learn from them.
Also why all the anti-copilot seems to think their code is great, or even well understood by themself.
I have counterexamples everywhere around me all the time for these 3 points.
"Blind copypaste" is just slightly more specific thing than just "copypaste". Copypasting code you fully understand and trust is fine (though in practice, is the rarer case). "Blind copypaste" implies you know it works(ish?) and don't care as much about the how.
> Also why all the anti-copilot seems to think their code is great, or even well understood by themself.
My code is certainly not great, but I like to think I understand what I've written pretty well (there are many contributors to poor quality code, not understanding what you're writing is just one potential one).
I also like to think that, while it's not great, it's on average going to be better than code put together by someone who doesn't fully understand what they've written.
> I have counterexamples everywhere around me all the time for these 3 points.
Do you? By what metric do you consider them counterexamples?
Copypaste programming doesn't have to be benign in order to be better than the likely alternatives. The people who blind copy/paste are likely not producing high quality code in the first place. In which case, blind copy/paste is often an improvement.
1. Delve into the original source to see what happens (or reverse engineer the binary) -- very time consuming!
2. Guess. Maybe write some test apps to play around with it till you get it working. This used to be very common, but leads to situations like the PS2 encryption algorithm being completely broken because the devs didn't understand the IV parameter.[1]
3. Go on StackExchange and find an example of what you are trying to do, usually with some helpful discussion about the parameters.
[1] You would think security libraries would have the best documentation because it's so important to get it right and difficult for the developer to detect mistakes, but I've found the opposite to be the case. They're some of the worst offenders for just showing you a cryptic function prototype and assuming you know everything about the underlying math already. It feels like the crypto guys think if you couldn't write your own crypto library then you aren't good enough to use theirs, kind of missing the point of libraries.
I wonder, how much better could Github Copilot become by also looking that the modifications that are subsequently made to the accepted suggestions? Obviously this would go quite a bit further in terms of telemetry, and may become an issue. They would essentially be training based on non-public code at that point.
That will make it the target of a collaborative bias attack.
Why not? Most of the software is not built by checking the formal verification of specification but by looking into the code and having reasonable understanding that it works. Also there will be errors in the code whether we use copilot or not. Personally if I don't have an option to do a build and run and look into the output, I am reasonably sure that there is at least one bug in something like every 50 lines.
There's always almost some nuance that the accepted answer might be lacking or you should know about that is mentioned.
I think context is important. It's not inherently bad. If you are inexperienced or don't know what the code/command is doing then yes that's not ideal.
But competent developers using Stack Overflow (and all other external memory devices) appropriately to aid their workflow is perfectly valid.
I rarely copy/paste verbatim from Stack Overflow (apart from perhaps bash commands where the answer is literally the exact command I need - and in that case, why would I not use it?). But I do copy/paste, as long as I understand the code, and then adjust it accordingly.
In my experience of coaching junior devs. The number one skill I've had to train them in, above all else, is the ability to efficiently search for and find answers to their questions/unknowns quickly. (As well as digest those answers and incorporate the knowledge into their understanding - not just blind copy/paste).
I'd go as far as to say that If you are a developer in 2021 and not constantly looking up things for reference (whether to jog your memory or to quickly learn new concepts) then you're either a genius with a photographic memory, working in a very constrained domain that isn't stretching you or you're just plain doing it wrong. :-)
Copilot makes it a method of FIRST resort.
If I know what I'm doing, and know I should escape my inputs... but copilot barfs up a block copied from someone who didn't... now I have to retrain myself to spend time reading the suggested code for stupid shit like that versus just using my own knowledge in the first place.
That's a far cry from "i know the method name I want has 'string' in it somewhere"-style autocomplete.
You're basically importing a library of "every stupid crap anyone committed to github" and just hoping the the library functions in it are safe and reasonable. That's a crazy dependency to bring into your project if your own programming skills are above that of the median github user.
So, roughly half of programmers would be _better_ served just blindly using Copilot's suggestions then?
Personally, I find that I work with so many different things so often that I "googling" is often much quicker even than reading documentation or even searching my own existing code.
But I also have _zero_ interest in Copilot at all, so what do I know?
A long command is almost never a good answer.
Even that cannot really protect me from missing things like the security implications that this blog post talks about.
In this case, I probably wouldn't have fallen for the stuff CoPilot (or an equivalent SO answer) suggested, as I learned about these kind of injection issues a long time ago, but there are certainly a lot of areas where I would fail miserably to detect subtle (security) bugs. APIs are full of subtle and often non-obvious pitfalls, and even algorithms can be, where the algorithm seemingly works except for non-obvious edge cases that you might not have considered.
Is this serious? I've never literally copy pasted from stackoverflow. I read the answer and then go write my own code. Did you seriously copy pasted an entire chunk of code and committed it to your codebase after some edits?
A tool like this has the potential to help good programmers work more quickly, but it carries the risk of acting as a crutch. A lot of people might never put in the work to become good programmers because they learn how to be just good enough at using Copilot to fake it.
In a world where there are lots and lots of people trying to gain entry in the software industry, there's a major risk of this leading to a lot of incorrect, and even dangerous code making it into production because nobody really had a look at it.
However, you seem to be making the argument that is good behavior. I say it is not. The time saved by automating the googling/copying/pasting is miniscule compared to actually understanding the context in which the code is suited and ill suited. That is the developer's work, and it isn't fed by only the code.
Developing ain't typing. It's solving problems. Most of the time the problem isn't in code. Even when it is in code, there's nuance in how to best solve it that isn't. The idea that AI is useful in understanding the real world context of the problem better than the human (who has the whole context, in code and outside of it) is naive, or disingenuous.
The code i produced during my first few years isn’t something anyone should aspire to.
Additionally you likely learned over time that most SO posts are not great but provide a good starting point.
I think that when $PROJECT lets everybody do something at a scale that was before impossible, even if it's the "same thing", it is not "the same thing".