Why Learning to Code Is So Damn Hard

The fun part was that they turned off the timesharing service at night - but they didn't want to power down the Sigma 5 for fear that it might not start back up in the morning. There were occasional overnight batch jobs to run, but mostly I didn't have much to do.

I already knew BASIC, having punched programs on paper tape in high school to run on Transdata's service (which was how we got acquainted). I found a copy of the Algol-60 report at the office and thought it looked interesting, so I read it, tried out a bunch of programs, and learned Algol.

Then I found an assembly language and opcode reference for the Sigma 5, which was fascinating. There were plenty of blank cards to punch, so I learned machine language too.

I could have just sat back and done the night operator job and not much else, but man, there were such interesting things to fill in the rest of that time. And it's stayed interesting ever since.

Of course that was an unusual situation, and I suppose not one you could repeat now. After all, how often do you get a chance to have a whole computer all to yourself?

If you break a problem down far enough, eventually you end up with groups of problems, each containing simple conditional statements, a few variables, maybe a loop :-). That's the challenge new programmers face!

Programming is only hard because it is simultaneously a basic IT, foreign language, applied mathematics and logic class wrapped into one! Also, since its 100% cumulative, every class they miss can be a death sentence. How can you understand Inheritance if you missed the lecture on Objects (or Conditionals if you missed Variables)? I've specifically told my students not to use an IDE for the first month so they get an understanding of how command line operates.

I think another issue is simply underestimating the time it takes to complete a simple assignment like implementing the distance formula. Taking an algorithm you understand and translating it correctly can be an exponential problem.

I try to model my courses very similar to the MOOCs I've used for practice (edX, Codecademy, and Udacity) - I am a developer turned instructor, so I use these courses as guidelines as what to do. Also, I look at something like MIT's edX courses and think "if this is what they teach, why shouldn't try to model that?"

The one thing I like about the courses are that they each uses a constant engagement tactic to ensure the user did learn what they heard. 5-7 minute video, then immediately a quiz or 'lecture exercise' designed to make sure you get the material (not just repeat a definition).

Again looking at MIT's edX 6.00x course, you are given "Problem Sets" (homework) that is given a week to be completed. Each part builds to a grand finale. For example, the distance formula mentioned above is then used in my course to implement a crude version of collision detection (www.youtube.com/watch?v=W84QzXUxcL0). I use collision detection because one of the key demographics of CS courses are nerdy gamers (not an insult, I love Binding of Isaac, but that's one of the people that go into CS).

One of the other things I try to do is follow the structure of my martial arts classes. In aikido, we start each class with "tai sabaki" (basic body movements). Since these are the core fundamentals of the art, practice makes permanent. I want to start adding basic keyboarding exercises of basic syntax to get them in the habit writing the words that look like english, but aren't.

A lot of people need external mechanisms to keep themselves motivated, such as parental pressure, peer pressure, shame, and so on. As soon as people leave college, most people never learn a tall order of knowledge ever again, and most people let their existing knowledge rapidly decay. And then they're going to tell you a story about how everything they learned in college is useless, and how jobs want something entirely different.

Whatever human nature is going on inside of them that explains the outwardly visible behavior is part of the cliff people are walking toward.

Comparing "computer surgeon" to brain surgeon is like comparing sudoku to racquetball.