4 ms·

> But you should still know how to do it regardless. Because of situations like this. That is the point of my comment. If you can't do your job without ChatGPT,

> But you should still know how to do it regardless. Because of situations like this. That is the point of my comment. If you can't do your job without ChatGPT, you don't have any business working in your field to begin with. Even if it's at a reduced speed, you still need to know how to do your job. I'm currently using ChatGPT for a bunch of AI/ML that I don't know how the insides are working. But I'm able to build models from scratch that does exactly what I want, with 99% accuracy in my test cases, without actually knowing what the model does, but together with GPT4 + automatic hyperparameter tuning, I'm able to build models I can use in production. Does it matter if I know exactly how everything inside in the model works, if I can get it to work exactly to my specification without it? This is essentially how I started programming as well way back in time. I didn't know exactly what the Perl code I copy-pasted did, but if it solved the problem, it solved the problem. It brought me and my family out of poverty, and at that point I couldn't care less about how the magic actually was done, just that it did work. Obviously now I have more knowledge about web field in general and 10+ languages that I no longer have to use any docs to be productive with, and maybe that'll happen with AI/ML eventually as well, but for a person who is starting with something new and wanna be productive quickly, GPT4 is a godsend.

danjoredd 3y ago
>Does it matter if I know exactly how everything inside in the model works, if I can get it to work exactly to my specification without it? Maybe not every single thing, but you should know what your lines of code that implement it do. You can't debug if you don't know why you wrote what you wrote. >This is essentially how I started programming as well way back in time. I didn't know exactly what the Perl code I copy-pasted did, but if it solved the problem, it solved the problem. It brought me and my family out of poverty, and at that point, I couldn't care less about how the magic actually was done, just that it did work. Ok. Great that it pulled you out of poverty. That's irrelevant to your argument, but Im glad for you. I guarantee you that the code sucked regardless. You might not care that you produced software that sucked, but it still guaranteed sucked. If you copy and paste code without knowing what it does, you are a bad programmer. Someone, somewhere, is going to have to clean up your mess. And they are cursing your name right now.
- capableweb 3y ago
  > Maybe not every single thing, but you should know what your lines of code that implement it do. You can't debug if you don't know why you wrote what you wrote. That's the thing though, the point of code is not to be perfect in isolation, it's to solve a problem. And if you eventually can solve a problem by treating it as a blackbox, who cares? > That's irrelevant to your argument It's not though, it's to illustrate that you can have a real-life impact using code that you don't understand at the time. > I guarantee you that the code sucked regardless That is irrelevant though, because no matter if it sucked or not, it worked and solved a real problem, which is the reason we (I at least) write code in the first place. > Someone, somewhere, is going to have to clean up your mess. And they are cursing your name right now. Well, and here I am cleaning up someone else's mess, so what? Life goes on. You seem to fall into the classical programmers trap of thinking that code has to be beautiful just to look at in order to be valuable, and anyone who disagrees is a shitty programmer and it's their fault you have to refactor some shitty code right now. It's not, they're not, and it's not their fault.
  - danjoredd 3y ago
    There are so many things wrong with this argument that it will take me a while to list every one of them. >And if you eventually can solve a problem by treating it as a black box, who cares When the inevitable security bug gets introduced because you decided to be lazy, you will care. Black boxes make spaghetti code that is inherently buggy and insecure from the get-go. My current job is to clean up from programmers like you who don't give a crap about the code as long as it "just werks." Am I glad to have the job? Yes. Does it piss me off to see such blatantly terrible code? Also yes. >It's not though, it's to illustrate that you can have a real-life impact using code that you don't understand at the time Guess what? Programming lifted me out of poverty as well. I never use black boxes and never have. If I can't understand the stack overflow post, I don't use it. I find a solution I can understand. It's irrelevant and a logical fallacy. "well using shitty code helped me not be poor so it's good lmao!" Just no. > That is irrelevant though, because no matter if it sucked or not, it worked and solved a real problem, which is the reason we (I at least) write code in the first place. If writing spaghetti code causes more problems than it solves, it's not irrelevant. And guess what? It does. It might be years before these problems are revealed, but when that code gets exploited over something simple that a cursory understanding could have solved, then yeah. That's on you. It "just werks" is not a valid excuse. > You seem to fall into the classical programmers trap of thinking that code has to be beautiful just to look at in order to be valuable, and anyone who disagrees is a shitty programmer and it's their fault you have to refactor some shitty code right now. It's not, they're not, and it's not their fault. For one, ad hominem. Second, Beautiful code =\= good code. I have seen terrible code that was written beautifully sticking to a single programming style. I have seen great code that looked a little messy. I can tell when the programmer behind the code knew what they were doing or not. I like beautiful code, but I prefer secure code. Also >and it's their fault you have to refactor some shitty code right now. It...literally is. They wrote it. If they write shitty code, and I'm the one that has to fix it, the blame falls on them for writing it in the first place without any quality in mind.

