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?
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.
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?
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.
They are one in the same, no? Why would one write code that isn't required?
Are you referring to the aforementioned iteration process where the act of writing code and measuring the results will lead to realizing that not all requirements have been gathered? When you start with bubble sort and then users complain that your program is too slow you will realize that you missed that efficiency as a requirement when you were first determining "what to write", sure, but theoretically the requirement was there all along. I don't think when you discover "what to write" really matters with respect to the discussion. The process was understood in the original comment.
We can recognize that transient state where one hypothetically thought bubble sort was a suitable algorithm for the user's requirements when it actually wasn't. But isn't it still chosen under some misaligned understanding of the user requirements, like seeing bubble sort as being quick to implement and thinking fastest delivery is the requirement in the moment? The choice to use bubble sort is not random. I'm not sure refinement as more information becomes available changes anything.
> You want to know what I think? I think this conversation is crossing into rudeness.
True. I can think of nothing more rude than asking for clarification an in effort to understand someone. My apologies. I will only talk past you henceforth... But seriously, appeal to emotion is a poor device. There is no good faith discussion that can venture into the world of logical fallacies. What were you trying to accomplish here?