> When you watch someone who knows what they are doing, you'll see them looping over the following steps:
> Build a mental model of the requirements
> Write code that (hopefully?!) does that
> Build a mental model of what the code actually does
> Identify the differences, and update the code (or the requirements).
This is pretty right on but I think it leaves out an aspect of writing code that I think is often pretty under appreciated. Code does two things at once: it provides a set of instructions to a machine and it communicates the authors' understanding of the program behavior those instructions are intended to express. I think this is a large part of what makes programming so fascinating and frustrating. It's what's behind the cliche that "naming things" is one of the hardest parts of programming. In growing software systems it's often not enough that a feature's implementation works. Ideally, that implementation should impose a minimum barrier to understanding for contributors to do something with it afterward. I'm not convinced this is an aspect of software development that LLMs will be able to meaningfully achieve.
I actually laughed out loud when I read that conclusion. Not only does it sound infeasible and unsustainable, it also sounds not a little arrogant and likely annoying for everyone else working with them.
Can you imagine saying to your product owner or whatever "oh yeah we're not gonna do anything new. We'll spend the next year or so rebuilding this service because the code looks ugly."
I think it’s easy to overestimate how thinly skinned most people really are because an exceptional complaint (that’s not easily dismissible) commands attention. (This isn’t necessarily a bad thing, insofar as it’s indicative of sympathy and sensitivity.)
At the very least, even if you haven’t read Camus, I expect that any programmer of any experience should already have some intuitive sympathy with “The Myth of Sisyphus.”
> Build a mental model of the requirements
> Write code that (hopefully?!) does that
> Build a mental model of what the code actually does
> Identify the differences, and update the code (or the requirements).
This is pretty right on but I think it leaves out an aspect of writing code that I think is often pretty under appreciated. Code does two things at once: it provides a set of instructions to a machine and it communicates the authors' understanding of the program behavior those instructions are intended to express. I think this is a large part of what makes programming so fascinating and frustrating. It's what's behind the cliche that "naming things" is one of the hardest parts of programming. In growing software systems it's often not enough that a feature's implementation works. Ideally, that implementation should impose a minimum barrier to understanding for contributors to do something with it afterward. I'm not convinced this is an aspect of software development that LLMs will be able to meaningfully achieve.