View: Programming as Thinking
If the hard part of programming isn't writing code, what else could it be? Maybe it's the problem-solving that happens in the programmer's head before they write the code. That would explain why programmers spend most of their time not typing.
This view is flawed though, because it suggests that programming is a linear sequence of steps. Step 1 is "think". Step 2 is "type". Step 3 is "watch the program run".
The "programming as thinking" view implies that we want to do the steps in order. If we have to go back to a previous step, that seems like failure. For example, if you type code, run it, discover it's wrong, delete it, and think some more, that seems like a problem. It indicates that you didn't think hard enough!
This is silly. There's little reason to try to write code that's perfect on the first draft. It doesn't actually matter to the big picture if we go "back" and fix problems with our code after running it if this speeds up the overall development process. In fact, experience has shown me that rapidly alternating steps of thinking, typing, and running gives me the fastest overall pace, even if I have to delete what I type. This is because our thinking is aided by the dialogue with the machine that happens in the typing and running steps.
This doesn't mean you shouldn't plan the broad strokes of what you're going to do before you do it. Worthwhile planning techniques include ReadmeDrivenDevelopment, UserStory, TopOfBacklog, Spike, and Prototype. But when it comes to writing code, rapid feedback from the machine is going to show you what will and won't work, and that is priceless. Thinking will never do that.