Comment by nerpderp83

It’s not really that difficult once you have worked on many, many different systems. When I start a new job (on average less, and sometime much less, than every two years for the joy of all the people here that would never, ever hire me because I change jobs too much) I ask for a complete overview of the architecture in case of server side work and for the gui I just start digging in the code while waiting for the visual Studio installation. Once I have visual studio / Idea I start immediately working on some high priority isolated work while continuing to explore how all the pieces fit together. At this point I realise if there is something that is obscure or that I don’t understand and ask questions. The important thing is probably to first try to understand how it works by yourself and only after some effort ask for clarifications. Normally by the time I finish the first two-three bits of work I already have an idea of some improvement that can be done on a bigger scale to make the coding more productive (it’s easy to find, when you feel pain while implementing something it means that there is space for improvement). At that point usually I start working on the smallest improvement that gives the biggest return in parallel while implementing the next required functionality. At the end everyone wins. The users will have the functionality requested because I implement it, although a bit more slowly compared to working only on that. I have the opportunity to play with the system improving it and I learn something new. In my current job I’m quite lucky because in my role I’m dispatched to different teams that need help to deliver high priority releases. In this way I can work in different systems without changing job.