1972: Using Anything Other Than Assembly Will Make You a Bad Programmer
1995: Using a Language with a Garbage Collector Will Make You a Bad Programmer
2024: Using AI Generated Code Will Make You a Bad Programmer
BugsJustFindMe 1 hours ago [-]
> You May Become Dependent on Your Own Eventual Replacement
If you're going to be eventually replaced, and I absolutely believe that even the best of us will, you may as well get in on the ground floor to extract value for a bit before that happens.
Not writing your own code doesn't need to mean turning your brain off. You still need to look at what came out, understand it, and spot where it didn't match your needs.
marginalia_nu 1 hours ago [-]
Yeah I don't think this is a good take.
In a learning context, sure, you probably should not be using copilot or similar, the same way you shouldn't be using a calculator when doing your basic arithmetic homework.
Beyond that, this just seems like a classic scrub mentality hangup. If a tool is useful, you should use it where appropriate. You'd be a fool not to. If it's not useful, then don't use it.
JohnMakin 2 hours ago [-]
While I agree with the spirit of this post, it seems a bit misguided on several points.
1) I do not believe AI will ever replace programming as a practice, because people will still need to read/review the code (and no, I don't personally believe LLM's are going to be able to do that themselves in the vast majority of cases)
2) while the "script kiddie" characterization is a bit of an unfair generalization, there is some truth to this. I disagree that using AI to generate code puts you in that realm automatically, but I have seen quite a few cases of this actually happening to give this point some merit.
3) Using AI generated code atrophies your skills no less than using someone's imported library/module/whatever. Yes, I probably couldn't write a really good merge sort in C off the top of my head anymore without thinking through it, but I don't really have to, because a bazillion people before me have solved that problem and created abstractions over it that I can use. It is not inherently bad to use other people's code, the entire software world is built on that principle. In fact, it's an extremely junior mindset (in my view) that all code you use must be written by your own hand.
4) "code being respected" is not really a metric I'd ever go for, and I'm not sure in my career so far I've ever seen someone push a big pull request and not have a bazillion nitpicky comments about it. Respecting other people's code doesn't seem to be very common in the industry. I struggle to think why I personally would even want that. Does it work? Is it readable/maintainable by someone other than me? Is it resilient to edge cases? If all yes, good, that is all I really care about.
5) > If you're someone who has no actual interest in learning to code, and instead see AI as more of a freelancer—telling it stuff like "make a kart racer game," and "that sucks, make it better"—then none of this really applies to you.
I mean, sure. I have very little interest or joy in "coding." I like building, and coding is a means to that end. Again, seems like a very junior mindset. I know people do find an enormous amount of joy in it for the sake of it, I am not one of those people, and that's fine. Usually it drives me to create better abstractions and automation so I don't have to write more code than I want to.
cranberryturkey 9 hours ago [-]
fun fact: after 25 years as a software engineer in silicon valley, I'm convinced nobody cares about code quality and they never have.
everforward 1 hours ago [-]
They do, but very few people are good enough to either write a pull request or review one well. I wouldn’t put myself in the really good category for either.
Most people write pull requests that are scoped too poorly to tell what they’re doing. Like I get a single function with unit tests, so the best I can do for a review is check whether there are any obvious missed edge cases for a function whose purpose I don’t understand.
On the review side, most people review by doing basically what a linter does. I joke with people that if they want to nitpick my variable names then I’ll start DMing them to ask what name they want every time I need a variable. A meaningful review would analyze whether abstractions are good, whether there is behavior that relies on an unspecified part of an abstraction (timing), etc. Nobody does those.
stuckinhell 3 hours ago [-]
I have 23 years,and I'm convinced too.
mewpmewp2 1 hours ago [-]
Also most attempts at code quality lead to even worse code - into overengineered abstraction layers that no one will be able to adjust once it's inevitably realized that the assumptions were all wrong.
fragmede 1 hours ago [-]
Totally. YAGNI - you ain't gonna need it. That beautiful framework you spent extra weeks writing,
designing from first principles, turns out to be the wrong layer of abstraction because of a bad assumption. the client left off critical business logic details, or a pivot to a more popular feature of the program. The only question then is how to get out of that tech debt.
souldeux 2 hours ago [-]
Only a dozen but same. Just ship the shit. Quality never mattered.
Rendered at 21:35:04 GMT+0000 (Coordinated Universal Time) with Vercel.
1995: Using a Language with a Garbage Collector Will Make You a Bad Programmer
2024: Using AI Generated Code Will Make You a Bad Programmer
If you're going to be eventually replaced, and I absolutely believe that even the best of us will, you may as well get in on the ground floor to extract value for a bit before that happens.
Not writing your own code doesn't need to mean turning your brain off. You still need to look at what came out, understand it, and spot where it didn't match your needs.
In a learning context, sure, you probably should not be using copilot or similar, the same way you shouldn't be using a calculator when doing your basic arithmetic homework.
Beyond that, this just seems like a classic scrub mentality hangup. If a tool is useful, you should use it where appropriate. You'd be a fool not to. If it's not useful, then don't use it.
1) I do not believe AI will ever replace programming as a practice, because people will still need to read/review the code (and no, I don't personally believe LLM's are going to be able to do that themselves in the vast majority of cases)
2) while the "script kiddie" characterization is a bit of an unfair generalization, there is some truth to this. I disagree that using AI to generate code puts you in that realm automatically, but I have seen quite a few cases of this actually happening to give this point some merit.
3) Using AI generated code atrophies your skills no less than using someone's imported library/module/whatever. Yes, I probably couldn't write a really good merge sort in C off the top of my head anymore without thinking through it, but I don't really have to, because a bazillion people before me have solved that problem and created abstractions over it that I can use. It is not inherently bad to use other people's code, the entire software world is built on that principle. In fact, it's an extremely junior mindset (in my view) that all code you use must be written by your own hand.
4) "code being respected" is not really a metric I'd ever go for, and I'm not sure in my career so far I've ever seen someone push a big pull request and not have a bazillion nitpicky comments about it. Respecting other people's code doesn't seem to be very common in the industry. I struggle to think why I personally would even want that. Does it work? Is it readable/maintainable by someone other than me? Is it resilient to edge cases? If all yes, good, that is all I really care about.
5) > If you're someone who has no actual interest in learning to code, and instead see AI as more of a freelancer—telling it stuff like "make a kart racer game," and "that sucks, make it better"—then none of this really applies to you.
I mean, sure. I have very little interest or joy in "coding." I like building, and coding is a means to that end. Again, seems like a very junior mindset. I know people do find an enormous amount of joy in it for the sake of it, I am not one of those people, and that's fine. Usually it drives me to create better abstractions and automation so I don't have to write more code than I want to.
Most people write pull requests that are scoped too poorly to tell what they’re doing. Like I get a single function with unit tests, so the best I can do for a review is check whether there are any obvious missed edge cases for a function whose purpose I don’t understand.
On the review side, most people review by doing basically what a linter does. I joke with people that if they want to nitpick my variable names then I’ll start DMing them to ask what name they want every time I need a variable. A meaningful review would analyze whether abstractions are good, whether there is behavior that relies on an unspecified part of an abstraction (timing), etc. Nobody does those.