I feel like I have gone from 100% hand written code -> 0% hand written -> 50% and climbing.
I think there are things LLMs are really good at coding up and experimenting with but I think there's still a need to understand the btoader context of your software so you need to dive in at some point.
It's very important to understand what's happening, sure. Blindly shipping AI-produced code without understanding is just irresponsible. But how does writing code helps with that? Reading helps a lot, but writing just slows things down in my experience so far.
I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from.
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.
gravypod · · focus · HN ↗
I think there are things LLMs are really good at coding up and experimenting with but I think there's still a need to understand the btoader context of your software so you need to dive in at some point.
dimonomid · · focus · HN ↗
bluefirebrand · · focus · HN ↗
nrr · · focus · HN ↗
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
bluefirebrand · · focus · HN ↗
But you're right. The better indication of capability is debugging skill than writing skill.
nrr · · focus · HN ↗
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.