Уважение: достойны ли его неопытные специалисты?

Как более опытный коллега, вы ответственны за развитие молодых специалистов, которые с вами работают. Этот тезис мы сегодня и разберем. Демотивировать и замедлить развитие джуниора очень просто, а дать ему хороший старт – сложно. И многие «зрелые» специалисты почему-то не особо желают помогать более молодым и не испытывают к ним уважения. В прошлом посте я давал #вредныесоветы про то, как нужно относиться к менее опытным коллегам, а сегодня хочу на эту тему поговорить серьезно.

Проявите уважение

Это самый главный постулат. Что бы ни сделал начинающий специалист (разумеется, в рабочих рамках), он не достоин негативного отношения к себе. Дерьмо случается. Каждый из нас может что-то по незнанию сломать и спровоцировать баги на продакшене. Иногда мы пишем плохой код (требования/тест-кейсы). Такие проблемы нужно решать профессионально и без негатива к конкретной личности. Никто не становится опытным сразу и никто не достоин презрения за свои ошибки. Каждый человек проходит свой путь и становится опытнее по-своему. Ваша задача – проявить уважение и помочь им этот самый опыт приобрести. Ошибки – самый неприятный способ что-либо намертво закрепить в голове, но и самый эффективный. Но при грамотном разборе ситуации из всего случившегося можно выделить большой объем полезного опыта.

Введение в проект и первая задача

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

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

Дайте понять, что к вам можно и нужно подходить с вопросами. Многие новички стесняются и даже боятся это делать. В итоге они в полнейшем шоке смотрят на кучу классов и не понимают, что от них требуется. Если вы сразу сломаете этот барьер и наладите диалог, будет лучше вам обоим. Новичку – потому что он начнет быстрее впитывать в себя информацию и разбираться в проекте, а вам – потому что он скорее отстанет от вас.

Когда первая задача будет успешно закрыта, объясните в деталях работу другой части системы и снова дайте по ней задачу. И так далее. Со временем у молодого специалиста сложится довольно полная картина о том, что вообще на проекте происходит. В качестве бонуса у вас образуется взаимное уважение, которое только добавит продуктивности вам обоим.

Делегирование задач

Соблазн велик, правда? Вы можете заняться действительно важными и интересными задачами, в то время как ваши орлята будут фиксить баги повышать test coverage.

Что ж, поначалу это может быть вполне неплохим вариантом, чтобы познакомить молодого бойца с проектом. Но не стоит забывать, что он здесь не в качестве обслуги, поэтому необходимо постепенно повышать сложность решаемых задач. Выделите для новичка большую стори, которую он будет развивать спринт за спринтом. Это добавит ему вовлеченности в проект и даст понять, что он работает над чем-то действительно важным. И, самое главное, что результатом его работы будут пользоваться настоящие клиенты.

Если же давать исключительно мелкие задачки без логического развития и багфикс, то очень быстро настанет ощущение безысходности. Пропадет энтузиазм и желание как-то развиваться и помогать проекту. У человека возникнет ощущение, что он какой-то разнорабочий (не fullstack!), и что результат его работы нигде особо не заметен. Да и вы, как человек, распределяющий задачи внутри команды, таким образом не заработаете уважение своих подчиненных.

Кстати, насчет test coverage

Если вы сажаете джуниора писать юнит-тесты и повышать test coverage, то это уже сигнал задуматься. Каждая задача должна закрываться только при наличии юнит и/или интеграционных тестов. Если вам молодой боец садится писать тесты – значит, вы сами поленились их написать раньше.

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

Если к вам пришли с вопросом

Никогда не говорите, что вопрос глупый. Даже если это действительно так. Все мы когда-то начинали с нуля и не понимали базовых вещей. И далеко не все решались задавать вопросы с целью усвоить что-то! Многие из нас просто скромно сидели в тщетных попытках понять сложные вещи самостоятельно.

Если к вам пришли с вопросом – снова проявите уважение, ответьте на него и убедитесь, что материал усвоен. Не давайте сухих ответов: «это вот так, а это так». Отвечайте развернуто: «Это вот так, потому что… А это так, ведь иначе было бы… например…». На примерах всегда проще понимать, особенно если эти примеры приводят какую-то простую аналогию из жизни.

Кстати, как бы вы ответили на вопрос, что такое инкапсуляция и зачем она нужна? Я бы ответил вот так.

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

Программирование – это не твое

Программирование, аналитика, тестирование, да что угодно. Всем иногда попадаются люди, до которых долго доходит. Зато когда дойдет, то засядет крепко, а человек в неконтролируемом порыве мотивации как начнет запиливать фичи направо и налево, да всякое добро проекту причинять.

Так вот, если вы говорите кому-то, что «это не твое», то знайте – это вы плохой специалист. Это вы не в состоянии объяснить новичку, как надо. Вы не в состоянии научить его писать хороший код/требования/тест-кейсы. И, опять-таки, вы не в состоянии дать начинающему специалисту хоть что-то. Вы ответственны за его развитие, и вы с этой ролью не справляетесь. А достойны ли вы уважения молодых специалистов?

