I have a lot of professional experience teaching people how to program — usually in a pairing environment. One thing I noticed almost universally is that people start off wanting to 'forward chain' all their code, meaning, they try to predict the leaves of the code and then build them up. The other thing they do is they leave their code in an inoperable (even non-parsing) state until the very last minute where it is completely done — and then are completely flummoxed when it doesn't work.
The problem with the first practice is that it is entirely hopeless, in most cases, to predict the smallest finishing touches of code that accomplishes some goal or purpose — because, naturally, ideas and rational thinking about the purpose of some code gives rise to decompositions of the problem at hand, whereas just thinking about all the things you have on hand gives rise to no useful decomposition whatsoever.
It is a real struggle to get people to (1) think from the root to the leaves, and (2) write their code in small steps after which it is always possible to take stock and see if you understand what you have written.
I learned to write code this way by being a Haskell and Agda programmer — I was lucky enough to be professionally writing Haskell around the time they introduced typed holes, which made this methodology much more systematic and applicable than it had been before.
Add comment