[seibelj]

Get the application working locally. You will likely find a lot of old half-written doc that doesn’t work anymore, and other developers have tricks and changes they made on their local machine to get things running. You should get it all running yourself and document what you did for the next developer.

[thescriptkiddie]

My team's code hasn't been able to run locally for at least 7 years. All development consists of committing changes to SVN trunk and running a Hudson build to update a shared dev server. We have hundreds of commits per day, mostly with unhelpful messages like "up".

halp

[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.

[btown]

Wow. Can you take a byte for byte copy of the shared dev server and make a VM image or something?

[sparkywolf]

Phoenix project irl

[adonese]

This! My first job was a large Django app. It was very intimidating for me at first and the stakes were very high.

After the first successful build everything seemed very natural onwards. Reading the docs and trying to understand he whole system flow were much easier after that. Also, the version control history can give you more insights on the features and the decision being made.