Когда джуниор java разработчик приходит в компанию как он начинает изучать существующий код на проекте?

мучается с настройкой окружения и сборкой проекта в течение нескольких дней,

потом дают задачу на отшибе, которая не принесет ни духовной кармы (ибо накуй юзерам не всралась) ни земных благ, но тем не менее требует знания проекта, ибо находится на самом верхнем уровне, чтобы от твоих багов было меньше ущерба тому кто дает,

ничего не показывают, торопят (или сам стесняется сидеть и "ничего не делать"), хватает задачу,

изучает только то что прямо связано с задачей, recursive = false,

тыкает пальцем в небо, не учитывает того-то того-то и того-то,

на code review получает кучу замечаний об этом, о стиле своего кода (немецкий перфекционизм отдыхает), об использовании гитхаба, о цвете волос и о погоде за окном,

основной баг никто не замечает, он проходит в релиз и его правят ничего тебе не сказав, но подумав.

ТАК ТОЖЕ БЫВАЕТ
тяжелее всего если пришел ДЖУНИОРОМ, ЕДИНСТВЕННЫМ В ПРОЕКТЕ, потому что ты будешь только педалить, а инфу узнавать ото всех,
а если синьором сразу пришел, то сам будешь все разрабатывать

-----

КАК ПРАВИЛЬНО:

1. отдавать ахуеееенное предпочтение вакансиям где можно заранее изучить проект да подольше

2. изучать как можно больше, исходя из текущих задач
2.1. изучать код от и до, от глубин к поверхности, от вызываемого к вызывающему
2.2. но в то же время разумно выбирать первый (нижний) уровень архитектуры для изучения, даже в проекте операционной системы для космической ракеты он должен быть отнюдь не самым низким

3. в выборе задачи принимать первостепенное участие!

4. лучшие задачи:
4.1. написание тестов,
4.2. ревью чужого кода - тщательный поиск мелких багов (после того как изучен тот уровень, поверх которого они пишут),
4.3. что-то отдельное от всех и минимально требующее знаний,
4.4. что-то в сааамой глубине, чтобы поменьше слоев надо было знать,
4.5. найти некрасивое, легко-решаемое, но встречающееся по всему коду, впарить свое решение и неделю пихать его в разные места по очереди,
4.6. но понимать, что с ошибкой в описании процесса настройки, мешающей только тебе, тебя могут и послать, не дав сделать из этого свою первую задачу.

5. найти самого доброго, или хотя бы самого низкого, и приватно доставать вопросами по задачам, чтобы хоть как-то их делать.

6. и вот все это время - ИЗУЧАТЬ.

ему дают задачку и показывают примерное место, где её нужно реализовать
вот от этого места он и начинает изучать исходники, по необходимости что-то спрашивая у более опытных камрадов