[jimmaswell]

As a front-end lead and long time game programmer, I've been using copilot at work and home since it was invite-only. This assessment isn't accurate, at least in my case. Copilot mostly:

- Writes the same code (often verbatim) I was about to write, often multiple lines of it. "Ok, next I'll loop over the rigidbodies and apply the force to the ones in range- oh look the loop is already there"

- Gives me some API calls I didn't know about, much easier than finding a stackoverflow post. There's generally not much enlightenment to be had diving deep into the formatting of java.date or some such - if I just want to format a date and move on, it's awesome being able to type a comment "//format the date as.." and get the code. The IDE will yell at me right away if it gave me something deprecated, and I'll hover over the unfamiliar bits it put there anyway to make sure everything is sensible.

- Solves the small problem I'm looking at in a way I didn't think of, or even alerts me to an error in my thinking frequently enough - "Why is it doing that? Oh yeah, I really should've done that.."

My codebases haven't suffered, and I'm still diligent to keep them maintainable, well-tested, and fundamentally sound.

Overall, it speeds things up a lot and frees mental space for me to think about the big picture more. I generally understand the code being put out just as well as any other code I've written - be honest, you don't read a book on every API call you copy from Stack Overflow. The beauty of a good abstraction is that we generally don't have to.

If anything I think it's helped me become a better programmer over the past year, elevating the mental level of abstraction I work at somewhat.

I can see what you said being a problem for somebody just starting out though. And as the author said (and I found trying to learn Rust with Copilot on) it can even be an annoying distraction in that case.

As an aside, copilot and gpt have certainly degraded lately with hallucinations way up (copilot chat has been extra disappointing lately), maybe to save server costs. Could be why we're seeing more negative sentiment.

[JohnFen]

> be honest, you don't read a book on every API call you copy from Stack Overflow.

I don't, because I don't copy code from SO in the first place. But when I'm using or encountering an API that I'm not terribly familiar with, I absolutely do read the documentation for it. It's part of my continuing education and how I maintain a diverse professional skillset.

[gorjusborg]

Same here, I've very rarely ever copy/pasted code out of stackoverflow.

The response to my comment above is an example of what I was describing, and I don't mean it as an insult (though I understand if it is taken that way). People don't all treat software development the same.

The 'rush to action' types are more willing to shortcut the thought part of the work that others might. They are more willing to embrace AI codegen, as coding for them is not about reifying understanding.

If I were to adopt AI code generation, I'd still have to read the code to understand, which nullifies some of its value.

I do think AI code generation as a way to start designs could be good. But again, if I need to expose company code to do that, it probably isn't worth it.

[jimmaswell]

> coding for them is not about reifying understanding.

I don't agree with the implication that I have a deficit in understanding. I would more say that I focus my understanding where it matters.

For example, in web dev this would be a thorough fundamental understanding of the DOM and what interacts with it (JS/HTML/CSS, especially the warts of JS), the performance/responsiveness costs of doing things certain ways, what runs synchronously and how to use that to make the best user experience (avoid flashing/repainting with a quick synchronous thing but longer things should be async..), the overarching architecture of your codebase and how modules should fit into it, what your internal API's do..

If you're rock solid on all of that, the really important stuff of your domain, then you'll have smooth sailing whatever you do. The rest is quite often incidental. Copilot/stackoverflow/some guy on IRC says org.apache.util3.json.JSON.IsValidJson will validate my json, and I already have org.apache.util3 installed? Great, moving on to the rest of the work I have to do building this service..

If that API call blows up on me later, I'll investigate deeper, but my sense of what's important to investigate deeply rarely fails me at this point in my career. The org.apache.util3 probably have little interesting to teach me, but when Firefox started supporting raw JS modules, you bet I thoroughly looked into that.

[JohnFen]

I think it's a difference in approach and goals. One approach isn't better than another -- it all depends on the person and what their overall goal is.

Personally, I've found that very often, things I've learned that were apparently unrelated to the task at hand gives me a key insight in how to approach the task at hand in a better way. That broad knowledge base is a large part of the value I bring to the job. This continuing education is not limited to technological topics -- any knowledge from any domain may be useful to me as a dev.

This is why I go out of my way to learn things as deeply as is practical, even (or especially) if that knowledge is much more than what I need for the immediate task at hand. I'm taking a natural opportunity to advance my overall knowledge and skillset. The immediate task at hand is only part of what I'm being paid to do. Another part is expanding my knowledge base. A huge part of what I want out of any job is to expand my education.

Other devs don't have that as their goal, and there's nothing at all wrong with that. It's just a different style and different overall goals, is all.

[gorjusborg]

I wasn't implying you lacked understanding.

I was describing two different general approaches people use to write software.

Sorry to use your post as an example. I don't know anything about you outside your posts. Please don't take it personally.