Pull to refresh

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

Reading time 3 min
Views 59K

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


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


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


Цитата 1:


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

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


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


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


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


Цитата 2:


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

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


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


Цитата 3:


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

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


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


Например:


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

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


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


Цитата 4:


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

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


Послесловие


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


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


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


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


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


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


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


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


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


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


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


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


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


Больше полезного можно найти на telegram-канале о разработке "Cross Join", где мы обсуждаем базы данных, языки программирования и всё на свете!

Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+180
Comments 502
Comments Comments 502

Articles