[a3voices]

>Once I realized that I enjoy staring at hundreds lines of code trying to figure out where the bug is

I agree it's fun at first, but once you do it for a few years on a daily basis, it gets old. I suppose most things in life are like this though. Maintaining enthusiasm about work is difficult, for me at least.

[javajosh]

Enjoying the myriad little mysteries we call "bugs" is key to being a good programmer. Bugs that we create are opportunities to understand the system better - it's a signal that there is behavior we don't understand.

[tieTYT]

> Enjoying the myriad little mysteries we call "bugs" is key to being a good programmer.

I disagree. I hate bugs and I do everything I can to prevent them from ever occurring. To me I find it fun to get better and better at preventing bugs.

[Danieru]

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.

[henrik_w]

Absolutely agree - bugs are definitely learning opportunities. I wrote a whole blog post about this - "4 Reasons Why Bugs Are Good For You":

1. Each bug can teach you something

2. You start to write code that is easier to debug if you have done a lot of debugging, because you know what you want to see to help the debugging effort.

3. Both you and the customer are happy when you find and fix a bug.

4. Solving problems is fun.

http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-goo...

[javajosh]

Yes indeed. Thanks for pointing that out.

[javajosh]

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!)

[yxhuvud]

That may get old, but what doesn't get old for me is the journey to discover how something can be improved, in structure (to avoid staring at hundreds of lines) or performance.