Totally true. It’s hard for me to stop a project, I keep piling feature after feature for no reason. I literally stop only when Claude Max Pro hits the hourly limit.
For me it was similar, but I think it was more about a lack of a natural friction. Normally when coding there was the "hit" of seeing something work, but the actually planning/coding/debugging would eventually wear me out, so I'd stop for the day. Now it can all just be endless "hit" of success and nothing that makes me feel tired or annoyed.
The reason I believe this is because I recently went through a really annoying battle with Claude trying to get it to stop being so strict with its sandbox. I wanted it to simply load some sanitized text from a source online, and it just would not do it. The sessions when I was sorting that out were so much easier to stop and moderate than the ones where everything just kept flowing effortlessly.
> 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.”
reply