Не люблю делить людей на джуниов-мидлов-сеньоров. Обозначим джуниором новоприбывшего члена команды, который немного умеет программировать и которому интересно в вашей команде поработать. Взяли его в команду - человека надо растить, чтобы хорошо работал. Как?

Наращивание навыков

В обучении нужен баланс. Нужно чтобы человек меньше отвлекал, но и больше делал.

Книги

Лучший способ проникнуться чьим-то опытом, никого не дергая. Какие книги я обычно рекомендую:

Вообще всем

  • Программист-прагматик - чтобы человек понимал что вообще такое работа программиста.
  • Мифический человекомесяц - чтобы человек перестал давать оптимистичные оценки.
  • Критическая цепь - чтобы после прочтения мифического месяца перестал давать пессимистичные оценки.
  • Психбольница в руках пациентов - чтобы человек понял, что он поехавший и другие программисты тоже поехавшие.

Linux

  • The art of UNIX programming - хороший скелет, вокруг которого будет вырастать хороший вкус в архитектуре.

Сети

Тут сложно. Читать талмуды - идея так себе, если не планируешь строить сеть провайдера с нуля, одновременно её и абонентов поддерживая в течении 10 лет. В нашем случае достаточно понимать такие простые и плохие вещи как:

  • IPv4 адресация и маршрутизация
  • tcpdump, traceroute, iproute2, iputils и прочие средства отладки
  • понимание как пакет идёт по сети
  • cli пары-тройки вендоров сетевого оборудования, redback/mikrotik/cisco/dlink/huawei, выберите любого
  • Vlan, QinQ, PPPoE и еще пару туннельных протоколов

Python/shell

Сервисы

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

Действия/практики

Я вообще поехавший либерал-демократ наверное в разработке и не особо люблю пользоваться тем, что “ЫЫААА Я СКАЗАЛ БЯРОЗА Я ЗДЭСЯ ГЛАВНЫЙ!” Короче равноправие, эквализм и все дела, но в меру.

Update 2019: прочитал Сократа, постарел, считаю что иногда “Я СКАЗАЛ БЯРОЗА Я ЗДЭСЯ ГЛАВНЫЙ” - вполне уместно и лучший способ сделать то, что нужно. Но старайтесь хотя бы потом объяснить почему такой выбор сделали. Иначе такие выборы всегда придётся делать Вам.

Пулл-реквесты в обе стороны

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

Ревью нужно в том числе для того чтобы учиться. Рекомендую иногда брать сделанный джуниором с нуля модуль и рефакторить его до упора. Затем прислать ему пуллреквест, в процессе ревью честно защищать свои правки, объясняя почему вы считаете, что нужно так, а не иначе. Если джун не согласен и отклоняет - его дело, ему с этим кодом возиться потом. Принимает - надеемся, что проникся, почему надо так, потом лучше код писать будет.

Опять же, изменения в те части проекта, где owner вы - тоже должны проходить через какого-нибудь джуниора, чтобы компетенция в проекте и навыки росли. К тому же глаза имеют свойство замыливаться, мозги глючить, а тесты - пропускать баги, вдруг чего найдёт.