I've had very similar feelings before, and in my experience that fear of "fixing" is telling me something, that i'm not in a good position to be fixing whatever it is.
You mention that "refactoring" doesn't give you the same dread? Could it be because you know the problem better if you are tackling a refactoring but you don't when you are bugfixing? I've found that that dread wasn't from bugfixing, but was from a lack of confidence about the part of the codebase i'm working on.
Personally, I've found good results with tricking my brain into thinking i'm "refactoring" while really "bugfixing". Schedule the time to review the codebase that i'll be bugfixing, talk to the author if possible (and it's not you). If I want to indulge myself I'll sometimes "mock refactor" it, I'll open a new tab in my editor and almost pseudocode rewrite the component or module that needs fixing/debugging. Then once I feel I understand it enough, I can actually dive in and fix the bugs in the original code. And by that time i'm familiar enough with that section that i'm not fearing every letter typed as I know what will happen, I understand the intent behind the code.
I also struggle with the fear of "wasting time" a lot with this kind of stuff. I have this incorrect feeling that if I was able to develop these 300 lines of code in 6 hours, that I can't possibly devote 6 more hours to fixing a few lines. But the reality is that often the small 1-2 line bugfixes are the largest timesinks of all, and that I can't be afraid to schedule those 6 hours to look into that bug. Once I get over that hump that I'm somehow "cheating" the system by allocating so much time to what ends up being so little change, I feel a LOT better about actually doing it.
You mention that "refactoring" doesn't give you the same dread? Could it be because you know the problem better if you are tackling a refactoring but you don't when you are bugfixing? I've found that that dread wasn't from bugfixing, but was from a lack of confidence about the part of the codebase i'm working on.
Personally, I've found good results with tricking my brain into thinking i'm "refactoring" while really "bugfixing". Schedule the time to review the codebase that i'll be bugfixing, talk to the author if possible (and it's not you). If I want to indulge myself I'll sometimes "mock refactor" it, I'll open a new tab in my editor and almost pseudocode rewrite the component or module that needs fixing/debugging. Then once I feel I understand it enough, I can actually dive in and fix the bugs in the original code. And by that time i'm familiar enough with that section that i'm not fearing every letter typed as I know what will happen, I understand the intent behind the code.
I also struggle with the fear of "wasting time" a lot with this kind of stuff. I have this incorrect feeling that if I was able to develop these 300 lines of code in 6 hours, that I can't possibly devote 6 more hours to fixing a few lines. But the reality is that often the small 1-2 line bugfixes are the largest timesinks of all, and that I can't be afraid to schedule those 6 hours to look into that bug. Once I get over that hump that I'm somehow "cheating" the system by allocating so much time to what ends up being so little change, I feel a LOT better about actually doing it.