In sustaining engineering, if it's not assigned to you, you can't really do it. I'd thought about doing what you suggested many times, but throughput is the #1 thing about bug fixing. I wanted to do a lot of things to improve process and the products I've worked on but it's not only not allowed, it's practically insubordination.
Bugs bugs bugs -- fix fix fix. No time to spend on anything else, my manager told me.
after reading all ur reply, I think ur problem is lack of practice. no matter how many open source side projects u put on github, they r just too simple/small/repetitive. u need to do bigger green field projects, either on a new job or in ur spare time. build something from scratch, write ur own library w/ advanced features like multithreading etc. develop application on top of it, test the crap out of it. like u said u r not the smartest guy in the room, u have to take lots of extra efforts to do well in this highly competitive field.
It was difficult to apply in my situation, though. on top of my many-hour commute, family commitments, normal day-to-day work (bug fixing is all throughput, no down time), I just don't know how many more hours of my day I could commit, which is why I ended up quitting that job.
Others seem to make more progress for less work, so I'm doing something wrong, or just not seeing what they are, or whatever.
Thanks for your advice.
Also keep in mind that these critical paths of the code produce more money for the company in a minute -- globally -- than I will produce in my entire life.
You don't just 'change' that part of the code without good reason and it's old enough that it's been throughly explored.