4 ms·

I don't really share your opinion, I think bad devs will write bad code and good devs will write (mostly) good code, with or without it. The problem exhibited

by simias 5y ago

I don't really share your opinion, I think bad devs will write bad code and good devs will write (mostly) good code, with or without it. The problem exhibited in TFA is not so different from people copy/pasting StackOverflow answers without understanding them.

wyuenho 5y ago
The problem is with Copilot, or over-relying on it for its purported convenience, bad devs will have a harder time becoming good devs. Discovering what code to write and what their exact effects are is a major part of the journey to becoming good dev. If humans aren't going thru this process, I very much doubt they'll be able to quality control the code Copilot dumps in until later in the cycle. Doing things the hard way is essential for being a good dev.
- emodendroket 5y ago
  I've heard this same line for using IDEs for years. Everyone else is welcome to stick with Ed if they like. I'm going to use the tools that are available to me to make my job easier.
  - auggierose 5y ago
    If you don't understand the difference between Idea IntelliJ, which I loved as soon as it came out, and Github Copilot, then you are exactly the reason why I am frightened.
    - emodendroket 5y ago
      IntelliJ and friends make a lot of suggestions, which aren't always good to blindly accept. It's not exactly the same but it's in the same universe of machine-assisted work that still requires human direction.
      - pyrale 5y ago
        There's a pretty big difference between asking a permission and going on unless that same permission is denied. There's also a large difference in scope between the kind of suggestions a linter gives and what copilot does. Linter usually works around the syntax for equivalent semantics, while copilot tries to infer semantics.
        emodendroket 5y ago
        IntelliJ does a lot of the latter with templates.
        marcosdumay 5y ago
        Code templates are the top reason why I avoid IDEs. You just start writing something and the IDE will insert a block of code there, with no indication of where it ends, and catching you off guard if you are focused on something other than data input. The fact that there are so many people that like them that all the IDEs have the feature on by default with the off switches scattered all over their configuration so you can't turn them off is scary.
        emodendroket 5y ago
        I'm not sure what's scary about it. I find them useful. And I find the behavior is pretty predictable with experience.
  - IncRnd 5y ago
    When you work for a company that forbids copilot and blocks its traffic from the network, you'll find that your dependence on tools to create your code has held you back.
    - emodendroket 5y ago
      Heard that one before too. I have to work without the IDE for interviews and it's not a big deal. It's just slower and less efficient.
saurik 5y ago
Ok: and since I would hope we agree that no one worth being a software developer is just blindly copying code off of stack overflow into their code, Copilot is certainly a horrible idea if what it is doing is making that easier or "cooler", right? :/ If we start by assuming the developer is a "good dev", I can't imagine Copilot is going to do anything useful for them, as this isn't going to be a useful way for them to come to understand how the system they are using works, and it won't support them building abstractions to reduce boilerplate. This tool is simply not useful for them. Which leaves us with the idea what Copilot is a tool designed for "bad devs" to be able to do less work to do the bad things they do, and while I sort of appreciate the idea of "it is worthwhile to support people who don't know what they are doing in their attempt to do the bad thing they are doing anyway", I have severe reservations about doing that with engineering... it at least needs to be marketed as that! Otherwise, the two main things we should be doing for "bad devs" is either helping them become "good devs"--which this doesn't do for much the same reasons it isn't useful for "good devs"--or we should honestly be trying to convince them not to be a developer at this level at all (which might include building higher-abstraction systems that are easier to use and understand).

by simias 5y ago

wyuenho 5y ago

The problem is with Copilot, or over-relying on it for its purported convenience, bad devs will have a harder time becoming good devs. Discovering what code to write and what their exact effects are is a major part of the journey to becoming good dev. If humans aren't going thru this process, I very much doubt they'll be able to quality control the code Copilot dumps in until later in the cycle. Doing things the hard way is essential for being a good dev.

emodendroket 5y ago
I've heard this same line for using IDEs for years. Everyone else is welcome to stick with Ed if they like. I'm going to use the tools that are available to me to make my job easier.
- auggierose 5y ago
  If you don't understand the difference between Idea IntelliJ, which I loved as soon as it came out, and Github Copilot, then you are exactly the reason why I am frightened.
  - emodendroket 5y ago
    IntelliJ and friends make a lot of suggestions, which aren't always good to blindly accept. It's not exactly the same but it's in the same universe of machine-assisted work that still requires human direction.
    - pyrale 5y ago
      There's a pretty big difference between asking a permission and going on unless that same permission is denied. There's also a large difference in scope between the kind of suggestions a linter gives and what copilot does. Linter usually works around the syntax for equivalent semantics, while copilot tries to infer semantics.
      - emodendroket 5y ago
        IntelliJ does a lot of the latter with templates.
        marcosdumay 5y ago
        Code templates are the top reason why I avoid IDEs. You just start writing something and the IDE will insert a block of code there, with no indication of where it ends, and catching you off guard if you are focused on something other than data input. The fact that there are so many people that like them that all the IDEs have the feature on by default with the off switches scattered all over their configuration so you can't turn them off is scary.
        emodendroket 5y ago
        I'm not sure what's scary about it. I find them useful. And I find the behavior is pretty predictable with experience.
- IncRnd 5y ago
  When you work for a company that forbids copilot and blocks its traffic from the network, you'll find that your dependence on tools to create your code has held you back.
  - emodendroket 5y ago
    Heard that one before too. I have to work without the IDE for interviews and it's not a big deal. It's just slower and less efficient.

saurik 5y ago

Ok: and since I would hope we agree that no one worth being a software developer is just blindly copying code off of stack overflow into their code, Copilot is certainly a horrible idea if what it is doing is making that easier or "cooler", right? :/ If we start by assuming the developer is a "good dev", I can't imagine Copilot is going to do anything useful for them, as this isn't going to be a useful way for them to come to understand how the system they are using works, and it won't support them building abstractions to reduce boilerplate. This tool is simply not useful for them. Which leaves us with the idea what Copilot is a tool designed for "bad devs" to be able to do less work to do the bad things they do, and while I sort of appreciate the idea of "it is worthwhile to support people who don't know what they are doing in their attempt to do the bad thing they are doing anyway", I have severe reservations about doing that with engineering... it at least needs to be marketed as that! Otherwise, the two main things we should be doing for "bad devs" is either helping them become "good devs"--which this doesn't do for much the same reasons it isn't useful for "good devs"--or we should honestly be trying to convince them not to be a developer at this level at all (which might include building higher-abstraction systems that are easier to use and understand).