Obviously, there's more to writing good code than writing it quickly, but in spite of that, it's a trait I'm really trying to develop.
I think you have it backwards; that is, I think the ability to locate and fix bugs in code quickly is a symptom of both a skilled programmer and a quality code base. The speed isn't really the goal, its just a happy side effect.
To illustrate my point, I once worked on a large program that was a sort of parsing tool which was used "in-house" to assist with creating our product. I was a bit of a newbie, and so I was given the task of fixing a few, "minor", bugs in the code base. Unfortunatly I continuously got lost in the code and started getting very frustrated. So I took it to a co-worker, a talented programmer with 20+ years of experience, but he too was unable to explain what the particular chunk of code was doing, despite an abundance of comments and documentation. It wasn't me, the programmer, that sucked, it was the code base.
Fast forward to more recent times... My latest project is a data processing server handling a variety of input formats. My co-worker, who wrote a large portion of it, went on vacation, and I had to fix a couple bugs in it. The quality of the code generated by my co-workers was very good, and that combined with my knowledge of the programming language has enabled me to determine the causes of the bugs, come up with solutions, and have them ready for our test department very quickly. Same programmer, but a much better code base.
The point is not to worry so much about being able to hack quickly, but rather to gain experience reading other people's code and writing your own quality code. It might take you longer to design, write, and test a quality product, but when it comes time to fix a bug or add a new feature, you will be able to do it just as fast as your boss.