Ug, sorry to hear that. Of course, I don't know your specific situation. But I've had stints where my main job was to fix bugs and/or add features to an exist

Ug, sorry to hear that. Of course, I don't know your specific situation. But I've had stints where my main job was to fix bugs and/or add features to an existing code base, and I don't consider it "easier" than designing and developing a greenfield project. In fact, I consider it considerably more difficult. To fix a bug you typically have to 1) figure out someone else's build and probably partially documented dependencies, 2) adapt to someone else's programming style and conventions, 3) figure out what the feature was supposed to do without the benefit of the business context in which it was created, 4) figure out how that feature was implemented in code, and then 5) not just get into the mindset of the programmer who wrote it, but keep enough distance from that mindset to find the flaw. In short, I consider "bug fixing" on a new and unfamiliar code base to be a pretty substantial mental challenge. I wish the industry gave more credit to what you've been doing. I have found that open source communities do give a great deal of credit to people who can get up to speed quickly with a code base and do things like improve testing coverage, fixing bugs, or improving documentation. That said, have you tried creating a side project? Probably the best thing to do would be to think of some software you think would be interesting, and try writing it. Pick a relatively new stack, and create a web app, or mobile app, or something that you think would be useful. I know, this is a lot of extra work on top of an existing job. But it might get you out of the rut.