4 ms·

The main difference with SO is that the code from SO cannot always be c/p, the context is different so we had to rethink it. With copilot you have the sense tha

The main difference with SO is that the code from SO cannot always be c/p, the context is different so we had to rethink it. With copilot you have the sense that it’s contextualized and it’s the right fit. With pair programming I saw him accept multiple times the autocompleted code without reading it, he just said « wow it got it fast ». That for me is even worse than SO in that regard. For the rest I agree

ssl-3 2y ago
In all cases (using examples gleaned from Stack Overflow, or seemingly-complete code from the bot, or code crafted/hacked-together from scratch with Knuth as reference material): The intern is at the end of this toolchain, whatever that chain is. And when the intern is using that chain to produce code that they won't bother trying to understand before submitting it, then the problem is the intern. It is a poor craftsman who blames their tools. And what I mean by that is this: Suppose an apprentice is tasked with using a saw to cut some 2x4s to a specified length. It doesn't matter what kind of saw it is: It could be a handsaw, a chop saw, a handheld circular saw, a radial arm saw, a table saw, a FrameRipper 9000 Pushbutton CNC SawSaw saw, or any other manner of wood-cutting saw. Maybe they're even using an LLM bot to create the G-code to run that FrameRipper 9000. Whatever it is they're using, suppose they produce cuts that are consistently and uselessly wrong -- that are unfit for the purpose. And maybe a lot of that is OK -- after all, they're there to learn, right? Certainly, a big part of learning means making mistakes. It's going to happen, and to varying extents it's absolutely expected to happen. It can be blameless -- especially early on. But suppose the apprentice won't ever bother with even looking at the cut-up boards that they've produced to see if they're even in the same ballpark of what was requested, and just blindly submits their work (however right or wrong it may be) as a finished task. This is no longer blameless. Now, at this point: Do you blame the tool, or the person who is using that tool? (Choose exactly one.)
- shinycode 2y ago
  The person. That’s when I say that when it’s as a help it’s ok, when it’s as a cheating out, aka outsourcing brain, it’s not. « I don’t want to think it through but still appear to having worked on it » is not acceptable. I agree with all other comments that says that we don’t trust the output and always control it. Imagine the horror to trying to read, understand and fix million lines of unsupervised code generated in a production environment …
  - ssl-3 2y ago
    I suck at coding. I always have sucked at coding. I've worked on getting better at it for several decades, but even small projects (regardless of language) get me bogged down very quickly. Historically, most of my coding projects get abandoned as being apparently-insurmountable (by me). Writing code is not something that has ever fully "clicked" for me. But in the past year or so, I've finished some coding projects that are useful to me. Mostly, I've done this using a ton of help from the bot. But I don't just blindly trust what the bot produces. I read the output until I understand what it does (and why it does it that way), and if I can't understand it or if the method is awful then I get clarifications and/or revisions until I do understand it or the method is sane. I test it to make sure that it does do what I think that it should do, even with weird parameters. And if it's got unreadable spaghetti in it, or it isn't following my specifications, I coach it back towards not fucking up that way and we start at the beginning again for that section of code (wherein, I don't just blindly trust it). It is not a particularly quick process, and it does have its rocky moments, though I am getting faster and better at it...and the results are... eh? They're alright. Now, sure: I do have all of my previous failings ("learning opportunities") to look back on as I work with the bot to produce the things I want -- I've got a ton of useful (if functionally incomplete) background relating to the production of code under my belt. But this is a process that works for me. And I definitely am not cheating. I'm just using a fairly new and widely misunderstood tool to accomplish things that I (despite decades of frustrating effort) was previously broadly unable to accomplish on my own. I don't have any regrets about using this process. I don't feel, say, that I'm somehow less of a man because I've found utility in the use of a tool -- I was fully a man before I started using that tool, and I remain fully a man today. In fact, in using this tool I've learned more about code in the past year or so than I ever have before. And not just syntax and formatting, but also good structures for that code, and the importance of planning that code before a single line is ever written, and of revising that plan whenever it becomes necessary -- no matter what needs thrown away or grossly-refactored as a result of that revision. This makes me feel that the idea of writing code (without a bot) may actually "click" for me someday soon, but it also makes me question the necessity of that: Does it ever have to "click" when I've got tools like this available for me to use? At the end of the day, lazy interns were also lazy interns an eternity ago. Lazy interns produced shit code 60 years ago, and lazy interns will still produce shit code today (except now, they can produce shit code even faster -- wheeeee! -- but that's also not new). Supervising lazy interns has always been an arduous task, whether they were using written arithmetic, a slide rule, or a pocket calculator; or whether using relay logic or punch cards or one of those new-fangled glass teletypes. When the output of a lazy intern is wrong because they are just don't care about their answer, then that lazy intern is still wrong no matter how they got there or how quickly they're able to show that they're wrong...again. Much the same as it always has been. But what has changed fairly recently is that we've begun a journey that is now absolutely inevitable, and we're all in for a long ride -- whether we like it and want to be a part of it or not, we're already well on our way.
