Я так понял, что большинство сагрилось на слово реджект и думает что это проблема процесса. Наоборот надо уметь быстро давать и уметь принимать негативную обратную связь, если что-то делаешь не так.
Я перечислил процессы онбординга, а не обучения (и это разные процессы). Для обучения простейший набор практик это: - книжки/статьи (отобранные, с обсуждением и т.п.) - внутренние митапы - специально спланированные сложные задачи - парная разработка (или формирование техдизайна или багфиксинг) с экспертом
Это работает гораздо лучше, нежели надежда на осмос от code review (который почти никогда не работает на обучение)
да это все есть же. блин у нас есть отдельный онбординг от компании на несколько дней, есть отдельный онбординг по архитектуре и так далее - это все занимает две недели. потом на самом проекте челу даются задачки и дальше ожидается, что он будет каждый день что-то коммитить и этот код будет каждый день ревьювиться. и весь этот код идет на прод., и да это несложные задачи. я не вижу противоречия.