I'd just pick a bug/feature that seems short and relatively contained and isn't urgent, probably from the backlog. Inform management, and make sure it'll be de

I'd just pick a bug/feature that seems short and relatively contained and isn't urgent, probably from the backlog. Inform management, and make sure it'll be deployed when you fix it - you want to learn the entire process of development and not just the code. Start learning the architecture, stack and development process with the goal of fixing that single bug. You don't have to learn the entire stack/architecture to fix that single bug. Try not to refactor the entire system while your fixing a bug - the point is to learn how the system works, not to redesign it. Make notes of the pain points you have - from setting up a dev environment, to lack of documentation or even communication problems. When you finish, do another bug, perhaps something more challenging. If you feel that you need to read a book, or do a tutorial on part of the stack you don't know to fix the bug, then do so. When your done with a few bugs, you are in a position to know and prioritize what quality and changes could be helpful, try and implement them.