Comments 43
Фу, какая токсичная статья./s
Закидают меня нежные наши писаки, чую, но не сказать глупо.
Чем больше общаюсь с разработчиками тем больше убеждаюсь, что это самые нежные и тонко организованные люди в твоем, username, офисе.
и упаси тебя господь вместо трех звонков и десяти часов обсуждения сказать разработчику «это ерунда, ты не прав, так делать мы не будем, точка».
ребят, иногда нужно работать, а не искать токсичность во всех несогласных. Ну так, вдруг забыли.
Бывают же ситуации, когда тебе именно и не дают просто работать.
В этом и проблема, что "просто работать" не получается. А проблемы менеджмент скидывает на исполнителей.
В примере, который привёл автор статьи, к разработчику обычно ещё приходит менеджер и говорит, что разработчик (pr'ы которого не принимаются и даже не смотрятся) не справляется. Никто не будет искать проблемы в управлении, если можно просто уволить разработчика, а начальству рассказать, что провел оптимизацию.
Как человек самой тонкой и трепетной душевной организации могу передать только короткий трехсимвольный сигнал с координатами по которым можно отправиться менеджеру влезающему в чужую предметную область и лакирующего все соусом "просто сделай как я сказал, просто надо работать". Следом пойдет чувак, который придумал что в его компании менеджеру это можно, или, упаси господь, нужно. Если ты нанял инженера - он инженерит, а не ты. Не можете договориться - привлеки других инженеров, ака "архитектурная сессия" и они либо тебе мозги поставят на место, либо ему. В зависимости от того кто не прав. И вот это вот и называется - просто работать.
А какая разница, сколько времени функционал добирается до релиза? Ты свою работу сделал, merge request создал, сиди и расслабляйся, пока бюрократия там сама себе работает и сама себя задерживает.
Организационные проблемы в компании должны решать менеджеры\тимлиды и прочие люди, наделённые властью, а не новички.
Тут мне кажется зависит от компании и где-то могут сказать твоя задаче и должен довести до конца решая все сопутствующие моменты. А так да лучше вопросы бюрократии перепасовать заинтересованным лицам)
зависит от компании и где-то могут сказать твоя задаче и должен довести до конца решая все сопутствующие моменты
Невыстроенные процессы Йода видит тут.
Это вроде того, как саппорту первой линии говорят: "ну, запроси базу у пользователя, расковыряй ее скулем, найди места, имеющие отношения к ошибке, залейся в дев, протестируй, найди сходное поведение и вот тогда создавай тикет на вторую линию".
Каждый должен делать свое дело.
Технари, одна из самых токсичных сред, у нас на учебе были взаимные проверки и попадались такие душнилы, которые любое малейшее двусмысленную формулировку в задании трактовали не в твою пользу. При этом никакого профита с обнаружения "ошибки" они не имели. Устроить трехчасовую проверку JsonParser-а? Да пожалуйста, попутно спросим все что можно о языке, памяти, командах процессора, стандартах и версиях среды разработки. Ну в целом вы это видите на собеседованиях.
Не то, чтобы гуманитарии много добрее, мне кажется это в целом проблема СНГ, а не программистов, очень низкая симпатия и доверие друг к другу вот и результат.
На позицию ревьюера просто противопоказано ставить кого попало. Обязательно должен быть человек с развитыми софт-скиллами. И конечно, ревьюер по задаче должен быть один.
Если ревьюер толковый и тактичный - то и взаимодействовать с таким нет проблем. Иногда даже есть за что спасибо сказать.
Ревьюер, который еще не прошел через период подросткового самоутверждения - беда для всех.
Да не сказал бы. Все как везде, такие же люди. Причем в разработке это еще на собесе видно - кому просто работать надо, а кому мозги сношать.
цель не в том, чтобы помочь улучшить код, а просто засыпать человека замечаниями и тратить дни на поиски проблемы там, где ее может и не быть.
начались мелкие придирки и постоянные вопросы к реализации.
Под ревью должно закладываться время на полировку решения и обсуждения возможных слабых мест. Вопросы и уточнения - это нормальное явление, систематические ревью без единого коммента - это скорее признак формального отношения ревьюеров. Все, разумеется, должно быть в пределах разумного, если никто нигде серьезно не облажался.
Затягивания другими людьми согласований и прочих подготовительных процедур, необходимых для дальнейшей работы - это повод вкопаться, заблокировав задачу (уведомив ответственных, конечно). А молчаливое выполнения по сырым требованиям - это уже ССЗБ разделение ответственности с тормозящим звеном. Тут и начинается выяснение, кто больше неправ.
Но бывает и обратная ситуация, если там на самом деле в ревью косяк на косяке и такие конфликтные ситуации систематически происходят с разными людьми, то токсиком запросто может оказаться сам рассказчик, который пытается втулить своё любыми правдами и неправдами, обесценивая труд ревьюеров и апеллируя ко времени.
Если под каждое ревью закладывать полировку решение и обсуждение возможных слабых мест, то на это будет уходить значительно больше времени и основная суть ревью будет теряться. Тогда можно сразу начинать с парного программирования и сидеть в вдвоем согласованный код писать.
Есть согласованный стандарт и стиль кода команды, если тебе не нравиться, какая-то вкусовщина, то создавай встречу или выноси на обсуждение в чате или ретроспективе. Есть какие-то слабые места не относящиеся к задаче, заводи задачу на доработку. Просто так можно бесконечно сидеть и полировать под желание каждого человека
Если не доводить до абсурда, то практика код-ревью отлично работает. А если реквесты просто подмахивают не глядя, то это бесполезная процедура, тормозящая мержи.
Есть согласованный стандарт и стиль кода команды
А если нет? Имеющаяся кодобаза может быть разного качества. Новый код может привносить как новые здравые изменения, так и чепуху.
какая-то вкусовщина
Самое растяжимое понятие здесь - эта самая вкусовщина. В идеале достаточно обменяться аргументами и некто обличенный властью должен принимать решение. Это должно происходить достаточно оперативно, без растекания мыслью по древу.
Перестал читать после "не относиться к задаче"
Ревью производиться по коду к задаче, а не по любому коду к проекта.
Видимо комментатор имеет в виду лишний мягкий знак в слове "относиться". (И "производиться" тоже. ;)
Именно! Когда человек не знает когда писать тся и ться, но учит манерам .
Возмутительно!
Манеры и правописание это разные вещи, странно, что тебе это невдомек
Именно! Когда человек не знает когда писать тся и ться, но учит манерам .
Ещё один человек зацикленный на бесполезных правилах)
Мы когда-то боролись с пассивной агрессией в команде и поэтому в конце фраз стали добавлять: “п.дор”, благодаря чему это переходило в активную агрессию, а с ней у нас проблем не было. :)
некоторые пожелания не совпадают с единым стилем кода принятым в цехе разработки
По-хорошему, стиль кода должен автоматически проверяться на пре-коммит хуке, а потом повторно уже пайпланом в репозитории, чтобы не проскочили любители опции -n.
Я триггернулась на картинку, а про сбор средст на всякие др и праздники на работе, а ничего про это не было. А я так хотела пожаловаться, как с нас сдерали по 3к на подарки мужчинам на 23 февраля (((
То есть автор собачился с коллегами, собачился с менеджментом, но виноват в этом не автор, а все окружающие? :-)
Говнюки, тешашие своё ЧСВ НА КОД-РЕВЬЮ ,ЯВЛЕНИЕ ОБЫЧНОЕ.
Очередной крик души про токсичность в айти. И все вроде как понимают, поддерживают. Но вон кто-то сказал, что джава популярнее питона (не лучше, а просто популярнее) - я пошли дизлайки.
Я как-то написал здесь, что книга по кодингу в 700 страниц за 3к дорого. Так кто-то обиделся и на это.
А так да, все против токсичности
Дизлайки - это тоже мнение, почему его не надо уважать и жалобы на них не считаются токсичными?
А зачем его уважать?
Мнение это просто некое свойство человека, например любит человек оливки, а другой нет.
Причём тут уважение?
Затем же, зачем уважать мнение из оригинального комментария, не проявляя токсичности, вроде минусования.
Я знаю что в ТомТоме это возведено в культ, и даже выдают памятные призы "лучшим ревьюверам". Слышал что треды в сотни комментов не редкость.
А недавно столктулся с обратной стороной - когда человек, к любому комменту относиться как к оскорблению матери ... что самое смешное в этой истории - обидчивым он считает меня, хотя я прошел всю школу капитанов, включая описанное в статье и научился спокойно относиться ко всему
Очень странная история... Релиз опоздал на два месяца из-за разборок между программером и каким-то из манагеров.
Где был тимлид?
Почему уже через день после дедлайна не пришёл лесник я про ПМа) и всех не успокоил???
У меня довольно брльшой опыт работы в разных разработческих компаниях, в том числе и очень душных. Но нигде сроки не срывались по таким, кхм, странным причинам.
Куда подевались ваши манеры? Коллеги в IT