Не очень люблю вообще делить людей по каким-то критериям на джуниов-мидлов-сеньоров. Обозначим джуниором новоприбывшего члена команды, который немного умеет программировать и которому интересно в вашей компании и команде поработать. Собственно взяли вы его в команду - человека надо растить, чтобы ебошил как господь. У меня не сильно большой опыт - я работаю 5.5 лет в одной конторе, из них 5 лет программером, из них 4 года над одним проектом, из них 3.5 года работал над ним практически в одну каску. Недавно кое как с горем пополам нашли более менее заинтересованного, способного сделать 1 тестовое задание, связать 2 слова и 3 технологии (линукс, сети, питон) человека. Мы реально были не сильно придирчивы к кандидатам, в принципе внятный ответ на 50% вопросов отсюда считались вполне неплохим результатом, ибо все знать заранее не работая в компаниях занимающихся провайдерами - откуда вообще, да и зачем?

Прирост скиллов

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

Книги

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

Лютый мастрид вообще всем

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

Линукс/C

  • The art of UNIX programming

Сети

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

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

Python/shell

Сервисы

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

Я там подтягиваю:

  • python
  • ruby
  • sql
  • c

но языков там куда больше поддерживается.

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

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

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

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

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

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

Компетенция в проекте

Парное программирование

Джек оф олл трэйдс?

Оценка степени пиздеца

Мотивация

Поощрение и непоощрение инициатив или БЛЯЯУГАРЕЛ-менеджмент