Of course I understood the concept of doing something x times with increasing counter, but I couldn't see the clear relation between what I wrote and what it did. It seemed a bit magic and I wanted to "truly understand" it before mapping the concept to syntax. It seemed too arbitrary to me to rely in my thinking on such magic.
My strategy was to unloop every loop I saw. It was ridiculous, I didn't have enough resources to keep even smaller loops in mind and I quickly forgot them. After few days I just gave up and committed it to my memory. Only then I felt that I truly understand.
I think I tried programming skipping this step but I just got irritated and really unsure if what I'm doing makes any sense. I remember it being the same with recursion, except a bit more mind-boggling. Now every time I try to understand something similar I try to reduce it to simplest case and just commit it.
I suppose other people may be unaware of what is actually keeping them from understanding and never get that far.
I had a similar transition of just writing all my code in one big block for a while, versus factoring stuff out into functions. And then putting stuff into data structures rather than primitive variables and arrays. Then, fully understanding the stack. And pointers.
Oddly enough I never had any trouble with recursion, although I have to say I probably encountered it somewhat later than iteration, at which point I was already very comfortable with the basics. (I only had access to very basic programming books and tools early on - internet? forget it) I guess I had the freedom of having no direction whatsoever and learning this stuff really slowly, something you don't have when taking a course at university. The optimal path is somewhere in between, for sure. I've done a fair bit of un-learning.
I wonder if this is harder today - the temptation of copy & paste coding is there. I've never been especially fast at typing, so typing more than a couple of lines from a book was probably harder than figuring out how the code in the book worked and how to adapt it without much trial and error. Cue comment from someone who learned to program with punch cards. (or twiddling switches...in the freezing cold...at the top of a mountain)
- assignment and sequence
- recursion / iteration
- concurrency
I don't know about the rest of the paper, but I can anecdotally but strongly confirm these observations from trying to help a bunch of people through programming courses at university - luckily "only" maths & physics students, not future programmers. A lot of people were just completely baffled by assignment and iteration. (I don't think they got as far as recursion, and concurrency would have broken their brains; presumably not for lack of intelligence, these were people who were doing well in maths & physics)
I wonder if programming courses would be better if they were sufficiently built around those hurdles, taking them one at a time? Courses I've attended (had to attend) or observed always struck me as wrong, as they confused people about syntax and semantics, and rushed assignment operations. Presumably because "it's only an equals sign". If you don't understand assignment, a 'for' loop must make no sense at all.
I don't know, maybe courses elsewhere are better. Maybe I'm not a good judge of course quality, as I attended all of them when I was already a competent programmer. (damn you, compulsory modules!)