[CodeMage]

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bugs that are hard to reproduce.

[9rx]

> That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

> there are many different ways to write a program to satisfy them.

"What to program" being hard was accepted from the onset and so far we see no disagreement with that.

[CodeMage]

> Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

Being able to transcribe sentences in a certain language is the skill kids pick up in elementary schools. Being a writer requires a whole set of skills built on top of that.

The reason why I brought up that difference in the first place is because both of these are called "writing". When a fan says "I heard the author is writing the next book in the series" or when an author says "I haven't been able to focus on writing due to my health issues", they're not talking about the low-level transcription skill.

> "What to program" being hard was accepted from the onset and so far we see no disagreement with that.

Similar to your interpretation of "writing", you're choosing to interpret "programming" as a process of transcribing an algorithm into a certain programming language, and everything else ends up being defined as "what to program".

That's an overly reductive interpretation, given the original context:

> For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to find out what programming actually needs to be done, is to program something that's not it, and then replace it. This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed.

> [...]

> Most of what is being done, during programming, is working through the problem space in a way which will make it more obvious what your mistakes are, in your understanding of the problem and what a solution would look like.

Notice that the original comment talks defines "determining what to program" as a process of refining your understanding of the problem itself.

In my reading of the original comment, understanding what your users need is "what to program". Writing code that solves your users' requirements is "programming".

[9rx]

> Writing code that solves your users' requirements is "programming".

For me, I need to have a solution figured out before writing code. I am not even sure how you could write code before having the problem solved. Your approach would be insightful.

Like, I get it is effectively impossible to gather all user requirements upfront and that you need to build a product to find out what details you overlooked. That means software is an iterative process. But within each iteration, surely you still need to have the solution — to the extent that it satisfies the known requirements — prepared before you can write code? Maybe if you had an infinite number of monkeys you could have them bang out something that accidentally works by throwing down random keywords, but in the real world where it is only you and your code has to meaningful, what you program is simply the expression of what to program.

Writing code is just means of conveyance, no?

[CodeMage]

> Writing code is just means of conveyance, no?

Yes, which is why I have been making the distinction between "programming" and "writing code" all this time.

Programming is hard because it's not merely writing code. Determining what to program is not the same as determining what code to write. "What to program" is about requirements. Going from "what to program" to "what code to write" is what programming is about.

[9rx]

> Going from "what to program" to "what code to write" is what programming is about.

Once your requirements are established there isn't any thing left to choose from, other than maybe whether to use a while loop instead of a for loop — stuff that makes absolutely no difference. The structure of your code, the algorithms you choose, etc. are all dictated by the requirements. So what lies in this nebulous in-between state and what makes it so hard? Is it choosing between for and while what you think is hard?

[CodeMage]

> The structure of your code, the algorithms you choose, etc. are all dictated by the requirements.

Only if you expand the meaning of the word "requirements" to encompass a full specification of the solution.

> Is it choosing between for and while what you think is hard?

You want to know what I think? I think this conversation is crossing into rudeness.

[krackers]

If good writing was easy then "LLM slop writing" wouldn't be a thing.

[9rx]

Not at all. LLM slop exists exactly because writing is easy, but figuring out what to write is hard.