Changing Perspectives while Learning to Program

When I started programming, I was bad at it.  There were two strategies that I used:

1. Read example code and try to 'understand' it.
2. Write a massive amount of code, then compile and debug if necessary. 

It was painful. I would read code for hours, locked in a fruitless quest for 'understanding.' I would write an epic poem's worth of code, compile it, then spend an ice age debugging it.

I assumed that as I learned, I would get better at both these techniques.  I assumed that:

1. I would be able to read code faster and understand it better
2. I would become a better debugger and spend less time debugging code I'd written.

Strangely, neither of these things happened. I did improve at programming, but not in the linear path that I'd expected. Instead, I improved by having a major change in the way I was approaching the problem. 

A change in perspective is worth 80 IQ points.

-Alan Kay

I had just started web programming and I was trying to figure out how drag and drop was implemented so that I could modify it. Using my old approach of reading example code, I was wading through the JavaScript of the Yahoo User Interface toolkit (YUI). It was long.  It employed design patterns I had never even heard of and 'understanding' it was becoming a nightmare. I read it for 2 days before I got so fed up with reading the long file that I figured, 'why don't I just rip out all the stuff I don't need?'

At that moment, I began my new perspective of programming.  I was no longer just 'understanding' it, I was interacting with it. Moreover, the process of ripping out code forced me to begin a cycle of reading code, interacting with code, and running code.

The next time I wrote my own code, I no longer took the epic poem approach. I came at it from an iterative perspective.  The better I got, the more I learned to be disciplined about testing each new line of code.  As I improved further, I refined my new perspective and started thinking in terms of writing the smallest testable new bit of code.  Only then, did my debugging time decrease.

I contend that it is not possible to simply write less buggy code.  To become a better programmer, we must adopt better processes that lend themselves to overcoming the inherent difficulties of programming.