Вот парочка примеров из реальной жизни:

Когда джуниор пишет плохой код (а джуниоры всегда это делают, ведь никто не пишет хороший код с самого начала), его тимлид молча все переписывает. При этом ни слова не говорит джуниору и не показывает, как правильно. Видимо, с его точки зрения, джуниор сам должен прочитать новый идеальный код и научиться, но на практике это невозможно. Джуниор просто ничего не поймет и потеряет мотивацию. Наш тимлид – плохой тимлид.
Джуниор пишет плохой код, и тимлид при всех коллегах начинает его унижать: «ну кто так пишет, что это такое, а это здесь зачем». Если повезет, тимлид покажет, как надо, но вряд ли объяснит, почему именно так. У меня так было. А когда мы посмотрели, кто на самом деле автор этого кода, то оказалось, что это другой джуниор, который был любимчиком лида.

Не бывает плохих джуниоров, бывают плохие тимлиды. Руководить командой, мотивировать и обучать молодых специалистов – обязанность тимлидов. Team Lead переводится как Лидер Команды. Разве можно назвать лидером того, кто делает все сам и никак не ведет команду за собой? Я считаю, что нет. Это просто крепкий специалист, который может в одиночку завершить проект, но он не лидер.

Если же вы новичок, и вам говорят, что «это не твое», то помните простое правило – НИКОГО НЕ СЛУШАЙТЕ. Научиться можно всему. Как говорится, невозможное тоже возможно, просто для этого требуется больше времени. Стремитесь к тому, что вы для себя выбрали, а от таких горе-тимлидов старайтесь держаться подальше, ведь они только замедлят ваше развитие.

Мне повезло – у меня были хорошие тимлиды. И вот как они мне помогли увеличить мою зарплату в 40 раз.

Если кто-то накосячил

Случается, что по вине молодого специалиста что-то идет не так. Например, выскакивает критическая ошибка на продакшене. Если что-то подобное произошло, и нужно кого-то наказать – делайте это правильно.

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

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

Просто подойдите к виновнику торжества и спокойно, проявляя взаимное уважение, обсудите с ним, как такая проблема возникла, что было сделано неправильно и как в следующий раз сделать это лучше. Увидите, что у адекватных специалистов реакция на такие разговоры вполне положительная, и в будущем они подобных ошибок постараются не допускать. На ошибках набивается бесценный опыт, поэтому лучше негативную ситуацию использовать как опору для прыжка, а не как бревно, которым стоит бить по голове. Как говорится, shit happens.

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

Код-ревью

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

Код-ревью преследует две важных цели:

Повысить качество выполнения задачи
Научить исполнителя (и проверяющего) чему-то новому

Тимлид может проверять сам пулл-реквесты каждого своего подчиненного. Но в таком случае он покроет только первую цель: он лишь проверит качество выполнения задачи.

Гораздо эффективнее делать кросс-ревью (cross-review). Когда кто-то создает пулл-реквест на свою задачу, он должен включить не только тимлида в качестве проверяющего, но и вообще всех коллег с проекта. Также и тимлид, когда создает пулл-реквест, должен включать своих джуниоров в список ревьюеров.

Это дает сплошные бонусы:

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

В общем, всегда делайте кросс-ревью.

Менторинг

Менторинг – это отдельный разговор. Возможно, это даже тема для отдельного поста, но снова вкратце поделюсь своими соображениями на эту тему.

Всегда давайте вашим джуниорам пищу для размышлений. Рекомендуйте им хорошие книги, но не заваливайте ими. База быть должна, но в целом, читать книги скучно. Когда начинаешь читать новую книгу, ты воодушевлен, но чем дальше читаешь, тем быстрее забываешь прочитанное и, что самое главное, зачем ты эту книгу вообще взял. Читать надо о том, что можешь применить на практике прямо сейчас.

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

Будет вообще замечательно, если вы сначала вместе разберете какую-то проблему, а затем вы ему на эту тему дадите что-нибудь почитать. Соберите своих джуниоров после рабочего дня на часок и расскажите им про паттерны, которые вы используете на проекте. Дайте им задание подробнее изучить их. Через неделю снова соберитесь и закрепите знания.

Делайте так время от времени.

Заключение

У вас есть собака? Собачники часто говорят, что не бывает плохих собак, бывают лишь плохие хозяева. И это правда. Так же и здесь. Аналогия не совсем подходит, и тимлид – вовсе не хозяин собаке-джуниору, но смысл тот же: если джуниор постоянно косячит, спрашивать стоит с его начальника.

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

Всегда уважайте молодых специалистов и не смейте относиться к ним с презрением.

Понравилось? Подписывайтесь на меня в соцсетях!