danjoredd 3y ago

>Does it matter if I know exactly how everything inside in the model works, if I can get it to work exactly to my specification without it? Maybe not every single thing, but you should know what your lines of code that implement it do. You can't debug if you don't know why you wrote what you wrote. >This is essentially how I started programming as well way back in time. I didn't know exactly what the Perl code I copy-pasted did, but if it solved the problem, it solved the problem. It brought me and my family out of poverty, and at that point, I couldn't care less about how the magic actually was done, just that it did work. Ok. Great that it pulled you out of poverty. That's irrelevant to your argument, but Im glad for you. I guarantee you that the code sucked regardless. You might not care that you produced software that sucked, but it still guaranteed sucked. If you copy and paste code without knowing what it does, you are a bad programmer. Someone, somewhere, is going to have to clean up your mess. And they are cursing your name right now.

capableweb 3y ago
> Maybe not every single thing, but you should know what your lines of code that implement it do. You can't debug if you don't know why you wrote what you wrote. That's the thing though, the point of code is not to be perfect in isolation, it's to solve a problem. And if you eventually can solve a problem by treating it as a blackbox, who cares? > That's irrelevant to your argument It's not though, it's to illustrate that you can have a real-life impact using code that you don't understand at the time. > I guarantee you that the code sucked regardless That is irrelevant though, because no matter if it sucked or not, it worked and solved a real problem, which is the reason we (I at least) write code in the first place. > Someone, somewhere, is going to have to clean up your mess. And they are cursing your name right now. Well, and here I am cleaning up someone else's mess, so what? Life goes on. You seem to fall into the classical programmers trap of thinking that code has to be beautiful just to look at in order to be valuable, and anyone who disagrees is a shitty programmer and it's their fault you have to refactor some shitty code right now. It's not, they're not, and it's not their fault.
- danjoredd 3y ago
  There are so many things wrong with this argument that it will take me a while to list every one of them. >And if you eventually can solve a problem by treating it as a black box, who cares When the inevitable security bug gets introduced because you decided to be lazy, you will care. Black boxes make spaghetti code that is inherently buggy and insecure from the get-go. My current job is to clean up from programmers like you who don't give a crap about the code as long as it "just werks." Am I glad to have the job? Yes. Does it piss me off to see such blatantly terrible code? Also yes. >It's not though, it's to illustrate that you can have a real-life impact using code that you don't understand at the time Guess what? Programming lifted me out of poverty as well. I never use black boxes and never have. If I can't understand the stack overflow post, I don't use it. I find a solution I can understand. It's irrelevant and a logical fallacy. "well using shitty code helped me not be poor so it's good lmao!" Just no. > That is irrelevant though, because no matter if it sucked or not, it worked and solved a real problem, which is the reason we (I at least) write code in the first place. If writing spaghetti code causes more problems than it solves, it's not irrelevant. And guess what? It does. It might be years before these problems are revealed, but when that code gets exploited over something simple that a cursory understanding could have solved, then yeah. That's on you. It "just werks" is not a valid excuse. > You seem to fall into the classical programmers trap of thinking that code has to be beautiful just to look at in order to be valuable, and anyone who disagrees is a shitty programmer and it's their fault you have to refactor some shitty code right now. It's not, they're not, and it's not their fault. For one, ad hominem. Second, Beautiful code =\= good code. I have seen terrible code that was written beautifully sticking to a single programming style. I have seen great code that looked a little messy. I can tell when the programmer behind the code knew what they were doing or not. I like beautiful code, but I prefer secure code. Also >and it's their fault you have to refactor some shitty code right now. It...literally is. They wrote it. If they write shitty code, and I'm the one that has to fix it, the blame falls on them for writing it in the first place without any quality in mind.