Комментарии 8
Краткий конспект: делайте как правильно, а как неправильно — не делайте.
У меня сейчас немного размазанная позиция, я и архитектор и тех лид и сениор девелопер. В команде кроме меня ещё 1 сениор послабее и несколько аутсорсорсеров из других, но наших офисов, кто-то джуниор, кто-то слабенький джуниор. И я столкнулся с проблемой, что джуниоров ну никак не могу научить писать как надо, мне написать самому быстрее и легче чем им обьяснять. Я конечно понимаю что надо делегировать и их учить, но скорость обучения очень маленькая и они тоже «умные».
В свою защиту скажу что код и архитектура довольно простые для понимания и они разобрались очень быстро откуда начинать и что делать, но их код уровня универа где пишут так чтоб хоть как-то заработало.
Позволить им писать как умеют не вариант потому что проект хоть пока и не сильно требователен к перформансу, но нужно постоянно кастомизации встявлять и буквально завтра 100500+ клиентов набежит, поэтому надо писать так как будто у нас они уже есть и учитывать возможные расширения функционала, чтоб не было как в паралельных проектах где надо всё переделать вчера.
Вот и чё делать не понятно, вроде как я понимаю что надо пытаться выжать максимум из тех ресурсов которые есть, а не надеяться на то что потом наберём получше и всё заиграет, но текущие ресурсы не ускоряют процесс, а наоборот и уже полгода как нет движения в лучшую сторону.
В свою защиту скажу что код и архитектура довольно простые для понимания и они разобрались очень быстро откуда начинать и что делать, но их код уровня универа где пишут так чтоб хоть как-то заработало.
Позволить им писать как умеют не вариант потому что проект хоть пока и не сильно требователен к перформансу, но нужно постоянно кастомизации встявлять и буквально завтра 100500+ клиентов набежит, поэтому надо писать так как будто у нас они уже есть и учитывать возможные расширения функционала, чтоб не было как в паралельных проектах где надо всё переделать вчера.
Вот и чё делать не понятно, вроде как я понимаю что надо пытаться выжать максимум из тех ресурсов которые есть, а не надеяться на то что потом наберём получше и всё заиграет, но текущие ресурсы не ускоряют процесс, а наоборот и уже полгода как нет движения в лучшую сторону.
У вас на двоих сеньоров приходится несколько (я так понимаю минимум двое) джуниоров и один тимлид. В этом, на мой взгляд, и есть проблема. В Вашей команде просто некому писать код. По своему опыту вывел правило, что один джун съедает 50% времени одного сеньора. Два джуна — это уже минус сеньор с проекта.
Это какие же должны быть джуны, чтобы на них тратилось по 50% рабочего времени (внимания) сеньора?
и несколько аутсорсорсеров из других, но наших офисов, кто-то джуниор, кто-то слабенький джуниор
Джуниор джуниору рознь. На практике встречал как и очень толковых старшекурсников, так и уж совсем не пробиваемых, которые не правильно выбрали профессию. К сожалению в команду не всегда попадают люди, которых ты сам можешь отбирать. Встречал таких, которые после универа не понимают в структуры данных и простейшие алгоритмы.
Работал удаленно, поэтому скрупулезно записывал все время на митинги. Обратил внимание, что на общение с джуниором уходит от 2х часов в день (в случае если человек схватывает) и до 6ти часов (когда приходится работать кувалдой и прочими тяжелыми инструментами). Т.к. уровень подготовки и скилов очередного джуна — это полнейший рандом, то отсюда и обобщил, что
По своему опыту вывел правило, что один джун съедает 50% времени одного сеньора.
Совершенно согласен, курирование джунов еще подразумевает переключение контекстов и погружение в задачи начального уровня.
Согласен с предыдущим комментатором, если джуниоров больше 2-х, то это многовато.
Кроме того, по опыту знаю что иногда у ревьювера может быть синдром «если код написан не так как написал бы я, то это плохой код». Иногда нужно чуть расслабиться и принять, что способов решить задачу много и код не плохой, а просто не привычный.
Ещё я не понял, привлекаете ли вы сеньёра к review? Если нет, то стоит. Например на задачу назначается два человека: джуниор (который будет делать здачу) и сеньёр который будет его ревьювить. Если потом выясниться что задача сделана косячно, то в первую очередь вопросы к сеньёру.
Так же, вы пишите что не можете позволить им писать плохой код из-за того потенциальных проблем с производительностью. Почему бы при постановке задачи, вместе с ней не поставлять набор перфоманс тестов для неё? Тогда пусть пишут как угодно, но перфоманс-тесты должны пройти. Если нет времени писать, то можно их же заставить писать такие тесты. Тогда вам нужно будет проверить только корректность тестов.
Ну и в конце концов если молодой специалист систематически косячит, не прогрессируют (и может быть при этом перечит), то почему бы его просто не уволить?
К этому надо относиться спокойно. Должность младшего специалиста это фильтр который не все проходят.
Кроме того, по опыту знаю что иногда у ревьювера может быть синдром «если код написан не так как написал бы я, то это плохой код». Иногда нужно чуть расслабиться и принять, что способов решить задачу много и код не плохой, а просто не привычный.
Ещё я не понял, привлекаете ли вы сеньёра к review? Если нет, то стоит. Например на задачу назначается два человека: джуниор (который будет делать здачу) и сеньёр который будет его ревьювить. Если потом выясниться что задача сделана косячно, то в первую очередь вопросы к сеньёру.
Так же, вы пишите что не можете позволить им писать плохой код из-за того потенциальных проблем с производительностью. Почему бы при постановке задачи, вместе с ней не поставлять набор перфоманс тестов для неё? Тогда пусть пишут как угодно, но перфоманс-тесты должны пройти. Если нет времени писать, то можно их же заставить писать такие тесты. Тогда вам нужно будет проверить только корректность тестов.
Ну и в конце концов если молодой специалист систематически косячит, не прогрессируют (и может быть при этом перечит), то почему бы его просто не уволить?
К этому надо относиться спокойно. Должность младшего специалиста это фильтр который не все проходят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 советов для того, чтобы быть хорошим техническим лидером