How to quickly understand someone else's project?

Question

Work organization

He came to the project, another programmer leaves in two weeks.
Can you recommend a plan for how to make the most of these two weeks to get the most out of the code?
There are no special docks. What exactly needs to be documented?

Answer 1

Contact the programmer with a request to tell everything.
Two weeks is enough for a mediocre project.
Well, or run, pusho this:

There are no special docks.

Instead of a thousand words, he speaks about the level of the office and the organization of the work of the development department.

Answer 2

These two weeks "Live together" with the former developer.
1) Let him tell the architecture, put on all the scraps on setting up the technical specifications and fulfilling them, show them in detail and sort them.
2) Go through typical support / development cases with him. In the second week, sit down to fulfill all the requests for the system that come to the developer (he should be nearby as a tutor)
3) Fix for yourself right away what was not clear. And ask
4) Try to negotiate (ideally through management) or personally with the old developer that you can turn to him occasionally for advice over the next few months.
5) Let the old-timer tell the everyday / political / economic features of this employer.
Are you on probation? Perfectly! In the case of a furry animal on the horizon, you have the right to leave in one day.
6) If time allows and there is a resource, then let the analysts or this developer (if he is All-inclusive) sit down and write docks on the system at night. It will be correct for the employer to offer a bonus / bonus / GPC agreement for this after the developer is fired.

Answer 3

There are no special docks. What exactly needs to be documented?

All logins, passwords, hostings, dependencies, versions of software and libs used, database structure, backup policy.
And then it all depends on what needs to be done - if you actively develop, then maybe you should not take it.
If you are lazy to support, then by notifying about the risks that the project is unknown, you can slowly figure it out.

Answer 4

The ability to read someone else's code is almost the first thing they ask when applying for a job. First of all, study how the software should work from the user's point of view, according to user instructions (at the same time specifying whether this is actually done or only in plans). And then, if your head is on your shoulders, you can figure it out.