3 ms·

code is an input not an output. People don’t care about code, they care about products. You can build something new using code that already exists: every produc

code is an input not an output. People don’t care about code, they care about products. You can build something new using code that already exists: every product we use today is built on a lot of what came before. My point wasn’t that writing code with AI is bad, my point was that writing code for the sake of writing code is bad. If something already exists, use it. If something doesn’t exist, build it, bring something new to the world — whether that’s with hand-typed code or ChatGPT assisted code, I don’t care. I think we should write less code.

jpc0 2y ago
> You can build something new using code that already exists: every product we use today is built on a lot of what came before. I don't disagree with this from a business perspective but for an engineers perspective I find it severely limiting. Even very very basic things should probably stay fresh foe you. If you cannot implement a basic parser ( recursive dexent / pratt etc) you will very likely reach for regex when there is likely a better solution that isn't a lot of code. You should probably know how to write leftpad... Or how to strip ascii whitespace using an ArrayBuffer and a for loop in JS. These are things that is extremely easy but a little tedius to do but are fundamental skill to building up more complex solutions later. You should probably know how to build and reason about some more advanced datastructures in your language. Basic trees, directed graphs, trie. These are things that if they are second nature for you to implement you can come up with novel solutions to actually novel problems when they come up. You also get an innate understanding of where the performance characteristics of certian algorithms and datastructures actually lay. Because big O doesn't always tell the full story...
- nprateem 2y ago
  And yet in 20 years of coding I've never needed to write any of these. Even implementing a graph is something I've only needed once or twice. It's far more important to know what you want to do rather than how to do it.
  - nunez 2y ago
    It's not about implementing a graph or a trie. It's about knowing when and why these data structures matter. Sure, you (or an LLM) can probably find a package that can quickly search for a file in an extremely large filesystem. I'm guessing that the authors of S3 didn't have that luxury when they were building out this service years ago, though. There are very few people on Earth that deal with exabytes of data, and prior art only gets you so far in this scenario. The only way something like that can be built is by truly understanding CS fundamentals. Most people study CS to become a SWE. If programming gets reduced to maintaining prompts and optimizing here and there, then there is a real risk of this discipline eroding over time.
  - jpc0 2y ago
    As the parent comment said. Even if you never need to do it. Being quire familiar with these topics can help you select the correct solution. Sometimes you don't need a binary tree, you just need a O(n) linear search but someone who has never played with the actual low level datastructures has no idea when that matters, so in their mind a hashmap makes a ton of sense because searching is between O(1) and O(log n) depending on implementation. But in many cases a flat array will be significantly more performant and is a simpler implementation but in their mind a hashmap is the better solution. Now it probably doesn't matter, but when it matters it's better to know the the answer. That for me is the big distinction between software engineering and software development. Plumbers don't need to be engineers, but there are times when you really need an engineer to design the plumbing system. Strive to be the engineer, purely because you will enjoy the craft a lot more, and people recognise drive and ambition. It doesn't matter if you are in the right place at the right time if you don't have the skills to back it up. Granted if all you want to be is a plumber that pipes APIs together and lives a different life, by all means I encourage you to enjoy life. But don't make students believe thats all their is to the industry.
nprateem 2y ago
Yes, but there's a balance. The HN purists who are wedded to their knowledge struggle with this, but then someone does need debugging skills to go in and fix things when some of the stupid things AI does makes things break. Also I've found telling it specifically where it's messed up is way more effective than just shouting at it to fix it after it's failed a second time. And sometimes you just need to manually fix it. I wrote an entire library last weekend, then rewrote it on Monday when I realised I'd messed up. Two things I wouldn't have bothered to do without AI doing the coding. I know how the important stuff works and I could pick my way through the JS, but glad I didn't have to write it. I mean, I just wouldn't have.

jpc0 2y ago

> You can build something new using code that already exists: every product we use today is built on a lot of what came before. I don't disagree with this from a business perspective but for an engineers perspective I find it severely limiting. Even very very basic things should probably stay fresh foe you. If you cannot implement a basic parser ( recursive dexent / pratt etc) you will very likely reach for regex when there is likely a better solution that isn't a lot of code. You should probably know how to write leftpad... Or how to strip ascii whitespace using an ArrayBuffer and a for loop in JS. These are things that is extremely easy but a little tedius to do but are fundamental skill to building up more complex solutions later. You should probably know how to build and reason about some more advanced datastructures in your language. Basic trees, directed graphs, trie. These are things that if they are second nature for you to implement you can come up with novel solutions to actually novel problems when they come up. You also get an innate understanding of where the performance characteristics of certian algorithms and datastructures actually lay. Because big O doesn't always tell the full story...

nprateem 2y ago
And yet in 20 years of coding I've never needed to write any of these. Even implementing a graph is something I've only needed once or twice. It's far more important to know what you want to do rather than how to do it.
- nunez 2y ago
  It's not about implementing a graph or a trie. It's about knowing when and why these data structures matter. Sure, you (or an LLM) can probably find a package that can quickly search for a file in an extremely large filesystem. I'm guessing that the authors of S3 didn't have that luxury when they were building out this service years ago, though. There are very few people on Earth that deal with exabytes of data, and prior art only gets you so far in this scenario. The only way something like that can be built is by truly understanding CS fundamentals. Most people study CS to become a SWE. If programming gets reduced to maintaining prompts and optimizing here and there, then there is a real risk of this discipline eroding over time.
- jpc0 2y ago
  As the parent comment said. Even if you never need to do it. Being quire familiar with these topics can help you select the correct solution. Sometimes you don't need a binary tree, you just need a O(n) linear search but someone who has never played with the actual low level datastructures has no idea when that matters, so in their mind a hashmap makes a ton of sense because searching is between O(1) and O(log n) depending on implementation. But in many cases a flat array will be significantly more performant and is a simpler implementation but in their mind a hashmap is the better solution. Now it probably doesn't matter, but when it matters it's better to know the the answer. That for me is the big distinction between software engineering and software development. Plumbers don't need to be engineers, but there are times when you really need an engineer to design the plumbing system. Strive to be the engineer, purely because you will enjoy the craft a lot more, and people recognise drive and ambition. It doesn't matter if you are in the right place at the right time if you don't have the skills to back it up. Granted if all you want to be is a plumber that pipes APIs together and lives a different life, by all means I encourage you to enjoy life. But don't make students believe thats all their is to the industry.

nprateem 2y ago

Yes, but there's a balance. The HN purists who are wedded to their knowledge struggle with this, but then someone does need debugging skills to go in and fix things when some of the stupid things AI does makes things break. Also I've found telling it specifically where it's messed up is way more effective than just shouting at it to fix it after it's failed a second time. And sometimes you just need to manually fix it. I wrote an entire library last weekend, then rewrote it on Monday when I realised I'd messed up. Two things I wouldn't have bothered to do without AI doing the coding. I know how the important stuff works and I could pick my way through the JS, but glad I didn't have to write it. I mean, I just wouldn't have.