[skydhash]

That’s like saying enjoying composing music, but not enjoying playing music. Or creating stories, but don’t like writing. Yes they’re different activities, but linked together. The former is creativity, the latter is a medium of transmission.

Code is notation, just like music sheets, or food recipes. If your interaction with anyone else is with the end result only (the software), the. The code does not matter. But for collaboration, it does. When it’s badly written, that just increase everyone burden.

It’s like forcing everyone to learn a symphony with the record instead of the sheets. And often a badly recorded version.

[vidarh]

> That’s like saying enjoying composing music, but not enjoying playing music

Do you think that is impossible? There are plenty of people who enjoy composing music on things like trackers, with no intent of ever playing said music on an instrument.

I love coding, but I also like making things, and the two are in conflict: When I write code for the sake of writing code, I am meticulous and look for perfection. When I make things, I want to move as fast as possible, because it is the end-product that matters.

There is also a hidden presumption in what you've written that 1) the code will be badly written. Sometimes it is, but that is the case for people to, but often it is better than what I would produce (say, when needing to produce something in a language I'm not familiar enough with), 2) and that the collaboration will be with people manually working on the code. That is increasingly often not true.

[skydhash]

> When I write code for the sake of writing code,

I struggle to understand that comparison. Code is notation, you can’t write code for the sake of writing code. You have a problem and you instruct the computer how to do it. And for the sake of your collaborator and your futher self, you take care of how you write that. There’s no real distinction IMO.

> There is also a hidden presumption in what you've written that 1) the code will be badly written

The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.

Code is often the most precise explanation of some process. By being formal, it’s a truthful representation of the process. Specs and documentations can describe truth, but they do not embody it.

You can always collaborate with markdown files. But eventually someone will have to look at the code and understand what it does, because that’s the truth that matters. Anything else is prayers and hope. And if you’ve never cared about maintainability and quality of the code, it will probably be an arduous process.

[vidarh]

> Code is notation, you can’t write code for the sake of writing code.

Of course you can.

> You have a problem and you instruct the computer how to do it.

And sometimes that problem is not the point. Just like sometimes I write for the joy of writing, not because I particularly care about a reader or the meaning of the output.

> The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.

This has no relation whatsoever to the sentence you quoted.

[skydhash]

> This has no relation whatsoever to the sentence you quoted.

Maybe I wasn’t clear. What I wanted to convey is that the use of programming languages, paradigms, patterns, and other software engineering principles is related to the human side of programming.

You can solve a problem correctly, but with the resulting code being hard to parse. Or you can write readable code but with bugs. And almost everyone prefers the latter.

So badly written means incomprehensible code, mostly due to the size of it in the case of Agents. It’s all right if no one cares about the code. But if you expect someone to review it, changeset that even the author don’t understand is slop.

[vidarh]

So again, this presumes that the result must be incomprehensible. That is not at all my experience. It may become incomprehensible if you let it, just as is the case with human developers. It won't be if you enforce reviews, and your harness demands cleanups and sets clear standards.

[michael_j_x]

Using your analogy, I enjoy composing music and enjoy playing music. I don't enjoy going through the notion of writing the notes on a piece of paper with the pen. I have to do it because people can't read my mind, but if they could I would avoid it. Claude code is like that. The code that gets written, feels like the code that I would have written