Хабрахабр

Иди-ка ты сам на… или правила общения в команде

Пост-ответ на статью "Иди-ка ты на !@# со своей "токсичностью"".

Если бы я последовал советам из этой статьи, мне достаточно было бы проявить эмоцию и сказать автору "Иди-ка ты сам на на ..., ты ничего не понимаешь!".

Поэтому давайте разберем поподробнее. Однако это не помогло бы донести мою мысль.

Цитата 1:

Если человек некомпетентен, надо дать ему об этом явно понять, а не беречь его нежные чувства в ущерб всем остальным.

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

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

При этом говорить о конкретных проблемах в коде конечно надо.

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

Цитата 2:

Человек может раз за разом отправлять вам на ревью код с одними и теми же ошибками и надо отвечать на это вежливостью и улыбкой?

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

А ошибки в коде это никак не исправит. Негативные эмоции могут породить только негативные эмоции.

Цитата 3:

Чем больше ответственность в профессии, тем больше должна быть стрессоустойчивость.

Зачастую, это был стресс (особенно когда возглавляешь тех отдел и отвечаешь за весь этот колхоз). Я работал с продакшен окружением и, бывало, чинил по ночам какие-то проблемы.

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

Например:

  • настроить мониторинг, своевременный алерт от серверов, что есть какие-то проблемы
  • код проверить автоматическим и ручным тестированием
  • бекапы баз данных проверить на восстанавливаемость
  • и т.д.

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

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

Цитата 4:

Несомненно, оскорблять коллегу из за недостатка знаний недопустимо, но очевидный формат «Твой код плохой, я сейчас подробно изложу причины и дам советы» уже считается токсичным поведением.

"Твой код плохой" — имхо бессмысленная фраза, можно было бы сразу начать с советов, а еще лучше уточняющих вопросов, почему было сделано так, а не иначе. Ну да, так и есть.

Послесловие

Когда сотрудник боится отдать код на ревью, он не будет работать с энтузиазмом, не будет генерировать идеи, не будет лоялен к компании и т.д. Стресс мешает работоспособности.

Легко гуглятся исследования, которые показывают, что при превышении некоторого уровня стресса, работоспособность резко снижается.

Куча статей про "teamwork skills", не относящихся к IT никаким боком. Вообще, вежливость при работе в группе придумана не сейчас, еще задолго до того, как код ревью и программирование вообще стало модным.

Лучшие идеи рождаются в благоприятной атмосфере.

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

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

А именно: вежливость, запрет на приказной тон, запрет на обсуждение личных качеств, допустимы только аргументированные комментарии и т.д. В тех командах, где я был тимлидом, я вводил небооьшой code of conduct для code review (еще до того, как это стадо модным). В спорных ситуациях решает большинство.

Так как читабельность кода и прочие штуки — это важно для всей команды, именно команда будет работать с этим кодом в дальнейшем. Кстати, именно большинство, а не тимлид/техлид. А не тот, кто считает себя самым умным.

Эти простые меры существенно улучшили атмосферу в команде.

Потому что в целом время гениев-одиночек проходит. Почему вообще сейчас все заговорили о CoC и teamwork? Поговорил с одним, поговорил с другим — и пол задачи решено. Сплоченная команда за счет синергии решит любую задачу. Soft skills становятся важнее и важнее с каждым днём.

Есть люди, которые никогда не работали в сплоченной команде, и не представляют, какой это кайф.

Да собственно что я тут распинаюсь, иди-ка ты сам на...

S. (P. Никого не хочу оскорбить, это просто шутка ) смайлик в конце последней фразы убрали модераторы.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть