Dunno, maybe it's some old-school thing from the days of punch cards?

My first programming teacher was back in HS, some 25 years ago. The man was a retired software engineer in his 60s. He really pushed that train of thought - to "finish" the code in your mind, on paper, etc. before actually writing it and hitting compile / run.

I never took it literally in the sense that you need to think out the entire program, but rather that when writing functions and more overall logic, it is good practice to have it all worked out - rather than just write as you go, and iterate. The latter part is very easy to do these days, as running code is more or less instant...

This is not what he said.

> There are very different programming styles. I tend to see them as Mozart versus Beethoven. When Mozart started to write, the composition was finished. He wrote the manuscript in one go. In beautiful handwriting, too. Beethoven was a doubter and a struggler, who started writing before he finished the composition and then glued corrections onto the page.

I feel you should be able to keep the high level idea in your head at once; of course not the details. I don't think I've ever completed a piece of code without having a scheme in my head, and where it should fit in it.

I've never regretted spending time up-front on architecture and design. Of course you aren't going to write the entire program from scratch in your head. But iterating through stages of written descriptions, diagrams, actual code, and unit tests tends to produce a much higher quality result in the end than just banging out and implementation from start to finish. It takes more time at the beginning, but it takes so much less time to clean things up later that the additional time cost at the beginning is usually worth it.

Writing prose is similar. it might seem like you don't want to waste time outlining and sketching out ideas, but it's usually easier to assemble something useful from an outline than it is to try to work with a disjointed stream of consciousness.

You might get to a point of familiarity and/or mastery where you can do a lot of that work in your head. But that's very different from not doing that work at all.

I liked some of the MIT lisp lectures where they show that you compose a program out of simple functions. Think of the input, the out, and then a made up function which transforms it in 2 to 5 made up steps. Then recurse, and think of steps for the steps. Etc.

I get this now but certainly didn't 20 years ago, and I suspect it will more easily register with functional/logical programming language users. I've heard it referred to as "wholemeal" programming. Take the first step with the last one already in mind, and be circumspect. In practice you still iterate, but a lot less, and pursuit of this ideal does result in a different aesthetic to the solution. I personally have a fetish for short code with minimal departures from the standard library. I "feel" it when its correct, and this strongly conditions how I code as a result.

My father, a programmer who got his start in the punch card era, was the same way, but I never had the mental capacity for this. I need to start writing before I can concretely hold anything in my mind. The structure of the program, and the output feedback loop into themselves and emerge more or less simultaneously.