- chrisjj 2y ago
  > It is a poor craftsman who blames their tools. But this intern doesn't blame his tools. Unfortunately. And one can hardly say it is a poor end-user that blames the intern's tools. > Do you blame the tool, or the person who is using that tool? (Choose exactly one.) I'll blame the person who created that tool.

ssl-3 2y ago

In all cases (using examples gleaned from Stack Overflow, or seemingly-complete code from the bot, or code crafted/hacked-together from scratch with Knuth as reference material): The intern is at the end of this toolchain, whatever that chain is. And when the intern is using that chain to produce code that they won't bother trying to understand before submitting it, then the problem is the intern. It is a poor craftsman who blames their tools. And what I mean by that is this: Suppose an apprentice is tasked with using a saw to cut some 2x4s to a specified length. It doesn't matter what kind of saw it is: It could be a handsaw, a chop saw, a handheld circular saw, a radial arm saw, a table saw, a FrameRipper 9000 Pushbutton CNC SawSaw saw, or any other manner of wood-cutting saw. Maybe they're even using an LLM bot to create the G-code to run that FrameRipper 9000. Whatever it is they're using, suppose they produce cuts that are consistently and uselessly wrong -- that are unfit for the purpose. And maybe a lot of that is OK -- after all, they're there to learn, right? Certainly, a big part of learning means making mistakes. It's going to happen, and to varying extents it's absolutely expected to happen. It can be blameless -- especially early on. But suppose the apprentice won't ever bother with even looking at the cut-up boards that they've produced to see if they're even in the same ballpark of what was requested, and just blindly submits their work (however right or wrong it may be) as a finished task. This is no longer blameless. Now, at this point: Do you blame the tool, or the person who is using that tool? (Choose exactly one.)

shinycode 2y ago
The person. That’s when I say that when it’s as a help it’s ok, when it’s as a cheating out, aka outsourcing brain, it’s not. « I don’t want to think it through but still appear to having worked on it » is not acceptable. I agree with all other comments that says that we don’t trust the output and always control it. Imagine the horror to trying to read, understand and fix million lines of unsupervised code generated in a production environment …
- ssl-3 2y ago
  I suck at coding. I always have sucked at coding. I've worked on getting better at it for several decades, but even small projects (regardless of language) get me bogged down very quickly. Historically, most of my coding projects get abandoned as being apparently-insurmountable (by me). Writing code is not something that has ever fully "clicked" for me. But in the past year or so, I've finished some coding projects that are useful to me. Mostly, I've done this using a ton of help from the bot. But I don't just blindly trust what the bot produces. I read the output until I understand what it does (and why it does it that way), and if I can't understand it or if the method is awful then I get clarifications and/or revisions until I do understand it or the method is sane. I test it to make sure that it does do what I think that it should do, even with weird parameters. And if it's got unreadable spaghetti in it, or it isn't following my specifications, I coach it back towards not fucking up that way and we start at the beginning again for that section of code (wherein, I don't just blindly trust it). It is not a particularly quick process, and it does have its rocky moments, though I am getting faster and better at it...and the results are... eh? They're alright. Now, sure: I do have all of my previous failings ("learning opportunities") to look back on as I work with the bot to produce the things I want -- I've got a ton of useful (if functionally incomplete) background relating to the production of code under my belt. But this is a process that works for me. And I definitely am not cheating. I'm just using a fairly new and widely misunderstood tool to accomplish things that I (despite decades of frustrating effort) was previously broadly unable to accomplish on my own. I don't have any regrets about using this process. I don't feel, say, that I'm somehow less of a man because I've found utility in the use of a tool -- I was fully a man before I started using that tool, and I remain fully a man today. In fact, in using this tool I've learned more about code in the past year or so than I ever have before. And not just syntax and formatting, but also good structures for that code, and the importance of planning that code before a single line is ever written, and of revising that plan whenever it becomes necessary -- no matter what needs thrown away or grossly-refactored as a result of that revision. This makes me feel that the idea of writing code (without a bot) may actually "click" for me someday soon, but it also makes me question the necessity of that: Does it ever have to "click" when I've got tools like this available for me to use? At the end of the day, lazy interns were also lazy interns an eternity ago. Lazy interns produced shit code 60 years ago, and lazy interns will still produce shit code today (except now, they can produce shit code even faster -- wheeeee! -- but that's also not new). Supervising lazy interns has always been an arduous task, whether they were using written arithmetic, a slide rule, or a pocket calculator; or whether using relay logic or punch cards or one of those new-fangled glass teletypes. When the output of a lazy intern is wrong because they are just don't care about their answer, then that lazy intern is still wrong no matter how they got there or how quickly they're able to show that they're wrong...again. Much the same as it always has been. But what has changed fairly recently is that we've begun a journey that is now absolutely inevitable, and we're all in for a long ride -- whether we like it and want to be a part of it or not, we're already well on our way.
chrisjj 2y ago
> It is a poor craftsman who blames their tools. But this intern doesn't blame his tools. Unfortunately. And one can hardly say it is a poor end-user that blames the intern's tools. > Do you blame the tool, or the person who is using that tool? (Choose exactly one.) I'll blame the person who created that tool.