When I started programming, I was bad at it. There were two strategies that I used:
- Read example code and try to 'understand' it.
- Write a massive amount of code, then compile and debug if necessary.
I assumed that as I learned, I would get better at both these techniques. I assumed that:
- I would be able to read code faster and understand it better
- I would become a better debugger and spend less time debugging code I'd written.
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.