Иди-ка ты сам на… или правила общения в команде
Пост-ответ на статью «Иди-ка ты на !@# со своей «токсичностью».
Если бы я последовал советам из этой статьи, мне достаточно было бы проявить эмоцию и сказать автору «Иди-ка ты сам на на …, ты ничего не понимаешь!».
Однако это не помогло бы донести мою мысль. Поэтому давайте разберем поподробнее.
Цитата 1:
Если человек некомпетентен, надо дать ему об этом явно понять, а не беречь его нежные чувства в ущерб всем остальным.
Не согласен с основой этого высказывания. Я считаю, что человек не может быть компетентен или некомпетентен. Такой обобщающий черно-белый подход на практике не работает. Даже самый прокачанный senior может не знать каких-то вещей. И наоборот, у джуниоров иногда проскакивают отличные идеи.
Переходить на личности («ты не компетентен!») на код ревью вместо конкретных аргументов — это слишком просто. Если ты такой умный senior, потрудись, объясни почему именно в этом месте кода всё должно быть иначе. Не можешь объяснить — лучше не пиши ничего, потому что возможно и сам не понимаешь до конца.
При этом говорить о конкретных проблемах в коде конечно надо.
Нормальный человек рад обсудить аргументированную позицию. И воспримет в штыки негативные эмоции. Кто вообще захочет работать с токсичным членом команды?
Цитата 2:
Человек может раз за разом отправлять вам на ревью код с одними и теми же ошибками и надо отвечать на это вежливостью и улыбкой?
Если человек совершает ошибки раз за разом и не пытается как-то расти, то его надо увольнять. Поговорите с тимлидом на этот счет. Но истерить не надо всё равно. Ну, просто потому, что это не поможет.
Негативные эмоции могут породить только негативные эмоции. А ошибки в коде это никак не исправит.
Цитата 3:
Чем больше ответственность в профессии, тем больше должна быть стрессоустойчивость.
Я работал с продакшен окружением и, бывало, чинил по ночам какие-то проблемы. Зачастую, это был стресс (особенно когда возглавляешь тех отдел и отвечаешь за весь этот колхоз)
И хочу со всей ответственностью заявить: никто не любит стрессы, даже если способен их выдержать. Всегда все стараются сделать так, чтобы стрессов было меньше.
Например:
- настроить мониторинг, своевременный алерт от серверов, что есть какие-то проблемы
- код проверить автоматическим и ручным тестированием
- бекапы баз данных проверить на восстанавливаемость
- и т.д.
Короче, уменьшаем потенциальные проблемы как только можем.
Т.е. стресс — это плохо вообще-то. Даже для самых «стрессоустойчивых» людей.
Как раз-таки человек, который не любит стрессы, скорее всего сделает всё правильно, всё перепроверит, подстелит соломку и не допустит фатальных ошибок.
Цитата 4:
Несомненно, оскорблять коллегу из за недостатка знаний недопустимо, но очевидный формат «Твой код плохой, я сейчас подробно изложу причины и дам советы» уже считается токсичным поведением.
Ну да, так и есть. «Твой код плохой» — имхо бессмысленная фраза, можно было бы сразу начать с советов, а еще лучше уточняющих вопросов, почему было сделано так, а не иначе.
Послесловие
Стресс мешает работоспособности. Когда сотрудник боится отдать код на ревью, он не будет работать с энтузиазмом, не будет генерировать идеи, не будет лоялен к компании и т.д.
Легко гуглятся исследования, которые показывают, что при превышении некоторого уровня стресса, работоспособность резко снижается.
Вообще, вежливость при работе в группе придумана не сейчас, еще задолго до того, как код ревью и программирование вообще стало модным. Куча статей про «teamwork skills», не относящихся к IT никаким боком.
Лучшие идеи рождаются в благоприятной атмосфере.
Возьмите, например, правила мозгового штурма: сначала все накидывают идеи, и критиковать их вообще нельзя. И лишь потом идет подробное обсуждение.
Ну то есть, мы все люди. Люди не любят, когда кто-то указывает на их ошибки. Даже самое корректное код ревью зачастую выглядит как публичная порка. Ну так не надо усугублять!
В тех командах, где я был тимлидом, я вводил небооьшой code of conduct для code review (еще до того, как это стадо модным). А именно: вежливость, запрет на приказной тон, запрет на обсуждение личных качеств, допустимы только аргументированные комментарии и т.д. В спорных ситуациях решает большинство.
Кстати, именно большинство, а не тимлид/техлид. Так как читабельность кода и прочие штуки — это важно для всей команды, именно команда будет работать с этим кодом в дальнейшем. А не тот, кто считает себя самым умным.
Эти простые меры существенно улучшили атмосферу в команде.
Почему вообще сейчас все заговорили о CoC и teamwork? Потому что в целом время гениев-одиночек проходит. Сплоченная команда за счет синергии решит любую задачу. Поговорил с одним, поговорил с другим — и пол задачи решено. Soft skills становятся важнее и важнее с каждым днём.
Есть люди, которые никогда не работали в сплоченной команде, и не представляют, какой это кайф.
Да собственно что я тут распинаюсь, иди-ка ты сам на…))
(P.S. никого не хочу оскорбить, это просто шутка)
