3 ms·

>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 sin

>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.
  - soulofmischief 3y ago
    Have you ever managed another programmer? Asked them to produce some code, received it, pointed out flaws or inefficiencies, tweaked it, and even learned something new from their process? That's how you treat ChatGPT. What you are displaying is ignorance on how to best grasp these tools, and wrapping it in a superiority complex doesn't make it more palatable. Try being less negative and close-minded, and explore how these tools can augment your existing workflow. If you lack the capability to differentiate good from bad code, maybe you are just too inexperienced to rely on the tool at an advanced level. If you don't lack that capability, then I fail to understand what the problem is; GPT has vastly sped up my productivity.

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.
- soulofmischief 3y ago
  Have you ever managed another programmer? Asked them to produce some code, received it, pointed out flaws or inefficiencies, tweaked it, and even learned something new from their process? That's how you treat ChatGPT. What you are displaying is ignorance on how to best grasp these tools, and wrapping it in a superiority complex doesn't make it more palatable. Try being less negative and close-minded, and explore how these tools can augment your existing workflow. If you lack the capability to differentiate good from bad code, maybe you are just too inexperienced to rely on the tool at an advanced level. If you don't lack that capability, then I fail to understand what the problem is; GPT has vastly sped up my productivity.