[kls]

I cannot agree with the GP post more, you should be able to reproduce a working environment from source and environmental config. If you cannot you may want to try getting your team and your management to see the value in investing in doing so. When I took my latest contract, I literally walked into an environment where developers where pushing to the same server, debugging on the same server and generally stomping all over each other. I felt like I was developing in the 90's all over again. They did not see that it was a huge productivity killer. I took the time to automate the development environment to the point where each developer was able to run a script and have a fully local dev environment. Isolated DB, isolated server, isolated LDAP instance everything needed to run the environment completely disconnected. It is really not that hard to go thru the process of setting everything up and capturing the process in scripts, even something as simple as shell scripts or powershell scripts are better than having the dev environment fail, and having to stop progress while everyone scrambles to get an environment back up.

As for the topic at hand, I always find the entry point of the application, fire up the debugger and walk thru the main workflows of the application. This generally gives me enough of a mental map of the app to be able to dig into an area when I get a bug or feature request. The debugger allows you to break on areas you don't understand and work thru them in more detail.

Total tangent: this is why I detest and will not whiteboard in interviews, I am a debugger forward developer, it is how I reason about code. I think behind the compiler (or interpreter) the debugger is the second most important tool in a developers toolbox. It's sole purpose is to help a developer understand what is going on at runtime. It is hands down the best way to learn a new codebase.

[thescriptkiddie]

Any advice on what to do if the code is heavily entangled with AWS?

[kls]

You should have development or pre-prod versions of your AWS services, for those areas local dev environments should point to those endpoints. Ideally each dev would have their own AWS sandbox, but I get it that sometimes that is an impractical solution so what I would personally do, is create a nightly (or unstable) instance where one can test their code against the latest code base and push needed changes to, a stable instance where known stable features and bug fixes get deployed and then a release instance where testers can test against items deemed fit to go out in the next release. Developers should switch their local to unstable and stable endpoints based on their needs as well as the condition of unstable. If someone breaks unstable, other developers can still progress against stable they just cannot push to it. So think of stable as can read but cannot write. Once unstable is back up, they can push any service changes they need to up to AWS. As a side note, it is the responsibility of whoever broke unstable to get it back up and running for the other devs.