I do not think javajosh would disagree with you on that. I think he was suggesting treating bugs as opportunities for learning, in fact I think this feeds into your point.

Heh, don't get me wrong: if I never wrote a bug again I'd be happy (more than happy!) But when I do write a bug, it meant that either I had a momentary lapse of memory or coordination (like a mispelling) or, and this is important, that I don't understand how part of the machine works sufficiently - either a dependency or my own code. What makes this particularly interesting is that there are many perspectives on a code base. You can look at it's static structure, it's dynamic structure, it's distributed structure, it resource allocation, as a collection of signals, you can look at it from a maintainability perspective, extensibility, how easy it is to partition work across team, how easy it is to grasp. You can look at a piece of software as a collection of artifacts, etc.(Indeed, it seems like the list of ways you can examine a codebase is monotonically increasing year after year! :)

To bring it back to bugs, a bug can exist in any of these "views" of the system, and sometimes (often) simultaneously in several of them. That's what makes them such a rich signal for our own ignorance.

(Quick editorial: I think that's why rails, Play and meteor have gone/are going in the right direction of removing, sometimes dramatically, some of the ways you have to view your system, and incredibly tight tool integration. People just don't - can't - keep so many views of the system in their head at once. We can't think about the build and low-level plumbing, for example; we need a "synchronization" abstraction. We want the build to just work. We want design- and run-time tools that are easy to update, configure and run. And so on. Meteor is the bees knees, for that reason. Although, ironically, I find my Meteor code to be incredibly bug ridden. Writing JavaScript against new libraries is fairly painful if you're used to learning through IntelliSense!)