Arriving at a hundred thousand lines

Your first weeks on any job are spent in code somebody else wrote, and the instinct to read it top to bottom does not work.

Start from the outside

Run it. Get it working locally before reading anything. The setup instructions are also the first test of how well maintained it is, and fixing them is a genuinely useful first contribution.

Use it. Click through the product. Knowing what it does from the outside makes the code legible in a way no diagram does.

Find the entry points. Where do requests arrive? What runs on a schedule? Those are the roots of everything else.

tree -L 2 -d              # the shape
cat README.md
git log --oneline -30     # what is being worked on
git log --format='%an' | sort | uniq -c | sort -rn | head   # who to ask

Follow one request all the way through

Pick a single feature and trace it end to end: the route, the handler, the service, the database, the response.

One vertical slice teaches more than reading five files horizontally, because it shows you the conventions: how errors are handled, where validation lives, what the layers are called, what the tests look like.

Let the tests explain

The test suite is documentation that cannot go stale, because it runs. Reading the tests for a module tells you what it guarantees and, from the setup, what it depends on.

Use the history

git log -p --follow path/to/file.java     # how it got this way
git blame file.java                        # who wrote this line, and when
git log -S "someFunction"                  # when this string appeared

git blame on a confusing line leads to the commit, the message, and often the pull request discussion explaining why. That is usually the answer to "why is this like this".

Assume it is that way for a reason

The most reliable way to look inexperienced in your first month is to declare that everything is wrong. Some of it will be. Some of it is a workaround for a real problem you have not met yet.

Ask rather than assert: "I would have expected X here, is there a reason for Y?" Both possible answers are good ones, and one of them teaches you something.

Write down what confused you

Your confusion has a short shelf life. In three months you will have absorbed the conventions and forgotten which ones were unobvious.

Keeping notes as you go, and turning them into a page in the README, is one of the highest value things a new joiner can do, and it is the only time you are qualified to write it.