Как меня чуть не уволили из-за токсичного поведения и что было дальше

    Началось все с устройства на новую работу. Новый проект казался интересным, коллеги – доброжелательными, так что я с радостью принял оффер. Первое время я только погружался в проект, разбирался с его особенностями и особо ничего не критиковал. Все-таки я тут новичок, ещё не в курсе всей ситуации, и вообще, в чужой монастырь со своим уставом не лезут.

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

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

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

    Фото-реконструкция событий
    Фото-реконструкция событий

    Такой поворот событий был огромным шоком для меня. Первой мыслью было: "ну если вам не нравятся мои старания, то и загнивайте с своем болоте дальше!" Однако, в целом моя работа мне нравилась, поэтому так просто сдаваться не хотелось. И я решил разобраться в ситуации.

    Анализ

    Я попросил своего руководителя привести мне конкретные примеры токсичности в моем поведении. Тут надо отдать должное руководителю, к вопросу он подошёл серьезно и через некоторое время привел мне пару примеров: на митингах я тянул одеяло на себя, не давая другим высказаться нормально, показывал что есть лишь два мнения – моё и неправильное. На код-ревью были ожесточенные дискуссии по тривиальным поводам, и т.д. В общем, со стороны казалось, что со мной абсолютно невозможно ни о чём договориться.

    Характерный пример произошел во время командного обсуждения будущих планов. Почти все время митинга я занял рассказом, что у нас в проекте творится бардак и мы ничего не добьемся, пока этот бардак не исправим. Разговор на том митинге зашел в тупик. После этого руководитель меня спросил, зачем было нужно об этом говорить так долго. Я попытался объяснить ещё раз, что состояние проекта никуда не годится. На что руководитель заметил: "Бардак? А я не вижу никакого бардака, задачи доставляются, остальные коллеги довольны, в чем проблема?". Он предложил мне спокойно в текстовом виде расписать, что именно идет не так и показать цифрами и примерами, почему исправление этого должно стать нашим приоритетом. Такое конструктивное предложение мотивировало меня. Я сел за написание документа – сейчас я им всем покажу! – но в итоге так и не смог привести внятного и весомого аргумента. При переводе в текстовый вид все проблемы оказались маленькими трудностями. Тут-то до меня и дошло – смысла поднимать эту тему на митинге не было вообще никакого, потому что обсуждавшиеся там планы лишь слегка пересекались с нашим техдолгом, и мое внимание к ним просто зря потратило время всех участников.

    В том конкретном случае я признал свою неправоту, но руководитель показал мне ещё примеры. Там было про код-ревью. Я настаивал на своей точке зрения, и никак не соглашался принять другую, потому что там был совсем не поддерживаемый код, как мне казалось. При более детальном рассмотрении оказалось, что предложенная мной оптимизация была преждевременной, по прошествии полугода так и не понадобилась, вся борьба была зря.

    К этому моменту я осознал, что лезть на рожон лучше не стоит, даже при наличии благой цели. Иногда стоит и притормозить.

    Что было дальше

    Тут стало понятно, что нужно как-то выбираться из сложившейся ситуации, только вот неясно, как именно. В этом мне помог счастливый случай. Однажды на очередном код-ревью я заметил, что код можно переписать более оптимально, но помня про прошлые ситуации, у меня не было никакого желания ввязываться в затяжную дискуссию. Поэтому я оставил комментарий: "тут можно было сделать и по-другому, более оптимально, но в целом мне без разницы, могу заапрувить и так". Каково же было мое удивление, когда коллега без лишних пререканий взял и переделал на мою версию!

    А что, так можно было что ли?
    А что, так можно было что ли?

    Я решил попробовать оставлять комментарии в таком же опциональном стиле ещё несколько раз. Это сработало! Оказывается, если не настаивать на своем мнении, то у коллеги не включается чувство противоречия, при котором он защищает свою точку зрения не потому что она лучше, а в качестве естественной защитной реакции.

    Таким образом сложилась стратегия более конструктивных код-ревью. Если текущая версия не содержит каких-то фатальных багов, от которых развалится продакшен, то настаивать на своих комментариях не нужно. Автор кода сам разберется с нужными советами. Если же комментарий всё-таки критичный, то нужно явно показать, что именно сломается если этого не сделать. И пусть автор кода сам разбирается со своими рисками.

    С культурой дискуссий на встречах тоже разобрались. Перевод дискуссии с эмоциональной в письменную форму позволил найти конкретные недостатки и путь их исправления. Здесь очень важную роль играет скорость восприятия. Не все люди могут сразу разобраться в ситуации, о которой они узнали 5 минут назад. Текстовый документ со ссылками позволит им погрузиться в контекст ситуации и предложить свои решения. Главное здесь не давить и не требовать немедленного ответа. Из-за давления так же есть шанс получить режим противоречия.

    Выводы

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

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 247

      +46

      Статья прекрасна. Именно такое code review здорового человека. Главное - польза, а не вкусовщина. А еще бывает review в духе: "надо сделать так, потому что иначе не будет слито, ибо я так сказал".

        +40

        Справедливости ради, сказать "надо сделать так, потому что иначе не будет слито, ибо я так сказал" – это законное право мейнтейнера проекта, поскольку именно он отвечает за то, чтобы проект не развалился на части.

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

          –1

          Может я что-то не понимаю, но я примеров code review не увидел.

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

            +8
            Нет никакого смысла сваливаться в частности, потому что проблема от начала и до конца субъективна. «Токсичность» — модный термин, который значит что угодно и не значит ничего (кроме того, что одному человеку или нескольким людям не нравится поведение третьего лица).
              0

              Хорошая статья как не стоит и как стоит вести себя на ревью, с примерами: https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like

            +13
            У меня есть опыт коллеги токсичного код-ревьювера. Человек каждое утро в 4 или 5 по МСК проверял все коммиты членов команды и комментировал каждый участок, иногда советовал откровенную чушь и сильно обижался, если его не воспринимали всерьез.
            Утро разработчиков начиналось с текстовых баталий. По итогу конфликты привели к развалу команды.
              +19

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

              А так да, бывает, что мы очень увлекаемся чем-то и перестаем видеть окружающий мир, автор большой молодец, что не ушёл, а решил разобраться.

                +10

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

                +52

                Бывает и обратная ситуация.

                Слишком низкая "токсичность", отторгает измения и приводит к консервации команды работая как отрицательный отбор. В итоге получается команда в которой каждый хвалит соседа, при этом все сидят ту уже 5 и более лет, любой сильный сотрудник из команды очень быстро вымывается, и остаться только "лояльные" которые как специалисты на рынке не восстребованы. Проект при этом движется крайне медленно и представляет из себя сплошной технический долг.

                  +2
                  Да, это тоже бывает. Золотая середина Code Review где-то посередине, чтобы не упарываться в принципиальность, опираясь на благоразумие и целесообразность.
                    +7

                    Чтобы такого не происходило, нужно выстраивать культуру задавания вопросов. Если на очередной вопрос "почему мы не делаем X, ведь так же будет лучше?" получаешь ответ "не до этого сейчас, работать надо", то через пару попыток желание задававать вопросы и предлагать улучшения пропадает.

                      +4
                      Что бы такого не происходило — нужны документы. Вот как ни странно. Всегда работает.
                      Когда то сам боролся с этим всем, но у всех некое «своё» видение «всего». Однако же если конкретизировать цели не абстракциями а цифрами и прилепить сверху печать — то работает оно железобетонно.
                      Например из недавнего. Прекрасный новонанятый кодер кое что сделал действительно очень хорошо. Однако же полезши в бд он же сделал сие очень плохо. И для него нет разницы, он применил практически один и тот же подход в этих двух местах. И его как раз таки не долго бодали за это. Потому что есть документы. В первом случае скорость не критична и так и написано на бумашке. А во втором случае нужна скорость 10млн строк минимум и так и написано на другой бумашке. Всякие споры тут же и прекратились. Человек мгновенно понял и переделал совершенно в другом стиле. «Силу» подписи и печати не стоит недооценивать.
                        0
                        вот бы еще пример такой бумажки
                          0
                          вот бы еще пример такой бумажки
                          Вы это серьёзно? :) Коммерческим кодом вряд ли делятся. Ну или делятся, но за большие деньги.
                          А причём здесь код когда суть про бумашку — спросите вы. А притом — отвечу я.

                          Ну ладно. Как обычно на пальцах. Что есть производственный процесс? Это некоторые люди осуществляющие деятельность. По сути они работают по программе. Т.е. это и есть программа. Программа исполняется в треде. Тредов больше чем один. Они конкурируют, блочат друг друга, выкидывают ексепшены. Суть менеджмента — это высокоуровневый диспетчер для обработки очередей, блокировок, эксепшенов и т.д. Так получается что менеджмент — это тоже программа? Ну конечно. Только высокоуровневая. Ни в коем случае не нужно понимать высокий уровень как нечто возвышенное, суть вовсе не в этом. Высокий уровень — это более абстрактные абстракции, не более того. Так вот я про то, что всё есть программа. Вот так и получается предприятие. Вопрос в том, как и кто пишет программу или уже написал. И в каком стиле. И ещё более существенный вопрос — а эта программа вообще написана? А если написана — сколько в ней ошибок, необрабатываемых исключений, каков процент простоя тредов и т.д. и т.п. Улавливаете мысль ага? :) Если не улавливаете — вы не программист. И делать вам в менеджменте нечего. Для директоров и прочих руководителей сообщу наистрашнейшую истину. Увольте за забор всех тех кто не является программистом. Это бесполезные существа. Увольте себя если вы не программист. Вы — бесполезное существо. Ну потому что исходя их того что написано выше — всё есть программа. Но пишут это ПО только программисты. Иначе никак. Иначе ваша Машенька с философским образованием и лучший друг Петька зам. с рыбного ПТУ вам всё и всегда будут пороть. Потому что они не программисты. Т.е. существа исключительно бесполезные.

                          А вот теперь вернёмся к бумашкам. Что есть бумашка в данном случае? А это формализованная обработка ексепшена на тред. Всего навсего. Но вы меня извините, я ещё раз напишу — коммерческим кодом вряд ли делятся. Так что примеров бумажек не будет.

                          А теперь подумайте хотя бы раз, джентльмены. Особенно из так называемого менеджмента. Какова ваша функция? И исполняете ли вы её? А вот сильно вряд ли. Более того, вы даже не понимаете зачем вы есть. Господа программисты, и вам просьба не обижаться. Теперь вы понимаете чем является вменяемый менеджмент. Это ваш верный друг и помошник. Потому что менеджмент за вас разгребает ваши ексепшены и прочие косяки лезущие из вашего треда.

                          Все прочие завихрения от каких то там экономистов юристов дизайнеров психологов и прочих дегенератов — значения не имеют. Вообще никакого. Единственное зачем нужны эти люди — они реализуют нужный интерфейс. Однако же на абстрактное ПО в целом — они совершенно не влияют.

                          Так вот я про что. А я про то, что пока нет программиста и программы — а нефиг мутить предприятие. Это заведомо 100% фейл. Чудес не бывает и никогда не будет. Такие дела.

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

                            Да ладно, ещё как делятся, бесплатно.

                            Если не улавливаете — вы не программист

                            Увольте за забор всех тех кто не является программистом. Это бесполезные существа. Увольте себя если вы не программист. Вы — бесполезное существо

                            Потому что они не программисты. Т.е. существа исключительно бесполезные.

                            экономистов юристов дизайнеров психологов и прочих дегенератов

                            Зачем же вот так лихо вешать ярлыки, и откуда столько ненависити к «непрограммистам»?
                              0
                              Да ладно, ещё как делятся, бесплатно.


                              То есть коммерческим кодом кто-то там где-то там чуть-чуть поделился, не означает «еще как деляться». Вот когда процент коммерческого кода, попавшего в outsource будет хотя бы 25%, тогда можно будет говорить об «еще как делятся». А сейчас это в основном исключение из практики.
                                0
                                «ещё как» означало — такое встречается очень часто.

                                Но если нужны примеры, где отдали 100%, без проблем. Вообще, есть куча проектов, которые изначально были открытыми, например Godot. А есть ещё Defold, который был изначально закрытым, а потом им поделились на 100%, отдав в опенсорс.

                                Есть и намного более популярные примеры, возможно вы слышали о них: Linux, Docker, Postgres, Golang и др.
                                  0
                                  «ещё как» означало — такое встречается очень часто.

                                  "очень часто" — это сколько? 90% всего существующего коммерческого кода?80%? 50% хотя бы?

                                    0
                                    90% всего существующего коммерческого кода?80%? 50% хотя бы?

                                    Ого какой сложный вопрос, а как же я это узнаю? Нужно обязательно в процентах? А зачем?

                                    Я напомню, что изначально я ответил на фразу — «коммерческим кодом вряд ли делятся». Я показал, что делятся и привел примеры. При чем, это не парочка безымянных и малополезных проектов — их много, и среди них есть очень популярные.
                            0

                            Погуглите RFC (Requests For Comments). Во многих популярных проектах они есть, вот тут есть примеры: https://github.com/search?q=rfcs

                              0
                              В коменте выше шла речь о бумаге с печатью, вот и стало интересно, что это за бумага может быть с т.зр. ТК и как это реально (нереально) оформить в системе локальных актов предприятия.
                        0
                        Если есть админресурс, то так можно ехать бесконечно. Пилите, они золотые: )
                          0
                          Это просто классическая ситуация в бюджетке РФ, в добавок ситуацию усугубляет «веселая» ЗП.
                            0
                            Эта ситуация характерна для любой низко конкурентной среды или среды в которых критерия отбора( критерии конкуренции ) слабо коррелированных с предполагаемым результатом. Например компании нужна CRM, но премию получает самый лояльный сотрудник. Конкуренция есть, но не в области разработки CRM, а в области демонстрации лояльности.
                            Повышение дружественности среды требует введения дополнительных мероприятии для сохранения ее конкуренции, это не простая задача.
                          +8

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

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

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

                            0
                            Вот так лучше:
                            Самое главное правило при внедрении код-ревью в командах: поручать код-ревью только тем, кто хорошо их делает.

                            Нет, не так:
                            Cамое главное правило при внедрении X: X должны делать только те, кто хорошо умеет делать X.
                            +33
                            Ошибка в терминологии. Автор не токсичный (тот, кто отравляет жизнь), а душный (тот, кто мешает дышать полной грудью). Душнил и зануд не любят, но достаточно долго терпят, да и эффективность коллектива они не снижают. Её снижают токсики. Они же создают настоящие конфликты, плетут заговоры и натурально выживают коллег с работы.
                              +16
                              Иногда (довольно часто, на самом деле) назвать человека душным это предпоследний аргумент перед тем как сказать «ойвсё» если по существу возразить нечего, но и согласиться с тем что «душный» прав по всем статьям (и признать себя не правым) человек не готов. А «душный» не готов утереться и сдать назад. Я даже не про код сейчас а про вообще в целом.
                                +2
                                Смотрите тут какое дело. Человек может быть на 100% прав, однако если из-за его манеры подачи своего мнения, он останется единственным членом команды, то проект всё равно в срок никак сдать не получится. И скорее всего ни в какие разумные сроки. И это ещё если человек согласится работать за всех, а не выгорит в таком режиме работы и не сольётся сам через какое-то время (а проект с нулём разработчиков уже точно не будет закончен никогда).

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

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

                                Так что часто выгоднее выбирать решение, которые поддерживают большинство членов команды, а не которое правильное с точки зрения одного члена команды, но ему никто не верит — как минимум даже если решение окажется не очень хорошим, будет больше рук, готовых его поддерживать/переписывать. Исключение может быть разве что в каких-нибудь граничных случаях типа «один разработчик рок-звезда из Google, а вся остальная команда — студенты первокурсники», но обычно реальные отличия в уровнях подготовки не настолько сильные, как это видится разработчику, агрессивно продавливающем своё видение правильного решения.
                                  +4
                                  Человек пришел в команду и захотел что-то изменить к лучшему — сразу он становится душным и токсичным, потому как мы сидим в своем болоте и нам хорошо. А этот самозванец только маскировался на собеседовании адекватным, а на самом деле хочет всех нас тут подсидеть и оставить без работы каждый раз доказывая наш непрофессионализм, а продукт вывести на IPO.
                                    +2
                                    эх… прямо с языка снято… хотелось бы добавить частности:
                                    • срок сидения в болоте прямо пропорционален этому нашему «профессионализму»
                                    • … и возьмем мы тебя в это болото, только когда квакать будешь в унисон...
                                      +5

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


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

                                        0
                                        Ну так нам ведь для этого и нужны soft-skills и выработанный подход к решению задач?

                                        Встречают по одежке, провожают по уму — свою мысль нужно донести так чтобы её усвоили, а не просто бросить в воздух и надеяться что сама впитается. Это про команду
                                        А бизнесу надо показать в чем конкретно проблема, автор об этом понял благодаря руководителю. «работает — не трогай» это про то, что «оно, по крайней мере, работает и мы это видим. А ты докажи, что видишь больше». Просто доказать сложнее, чем по верхам собрать инфу и с какими-то бест-практисами лезть все перестраивать непонятно зачем.
                                        0
                                        > то проект всё равно в срок никак сдать не получится
                                        Не обязательно принимать все решения прямо в тот же спринт. Можно их чуть отложить на потом. Редко бывает что-то ну прям совсем срочное

                                        > Да, техдолг и кривые решения удорожают разработку
                                        А потом может возникнуть ситуация, что и в команду новые люди не идут, потому что легаси, и текущие спецы не могут устроиться на новую работу, потому что отстали от жизни

                                        И вообще, в большинстве случаев работодатель нанимает новых людей по опыту. Но зачем, если в итоге этот опыт оказывается ненужен? А пилить код «от забора и до обеда» спокойно может и выпускник курсов
                                          0
                                          Ни один проект не идеален
                                        +1

                                        Не очень понимаю, почему по вашему "душнила" не снижает эффективности работы окружающих, если вы сами пишите, что "не дает дышать полной грудью" (не дает работать в полную силу, как я понимаю)?

                                          0

                                          Потому, что он душит только на совещаниях и разборах, ну, максимум, на кухне, а в остальных ситуациях нормальный парень!

                                          +1
                                          Насколько я понимаю, душный это тот, кто искренне стремится приносить пользу, но не понимает некоторую динамику. Для автора озарение было шоком, но избавление от конфликта принесло всем облегчение и радость.
                                          Токсичному нужен именно конфликт, это основная его деятельность. Избавившись от одной драмы, немедленно создаёт две новых.
                                          +4

                                          Мне нравится вариант - писать фидбэк на код ревью в формате "а почему тут сделано так, а не вот так?". И в качестве ответа ожидается либо переделка на второй вариант (при условии что он действительно лучше), либо аргументация в формате "первый вариант лучше, потому что..." или хотя бы "потому что нет времени переделывать на второй вариант"

                                            +11

                                            "Как написал — так написал, переписывать не хочу".

                                              +6
                                              ну это явная эскалация в силу неконструктивного поведения.
                                                +16

                                                "Вы задерживаете работу, у меня еще 5 историй в этом спринте. Надо было на груминге умничать."

                                                  +7
                                                  Вы прям повторили слова одного колеги, который требовал убрать обязательное прохождение всех линт-тестов в CI, которые сделали обязательными за 2 дня до этого. Хотя конфиг линтера формировали и согласовывали со всеми разработчиками на протяжении 3х месяцев.
                                                    +3

                                                    А вы напомнили мне недавний пост от одного перца в общем чате (без задних мыслей, что страшнее): "А что это за билд такой CI? Он место в очереди занимает. Я удаляю если никто не отпишется щас.". Dunning-Kruger он такой.

                                                      +1
                                                      Имея таких «умников» в штате, специально вынесли все конфиги CI в отдельную репу, в которую могут писать только DevOps'ы и лиды.

                                                      Плюс настроили фейл CI если в проекте есть файлы с "#no-lint" (отключение линтера для конкретного файла). Отключение отдельных правил линтера позволялось, с обоснованием на ревью.
                                                  +2
                                                  Ну так и вопрос на самом деле провокационный)
                                                  Из разряда «Код писал селёдкой пахло?», т.е. он подразумевает, что должно быть написано «вот так», а написано почему-то «так» и это уже ставит написавшего в оборонительное положение. Поэтому и ответ «по кочену» не то чтобы неожиданный.
                                                  Поэтому я обычно предлагаю либо посмотреть похожие куски кода с более коректной реализацией, как пример, либо начинаю немного из далека, чтобы прощупать поток мысли и понять почему так вышло, в большинстве слуаев это просто пробел в знаниях не фундаментальных, а локальных по проекту и не злой умысел или халатность.
                                                  +1
                                                  «Как написал — так написал, переписывать не хочу».

                                                  Это ж классика! «Пилат же написал и надпись, и поставил на кресте. Написано было: Иисус Назорей, Царь Иудейский. Первосвященники же Иудейские сказали Пилату: не пиши: Царь Иудейский, но что Он говорил: Я Царь Иудейский. Пилат отвечал: что я написал, то написал.»
                                                  0
                                                  На мой взгляд «Почему» эмоционально может быть более неприятно чем «Предлагаю».
                                                  Но точно может быть, когда нужно пояснение про какое-то неочевидное решение.
                                                    –3
                                                    «а почему тут сделано так, а не вот так?» — вот этот вопрос в ревью сразу выбешивает, начинать ревью с наезда не продуктивно, так как вопрос — это требование ответа. Более того, ответ очевиден — «мне так придумалось)», а спрашивать очевидные вещи не комильфо, отличный вариант предложить свое решение, а не так как вам нравиться
                                                      +3
                                                      Просто запомнить, легко применять!
                                                      Чтобы определить – писать глагол с -тся или -ться, спросите себя, на какой вопрос отвечает этот глагол – «что делать?» или «что делает?». Если в вопросе есть мягкий знак, значит он есть и в глаголе.
                                                        –1
                                                        Может еще подскажите как редактировать первый комментарий в процессе модерации или после?
                                                          +4
                                                          Что сделаете? Подскажете!
                                                    +4
                                                    Нет, оглянуться на своё поведение и попытаться его проанализировать — это само по себе гуд. Как видно, автор сам понял, что порой красота кода имеет меньший приоритет, чем развитие проекта в целом и в следующий раз придёт более глубокое понимание того, что за свои правки надо не бороться, а просто подыскивать более весомый аргумент, уметь защищать своё мнение так, чтобы у других не оставалось вопросов.
                                                      +19
                                                      Ага видел я таких инициативных. На выходе остаются тонны неподдерживаемого кода, который правильным считает только сам автор.
                                                      Более того часто оказывается, что за счет того что человек использовал все модные паттерны он клал\не думал про общую архитектуру. В итоге несколько раз видел как после пары лет работы таких деятелей все их решения выбрасывались и переписывались с нуля, а сами деятели шли нести добро дальше рассказывая на собеседованиях как они переросли контору\коллег\здравый смысл.
                                                        +14

                                                        Бывает и наоборот. Наняли снежинок с парой лет опыта багфиксов и уверенностью, что опыт и знания "не нужны". Товарищи просто фигачат линейно "from A to B" (=эффективность), злятся когда указывают на ошибки дизайна (они еще не научились делать A-to-B и дизайн одновременно). Злятся еще больше, когда не получается запустить кривульку и проходится переписывать, а времени на анализ опять нет — надо ведь фигачить, чего тут думать.


                                                        Самое веселое — не-программист хрен отличит одно от другого.

                                                          +1
                                                          Это в 90% случаев ошибки менеджмента.
                                                            +1

                                                            Какие именно ошибки? Как чинить будем?

                                                              –22
                                                              Вы видимо реально плохо в разработке разбираетесь с такими рассуждениями.
                                                              Линейный код проще поддерживать и отлаживать.
                                                              Разные сложные решения нужны только в редких случаях. Типовые кейсы реально проще заткнуть чем-то простым вплоть до сайта на тильде вместо разработки мега портала.
                                                              Я допустим пишу на C# и занимаюсь вебразработкой и я не считаю, что должен знать JS. Отсюда все кто считает иначе посылаются далеко и на долго т.к. опыт показывает, что часто все эти гуру ничего кроме своих скриптовых языков не знают и в архитектуре не понимают ровным счетом ничего.
                                                                +28
                                                                Я допустим пишу на C# и занимаюсь вебразработкой и я не считаю, что должен знать JS. Отсюда все кто считает иначе посылаются далеко и на долго.

                                                                Ну тогда я тоже в вашем формате попробую — идите в жопу с вашими советами.
                                                                Получилось? Понравилось?

                                                                  +6
                                                                  Должны. Еще как должны. При знании многих языков переход на новый практически моментален, но вот в каждом языке есть свои особенности, которые сильно влияют на производительность кода, и есть unpredictable behavior, которые полезно знать. В принципе их не всегда понимает большое количество разработчиков пишущих на этом языке, но это не значит, что не надо изучать язык.
                                                                    +2
                                                                    Вы видимо реально плохо в разработке разбираетесь с такими рассуждениями.

                                                                    Двумя постами раньше:
                                                                    Это в 90% случаев ошибки менеджмента.

                                                                    Так это ошибки разработки или менеджмента?
                                                                    0
                                                                    Наняли неквалифицированных сотрудников, получается. Это значит, что вероятно у менджмента не было квалификации для найма и при этом не было осознания свой некомпетентности в этом, чтобы скажем нанять правильного HRа или хотя бы привлечь опытного программиста для проведения собеседований. Или изначально был план нанять новичков за недорого и получить задешево некачественно написанный продукт, тогда ошибки нет.
                                                                    +1
                                                                    Я больше скажу, практически любая проблема — это ошибка менеджмента, потому что менеджмент — это априори те люди, кто принимает решения. И любая проблема — это или вовремя не принятое правильное решение, или принятое неправильное решение или совсем уж внешний фактор (но опять же — если уж ты чем-то управляешь, ты наверное должен пытаться предсказывать внешние факторы и иметь планы на этот счет?)
                                                                    +1

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

                                                                      +1
                                                                      Есть ещё куча промежуточных вариантов. Неэффективные решения нередко не являются блокерами, а просто удорожают разработку и поддержку. И может оказаться, что не так уж и критично, чтобы экономика проекта не сошлась. В свою очередь серьёзные конфликты внутри команды могут парализовать разработку полностью.
                                                                        +1
                                                                        замените удорожают, на удешевляют прямо сейчас
                                                                      +8
                                                                      На выходе остаются тонны неподдерживаемого кода, который правильным считает только сам автор.

                                                                      Стандартная фраза любого программиста, который приходит на проект «Гавнокод какой то, надо всё переписать заново». Особенно это забавно, когда это его же код n лет назад (очевидно, что человек вырос и старое смотрится убого).
                                                                        +4
                                                                        На эту тему даже есть комикс про сову-эффективного менеджера
                                                                        image
                                                                          0
                                                                          У меня была в точности почти до слова такая ситуация. Мой сын написал мне довольно большой код (ядро управления станком с ЧПУ под QNX), через несколько лет надо было его серьезно дополнить. Он сказал почти в точности эту фразу «Гавнокод какой то, надо всё переписать заново, какой… это писал!» Одно из самых незабываемых моих впечатлений это было изменение выражения его лица, когда он вспомнил кто его писал.
                                                                        +1

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


                                                                        Если слишком много проблем с качеством на этапе ревью, не означает ли это, что надо просто начать уделить немного больше внимания проектированию и синхронизации команды (чтобы делали в одном ключе)?

                                                                          +2

                                                                          В основном были споры вокруг потенциальной поддерживаемости кода. Например, сделать код в общем виде, или оставить так, и потом зарефакторить. Шансы на то что это пригодится в будущем 50/50, поэтому возникали баталии

                                                                            +2
                                                                            «Взрослые люди редко обижаются на объективную критику» — смотря в каком стиле эта самая критика им высказывается. Мой руководитель на прошлой работе высказывал критику в агрессивно-начальственном тоне и обижались на нее все 100% сотрудников
                                                                              0
                                                                              Оказывался в сходной ситуации: в лицо улыбаются, а потом я узнал, какие слухи обо мне ходят. Взрослые люди, чего в лицо не сказать?..
                                                                                +1
                                                                                Взрослые люди редко обижаются на объективную критику.
                                                                                Взрослые люди редко спорят с объективной критикой. И многие этим пользуются. Мол, ну и что что я тебя криворуким назвал, объективно же, терпи))).
                                                                                  +6
                                                                                  Взрослые люди редко обижаются на объективную критику.


                                                                                  Ложное утверждения. Значительно число взрослых людей, я бы сказал подавляющее большинство, но исследований не проводил, по этому значительное число, не способны воспринимать даже самую объективную критику.
                                                                                  Завернуть критику так, чтобы она была воспринята, это искусство по сложнее разработки, так же как воспринять адекватно любую форму критики.
                                                                                    0
                                                                                    А ещё взрослые люди часто видят, что критика необъективна. Однако критики зачастую формальную логику воспринимают как словосочетание, да и предметом не владеют, хотя критиковать готовы.
                                                                                    0
                                                                                    Взрослые люди редко обижаются на объективную критику.

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

                                                                                    –23
                                                                                    Не согласен с автором, что надо прогибаться. Это не токсичность. Если вы считаете, что правы и это пойдет на пользу, идите до конца. Иначе скатитесь в итоге к пассивной серой массе. Про это есть замечательная книга «Ча́йка по и́мени Джо́натан Ли́вингстон». Выше правильно написал человек «Её снижают токсики. Они же создают настоящие конфликты, плетут заговоры и натурально выживают коллег с работы.». Вам просто не безразлично будущее проекта. Большая часть людей просто не хочет развиваться, и у них профессиональное выгорание, они приходят на работу не с икринкой глазах, развиваться, решать проблемы и получать от этого удовольствие, а просиживать попу и получить за это деньги, написали тяпляп, работает и ладно. В дали от крупных городов довольно сложно найти грамотных программистов, не говоря про знание безовых алгоритмов. Руководитель в статье относится к пассивному типу и впринципе понимает, что найти нормальных разработчиков сложно, поэтому вас просто сделали КОЗЛОМ-ОТПУЩЕНИЯ! И самое главное вам внушили, что вы были не правы. Вы согласились с этим, и все довольны… У меня была подобная ситуация, были так называемые «старички на работе» которые ничего не делали, плюс одни специалисты вечно сваливали проблемы на других, и так бесконечное перекладывание ответственности. Предлагал своему руководителю работать на опережение, добавить мониторинг оборудования и кучу всего полезного, основываясь на опыте прошлой работы, разделить нормально обязательства специалистов, установить сроки решения и ответственных, чтобы не было такого безобразия. Руководитель ничего не делал. Токсичность идет как раз от пассивных людей! В итоге мне это все настолько надоело, что все работает через одно место и на работе саботаж, что пошел непосредственно к директору, благо до этого с ним пересекались по работе, и он заметил меня как специалиста, изложил ему все проблемы и что руководитель ничего не решает, и работает по принципу сломается исправим, что не хочет развивать и улучшать ничего, и если ничего не решится мне придется уйти от них, в итоге директор согласился с моими доводами, бездельников уволили, руководитель получил выговор, коллеги по началу хряхтели и обижались, но уже через пару месяцев решилась большая груда проблем, и количество работы значительно уменьшилось, и в итоге коллеги меня зауважали и начали прислушиваться, а директор мне выписал премию, выдали в грамоту и занесли в трудовую, что получил награду за решением проблем компании. В принципе в нормальных компаниях это все должно было решаться до вас, и должно быть обучение специалистов в корпоративном университете, и должны быть описаны частые проблемы. Но у вас работает принцип какое руководство такие сотрудники… Мне известные случаи, когда такие сотрудники компании топили ко дну, в одной из таких работал, но быстро ушел, понял, что не мое и с этими людьми мне не по пути.
                                                                                      +18
                                                                                      Отличие руководителя от простого сотрудника заключается в том, что он смотрит чуть выше «чистоты кода».
                                                                                      Вероятно, можно было бы сделать чище, но это проект уже с определенным легаси. Это нужно перераспределять ресурсы команды, тратить время и деньги компании. Чтобы… чтобы что?
                                                                                      Насколько это обосновано для проекта? Что скажут стейкхолдеры? Может быть не самое изящное решение, но сейчас, важнее для компании, чем идеально вылизанный код, но когда-то потом.

                                                                                      Попробуйте мыслить чуть глобальнее в рамках компании, тогда многое станет понятнее.
                                                                                        –2
                                                                                        Так как раз смотрю глобальнее. Разве может быть в ж*пе все хорошо, когда постоянно звонят клиенты на дню и сильно ругаются? Как раз решения многих проблем там были с 0 сложностью и практически нулевыми затратами. И как раз мне там удалось снизить значительно затраты на многие вещи и повысить эффективность. Тут только говорит о руководителе одно, ни что он смотрит чуть выше, а то, что он в принципе не уверен в команде и в своих силах. Руководитель должен быть всегда примером, с которым не страшно пойти в бой, и подбирать команду грамотно, создать условия для работы хороших специалистов, в итоге в офисе никаких удобств, зарплаты не высокие и понаберут незнай кого, а потом удивляются почему все так плохо))
                                                                                          +3

                                                                                          А вы зачем пошли туда где в офисе удобств никаких (ну улице что ли?...) и зарплаты невысокие? Для поднятия самооценки?

                                                                                            0
                                                                                            Думаете где-то в глубинке есть из чего выбирать?
                                                                                              +5

                                                                                              Я думаю понятие "глубинка" для IT это не та история)

                                                                                                0

                                                                                                Я не знаю. Однако, периодически работаю с коллегами из разных городов, слава удаленке.

                                                                                                  –1
                                                                                                  На удаленке где-то с конца 2000-х. Описаное мной происходило в середине 2000-х.
                                                                                                    0

                                                                                                    Было бы неплохо это указать в комментарии, кстати.

                                                                                                    А по теме - мой опыт общения с такими людьми говорит о том что они все же верно названы токсичными и ничего хорошего в проект не привносят. Если это не про вас - отлично.

                                                                                                      +2
                                                                                                      Мой опыт показывает, что много где не принято вообще говорить про проблемы. Даже если офис синим пламенем будет гореть, народ будет молчать, многие просто боятся осуждения со стороны руководства и колег. По мне лично надо приветствовать любые пожелания по улучшениям и в любой форме, чтобы не копить недовольство, рассматривать их на митапах, и развивать именно активную позицию — «Знаешь как улучшить работу! Скажи!». Недовольство будет всегда по началу и от него никуда не уйти! Про это есть не плохая книга «Dream Team. Как создать команду мечты»
                                                                                                        0

                                                                                                        Тут вероятно проблема в том, что мой опыт он только про Петербург - какой смысл сидеть и молчать про проблему, когда можно пойти в другое место - все же их достаточно. Не, я слышал про "умиральные ямы", но сам с такой (вроде) не сталкивался.

                                                                                              +16
                                                                                              В статье ничего не было о постоянно звонящих клиентах.

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

                                                                                              Руководитель должен быть всегда примером, с которым не страшно пойти в бой

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

                                                                                              Не надо ваш личный опыт проецировать на все проекты.
                                                                                                0
                                                                                                Вы не поняли, был описан мой опыт, как не грамотные руководители губят процессы внутри компании. Не надо проецировать ваш опыт на мой, и додумывать непонятно что, это был лишь пример. И все описанное мной было ИМХО, что нет токсичности в поведении разработчика, что он что-то хочет улучшить. У людей всегда будут барьеры к новому, и как обычно они были пройдены, но тут не заслуга руководителя, а заслуга времени, некоторым людям нужно время, чтобы понять, осознать, что они что-то не то делают и понять в чем плюсы того или иного решения. Условный пример, вы заказали такси, а вас таксист начинает возить непонятным путем, который вы не знаете и говорит, что так лучше, быстрее, в итоге завозит вас в непонятные дворы, вы начинаете с ним ругаться куда же он вас завез, через пару минут такси выезжает из дворов и проезжает еще чуть-чуть и вы на месте, и понимаете, что таксист был прав, и что вы устроили истерику на ровном месте и не поверили более опытному таксисту. И кстати вы не считаете, что вы себя ведет досточно токсично и даже не даете при этом ответить собеседнику и начали его обвинять? Не это ли токсичное поведение? Где же обратная связь высокого уровня и где грамотный руководитель про которого вы пишете? ))
                                                                                              +4
                                                                                              А вот еще забыл написать. Был в той компании один чудной типок, так вот он каждый день уходил с офиса под предлогом, что его ждет наш клиент для решения проблемы. И еще призрительно говорил, что он давно работает и пусть салаги решают проблемы. По должности был выше его, но он так относился не только ко мне, а так же к другим специалистам выше по должности. Не напоминает вам дедовщину? По факту, у того клиента была сотрудница, которая с утра звонила к нам, и этот типок срывался с работы к ним и ошивался у ней. В ходе корпоративного расследования, почему все так часто ломается у клиента, выяснилось, что у них роман, и никакие проблемы он решает и у клиента проблем нет! Он же был первый на увольнение…
                                                                                                +1
                                                                                                У одного из самых странных чуваков, с которыми приходилось работать — были даже фейковые ключи от машины. Проходишь мимо — на экране открыта IDE, на столе лежит бейсболка, очки, ключи — впечатление что человек отошел на пару минут. А по факту он в обед куда-то выдвигался и появлялся обратно только к концу рабочего дня. Проработал у нас месяца четыре, успешно дуя своему начальству в уши о разворачивающихся перспективах — и слинял как только начальство начало о чем-то догадываться…
                                                                                                  +2
                                                                                                  Это был ненастоящий прохиндей, настоящие по 30 лет в конторах так ошиваются.
                                                                                              +1

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

                                                                                                0
                                                                                                Даже если вежливо будете указывать людям на ошибки и даже говорить при этом про то, что они сделали хорошо(так же учат делать обратную связь высокого уровня?), то не редко они будут считать, что вы придираетесь…
                                                                                                  +3

                                                                                                  Я не знаю, где такому учат, но знаю, что если написать, что я не буду аппрувить твой говнокод, то 100% я буду токсичен. А если напишу, что тут эта фигня приведет к такой то проблеме или тут можно сделать лучше вот так, то процент гораздо ниже

                                                                                                    –1
                                                                                                    Даже второй вариант не всегда пройдет. В первое случае такого принципе никогда не видел на code review. Есть вещи похуже не этичного критики кода, называется Звездная болезнь крупного проекта, когда есть крупный проект, который случайно выстрелил и стал популярным, и главный разработчик не видит проблем кода и проекта.
                                                                                                +4

                                                                                                "Чайка" — хорошая сказка.
                                                                                                Да, искушение представлять себя Д'Артаньяном Чайкой велико! Но проблема в том, что идеалистическо-романтическая парадигма вдребезги разбивается о реальный мир. Ну, потому что несовместима с его законами.


                                                                                                Почитайте "Затворник и Шестипалый". Это тоже сказка, но гораздо более жизненная.

                                                                                                  0
                                                                                                  В принципе в Чайке все жизненно. И 4я часть(которая в изначальном варианте не была опубликована) показывается хорошо, что кроме реальных людей раздвигающих границы и достигающих реальные цели, есть люди которые маскируются под них и наоборот занимаются псевдо просветительством и прафанацией.
                                                                                                +5
                                                                                                Еще большая ошибка такого товарища назначить руководителем команды. Команда рассыпается в течении кратчайшего времени, а затем сваливает и сам «спорщик».
                                                                                                  –1
                                                                                                  Это вполне естественно. Пассивным людям не дают пассивничить на работе. С нормальными специалистами всегда конструктивный диалог, и они прислушиваются к коллегам. Благо до подобных пассивных компаний, у меня был опыт работы с реальными специалистами с большой буквы, и даже споры с ними всегда проходили в позитивном ключе.
                                                                                                    +1
                                                                                                    Специалист может быть «пассивен» в спорах, но очень активен в работах. И не разделять точку зрения новоявленного протестанта, с его «идеями фикс». Спор с выскочкой может быть элементарно ниже профессиональных интересов остальных участников команды.

                                                                                                    Поэтому помимо насаждателя своей точки зрения. надо еще и проводить анонимное тестирования команды на предмет совместимости в коллективе.
                                                                                                      +5
                                                                                                      У любого проекта есть экономика. Сколько денег он может принести. И, внезапно, пользователи обычно не копаются в коде, а видят исключительно фасад «кнопку нажал и стало хорошо или не стало». При этом одного и то же «стало хорошо» может быть реализовано и идеально выверенным красивым кодом и лапшей говнокода. Просто во втором случае разработчиков потребуется больше и им чаще придётся отправлять проект на доработку. С другой стороны вторые разработчики будут дешевле. Успешно держатся на плаву и фирмы, нанимающие исключительно 300кк/нсек сеньоров, и фирмы, набирающие индусов и студентов. Просто там разные подходы к менеджменту и т. д. (и нет, менеджментить первый тип фирм не проще — надо очень тщательно относиться к найму, потому что найти замену в случае ошибки будет очень сложно) И если вы считаете, что достойны первого варианта, то, возможно, вам просто нужно идти в такие фирмы, а не пытаться переделать вторую фирму в первую? А то велик риск, что получится что-то среднее и гораздо менее жизнеспособное. Даже если конкретно вам повезло, это может быть ошибкой выжившего.

                                                                                                      А ещё у людей очень разные темпераменты. Можно иметь очень большой опыт и знания, но не желать портить себе настроение каждодневными агрессивными спорами.
                                                                                                        +1
                                                                                                        Про экономику можно писать много, но у меня есть чем вам ответить на реальном опыте.
                                                                                                        Работал в неплохой компании, все отличные специалисты были, зарплаты были не высокие, хороший начальник, главное грамотный, который понимал как решать проблемы, команда работала сплочено, да и как человек просто золото, не конфликтный. Бывали споры, но все проходило в позитивном ключе. Был еще второй начальник — друг хозяина компании. Эти два начальника руководили проектами и развивали их. Хозяйин был неадекват, у него было 7 пятниц на неделю, к примеру согласовываешь проект, сдаешь что сделал за пару месяцев, а тебе в ответ все не так, переделывай, а до дедлайна осталась неделя. Или была девочка она перевыполнила план продаж за месяц в 5 раз по сравнению с другими специалистами, и ее лишили премии. Через пару месяцев она уволилась. В какой-то момент первого начальника руководство обидело, и основные специалисты вместе с этим начальником разошлись в дальнейшей стратегии развития, в итоге он ушел, а за ним еще несколько человек основной команды включая меня. В итоге, вскоре компания поплыла ко дну с другом хозяина начальником, а потом их за бесценок поглотила крупная компания, но прошло много лет, поглотившая компания сменила руководство и специалистов, повысила зарплаты, но так и не разгребла все проблемы… Важнее не экономика, а команда, если команда плохая и пассивная, то принципе ничего уже не поможет… В первую очередь все зависит от руководителя, и от комфортных условий для развития персонала, а если само руководство пассивное, то такие же сотрудники. Опросники показывают, что для людей более важны комфортные условия, чем зарплата. И люди предпочтут работу где комфортные условия, есть все для развития и ниже зарплата, чем ту в которой выше зарплаты и пассивные сотрудники. Это вам про экономику и содержание отдела.
                                                                                                          +2
                                                                                                          Вы только что описали токсичное поведение, которое и привело к разбеганию команды. Разработчик, пусть даже очень квалифицированный, но с позицией «вы все идиоты, а я гений» точно также приведёт к падению эффективности команды вплоть до отрицательных значений. Только в отличии от руководителя бизнеса, такого разработчика может попытаться образумить начальник или удалить его из команды, если не получится.
                                                                                                            0
                                                                                                            «вы все идиоты, а я гений» — никогда не видел таких, потролить могут, но это другое. Мне лично попадалось именно большое количество пассивно токсичных команд и людей чем: «вы все идиоты, а я гений».
                                                                                                              0

                                                                                                              А я вот встречал таких. Возможно, они и не считали себя гениями, но манера общения у них была именно такая.

                                                                                                    +17
                                                                                                    Люди стали настолько «овощными», что отстаивание своей точки зрения уже считается чем-то зазорным.
                                                                                                    А вот руководитель оказался очень даже профессиональным, потому что смог не просто указать на ошибки, а заставить автора самого понять, где он не прав.
                                                                                                      +7

                                                                                                      Раньше было лучше (с)

                                                                                                      Проблема была не в отстаивании своей точки зрения, а спам этой точкой и непринятие альтернатив, кмк.

                                                                                                        0
                                                                                                        Если суммировать — люди настолько привыкли к спаму, что начинают его тупо игнорить на любом уровне и в любых областях. ;)
                                                                                                      +14
                                                                                                      Мне приходилось работать над проектами, которые с точки зрения разработчика были ужасны. Причём не в том смысле, что там не использовались последние модные веяния, а реально — неподдерживаемая архитектура, генерирующая поток проблем с продакшна, работа над которыми занимала 80% времени команды.

                                                                                                      Но нужно понимать, что с точки зрения бизнес-менеджмента то, что кажется адом разработчику, может быть приемлемой ситуацией: система в целом работает, затраты на поддержку в пределах бюджета, количество серьёзных жалоб от клиентов в норме. То, что где-то там внизу разработчики волками воют, менеджера не будет беспокоить до тех пор, пока не начнут увольняться.
                                                                                                        +2

                                                                                                        Даже после увольнений могут закрывать глаза, нанимая новых "разгребателей"

                                                                                                          0
                                                                                                          И это тоже может считаться приемлемой ситуацией. Правда, не всегда. Когда я как-то ушёл из проекта с очень высоким порогом входа, последнего оставшеося сениора тут же повысили :-)
                                                                                                        –2

                                                                                                        Надеюсь, на момент этого случая вам было лет 25, не больше.

                                                                                                          +22
                                                                                                          Текст статьи идеально подходит под картинку.

                                                                                                          Сижу тут с вами в свинарнике

                                                                                                            +6

                                                                                                            За старания лайк, но с картинкой я не согласен, все было не так

                                                                                                              +2
                                                                                                              это профдеформация. Люди проецируют на свой опыт. Я вот много встречал неконструктива на review, где люди вместо продвижения по проекту занимаются срачем в духе выше.
                                                                                                                +1
                                                                                                                Вы работали когда-нибудь с крупными открытыми проектами типа linux kernel?
                                                                                                                В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
                                                                                                                  +8

                                                                                                                  Я работаю над apache cloudstack. Смотрите в моих статьях. И что? Культура review в oss куда дипломатичнее, потому что волонтеры, в отличие от нанятых за деньги, куда быстрее ногами голосуют. А вы работали?

                                                                                                                    –1
                                                                                                                    Конечно. Выше же написал
                                                                                                                    Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам.
                                                                                                                      +6

                                                                                                                      Ну как-то это не звучит "я работал над крупным... и мои mr отклоняли...". Может быть вы херню писали вот и отклоняли. Мы этого не знаем. Мой опыт говорит, что review в oss, поскольку русских там мало, очень нежный и компромиссный. А что насчет линтера, хидеров лицензий - это просто дисциплина на уровне нет разгильдяйству и не создадим юридического прецедента.

                                                                                                                        –1
                                                                                                                        Бывает такое, что функционал который вы добавили, разработчик может посчитать не нужным, а вам решает каждодневные задачи. Или вы сделали рефакторинг для лучшего чтения кода, а разработчику это не понравилось по каким-то личным соображениям. Бывало всякое. Бывало и такое, что написал функцию для решения одной задачи вместо подгрузки тяжелой библиотеки, как зависимость и отвязать кода от сторонних библиотек, не пропустили. В довольно крупных проектах с грамотными майнтейнерами довольно все адекватно бывает и где решения принимают несколько разработчиков. Linux Kernel code review не просто так привел, не редко его считают очень токсичным, и раньше целые форумы люди расписывали про токсичность Линуса Торвальдса и что он не пропускает полезные патчи, заставляет лучше тестировать код перед отправкой.
                                                                                                                          +1

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

                                                                                                                            0

                                                                                                                            Ну так дайте ссылку на https://lore.kernel.org/ с архивом предложенных патчей, если вы считаете, что мантэйнер был сильно не прав.

                                                                                                              –16
                                                                                                              * Пришел в команду слабее своего уровня, с неадекватным амебным руководством
                                                                                                              * Попытался исправить, помочь, направить, улучшить код
                                                                                                              * Встретил сопротивление амебных некомпетентных исполнителей
                                                                                                              * Не выдержал сопротивления, испугался, убежал поджав хвост
                                                                                                              * Стал как все амебным некомпетентным исполнителем

                                                                                                              Единственная причина, почему это произошло автор отец-одиночка с 2 детьми инвалидами на иждевении в ипотечной квартире. Других причин работать там не вижу. Через 3 года еле еле на джуна устроишься.
                                                                                                                +9
                                                                                                                Одна я в белом пальто стою красивая.
                                                                                                                –2
                                                                                                                Сеньйора из глубинки даже на должность джуниора могут не принять в компанию типа яндекса… Мне попадались такие сеньйоры…
                                                                                                                  +5
                                                                                                                  Если так будет продолжаться и дальше, то им придется со мной расстаться.

                                                                                                                  Такой поворот событий был огромным шоком для меня

                                                                                                                  image

                                                                                                                  У автора все закончилось нормально, но есть ситуации и хуже, когда не предупреждают, а сразу говорят «пиши по собственному». И критика не на уровне «тут можно написать немного лучше», а «вы совсем головой ударились, разрабатывать бек одновременно на двух фреймворках?! (и речь не о разных микросервисах, написанных на разных фреймворках)

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

                                                                                                                  • После получения оффера сказать „мне все нравится, и я готов у вас работать, но дайте возможность взглянуть на код вашего проекта, например по скайп-связи, с расшариванием экрана“. Где можно будет взглянуть на уровень кода, который пишет команда, на тесты, на документацию, на CI/CD и пайплайны, попросить показать ревью (комментарии, обсуждения) мерж-реквестов и т.д.
                                                                                                                  • Иметь запас денег, который в случае кидалова на новой работе (вранье работодателя на собеседовании расцениваю именно как кидалово), позволит легко сказать „досвидос“, и спокойно поискать 2-4 месяца другую хорошую работу.
                                                                                                                    +4
                                                                                                                    В качестве некоторой формализации процесса code review можно вводить определенные теги к комментариям коду. Например: Recommendation, Defect, Code style, Vulnerability и т.д. И далее договориться в команде какие теги являются блокирующими к прохождению ревью, а какие нет. Соответственно, Recommendation может быть опциональным и если автор изменения согласен с замечанием и имеет возможность исправить — исправляет, а может и не исправлять.

                                                                                                                    Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
                                                                                                                      0

                                                                                                                      У меня в нескольких командах не вышло в эти теги. Проекты, правда, не опенсорсные. Всегда есть "владелец" кода, кто принимает окончательное решение.

                                                                                                                      Люди ленятся. Все что не обязательное - можно не делать.

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

                                                                                                                      +4

                                                                                                                      Забыл в каком фантастическом рассказе, но основная линия была в том, что федерация планет заподозрила, что человечество — токсичная цивилизация, и что надо их того.


                                                                                                                      Так вот, у них был офигенный фреймворк принятия таких решений (я себе перенял для борьбы с перфекционизмом). Если чего от себя придумал извините, но мне так больше нравится. Зацените:


                                                                                                                      1. Судью, трансформированного в местного обитателя, посылают на планету, которую надумали exterminate.
                                                                                                                      2. Судья находит подходящего местного обитателя, влюбляется, и живет вместе какое-то время в счастливых отношениях.
                                                                                                                      3. В самый неподходящий момент приходит сигнал, и судья должен принять решение (став сперва полноценной частью цивилизации, которую надо приговорить).
                                                                                                                      4. Если судья решает не нажимать кнопку, он остается на этой планете.

                                                                                                                      Когда во что-то веришь — надо быть готовым идти до конца. Если не готов — надо подумать, а так ли это на самом деле важно (и скорее всего забить).

                                                                                                                        +2
                                                                                                                        Ключевой вопрос: если судья принял положительное решение, то его тоже делают героем, или трансформируют взад? Ну то есть он только теряет любимого человека или же сам тоже того.
                                                                                                                          0

                                                                                                                          Хороший вопрос, надеюсь кто-нибудь отпишется как рассказ называется (я не могу вспомнить как ни старался).

                                                                                                                            0
                                                                                                                            Примерно похожий сюжет — «Серебряные колокольчики» Андрея Красникова
                                                                                                                          +4

                                                                                                                          Но ведь отдельно взятое существо, живущее в отдельно взятом месте может получить радикально разный опыт и сделать из этого разный вывод. Жизнь в гетто не тоже самое, что на рублёвке. Так что "мудрость" пришельцев в данном случае очень сомнительна.

                                                                                                                            0

                                                                                                                            В этом, видимо, и есть их мудрость. Понять жизнь во всем ее разнообразии.

                                                                                                                              +2

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

                                                                                                                                –1

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

                                                                                                                                  +3

                                                                                                                                  Нет, конечно.

                                                                                                                            +7

                                                                                                                            я себе перенял для борьбы с перфекционизмом

                                                                                                                            Судя по тому что я все еще жив, кнопку вы не нажали, и на том вам и вашей избраннице спасибо!

                                                                                                                              0

                                                                                                                              "Антибиотик" Лукьяненко, если не путаю.

                                                                                                                                0
                                                                                                                                Вроде у Лукьяненко был только «Мой папа — антибиотик», про сына космодесантника.
                                                                                                                                А вот очень похожая на сабж история была в рассказе «Мы не рабы» — с тем отличием, что Земля судила колонии, но грозило это в большинстве случаев не экстерминатусом, а серьезными ограничениями.
                                                                                                                                  0

                                                                                                                                  Перечитал "мы не рабы", очень похоже, что это оно и было, просто переплелось в памяти с другими. Спасибо.

                                                                                                                                  0
                                                                                                                                  Антибиотик наводил порядок в бунтующих колониях. Так что именно «Мы не рабы», и не за «токсичность», а за то, что в колониях угнетали и нарушали права части существ (то бишь использовали рабский труд). Ну как в текущем мире санкции в сторону стран, нарушающих международные договоры
                                                                                                                                  0
                                                                                                                                  федерация планет заподозрила, что человечество — токсичная цивилизация, и что надо их того

                                                                                                                                  Эталонное поведение SJW. «А нас-то за что?» (с)
                                                                                                                                    0
                                                                                                                                    аа, это старый рассказ «Есть два стула»
                                                                                                                                    +5

                                                                                                                                    Когда начал читать статью, думал прокомментирую: "Наивный автор, недавно устроился на работу на обычную должность, а ведет себя, как Senior на руководящей позиции."

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

                                                                                                                                    Поэтому было приятно в конце статьи прочитать, как развилась судьба автора в конкретом случае, и в итоге порадоваться за нас всех)

                                                                                                                                      +7
                                                                                                                                      Очень полезная статья для тех, кто «всегда прав»
                                                                                                                                      Автор, спасибо, что поделились этой историей, пойду тоже подумаю, а так ли неправы те, кто называют меня токсичной)
                                                                                                                                        +1
                                                                                                                                        Сложно прийти в слаженный уже коллектив, со своим уставом, так сказать, чтобы все работало и «чистилось» сначала надо в этом коллективе утвердиться и возыметь авторитет, мне кажется, даже высокая должность не спасет, если нет доверия
                                                                                                                                          0

                                                                                                                                          Спасет, если еще более высокая и уже устоявшаяся должность просто перенастроит такой коллектив, указав всем новые правила и кто теперь тут решает. Без этого да — такая высокая должность будет просто как пятая нога.

                                                                                                                                          +12
                                                                                                                                          По мне так автор просто понял, что планку ЧСВ можно и понизить, а лучше и вовсе убрать. К сожаление в IT это большая проблема, слишком много людей с высоким ЧСВ. Учитесь смотреть на себя со стороны. А то получается, вы считаете себя крупным экспертом по технологиям, а со стороны обычный офисный планктон.
                                                                                                                                            +2
                                                                                                                                            Есть такое у айтишников. Нужно понимать, что сейчас не 80-е, и все знать невозможно. Постоянно выходят новые языки, фреймворки, технологии, и у любого специалиста будут пробелы. Плох не тот программист, который что-то не знает, а тот, который не хочет учиться. Вообще огромное ЧСВ свойственно как раз ленивым быдлокодерам. У которых баттхерт от того, что ценят не их с 10-летним опытом на Turbo Vision и MFC, а молодых студентов, знающих Docker, RabbitMQ и прочее «хипстерство».
                                                                                                                                              0

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

                                                                                                                                                +4

                                                                                                                                                Docker, RabbitMQ

                                                                                                                                                Хипстерство

                                                                                                                                                Студент ещё молодой, а уже отстал от жизни

                                                                                                                                                  0
                                                                                                                                                  RabbitMQ это хипстерство? Oh my… у меня для вас плохие новости :)
                                                                                                                                                –7
                                                                                                                                                Токсичность это термин из сленга радикальных феминисток, ЛГБТ & BLM активистов и других SJW маргиналов, которых не следует допускать в приличное общество. Токсичными они называют всех, кто не согласен с их шизоидными идеями. Пожалуйста, не используйте лексику маргиналов, если не хотите быть принятыми за одного из них.

                                                                                                                                                В данном случае речь идет о корпоративном этикете и тактичности. На работе крайне важно поддерживать сплоченность коллектива, поэтому критиковать следует осторожно, не людей, а идеи. Например, «в целом решение приемлемое, но вот это и это я бы сделал иначе, вот смотри...» Обсуждение общего проекта — это сродни научной дискуссии, где мозговым штурмом ищут совместное решение. Умный руководитель обычно в таких ситуациях объясняет ситуацию новичкам, т.к. проблема общеизвестная, у профессиональных программистов (и других интровертов) в целом есть некоторые проблемы по части общения.

                                                                                                                                                Мир open source это не работа, а скорее хобби и субкультура, с неформальной атмосферой. Поэтому там отношение к резким высказываниям более спокойное, поведение Линуса, например, вполне допустимо.
                                                                                                                                                  +10
                                                                                                                                                  Токсичными они называют всех, кто не согласен с их шизоидными идеями.
                                                                                                                                                  Сказал автор коммента «В чем проблема? Я бы пришел и поколотил его. Программистишки обычно трусливы, и с физической формой у них очень плохо.»
                                                                                                                                                  Если кого-то называют токсичным, то, возможно, так оно и есть.
                                                                                                                                                    0
                                                                                                                                                    или солевым.
                                                                                                                                                    Слово «токсичный» появилось как очень меткое и поэтому зашло, но сейчас используют для описания любого негативного проявления. Как и где ни попадя используют понятия «антиппатерн», «синдром Даннинга-Крюгера», «ошибка выжившего», «джун» — даже тут, на хабре. Особенно на хабре.
                                                                                                                                                    0
                                                                                                                                                    Мир open source это не работа, а скорее хобби и субкультура, с неформальной атмосферой. Поэтому там отношение к резким высказываниям более спокойное,
                                                                                                                                                    Да, так было еще лет 15 назад, но с тех пор мир вообще (и опенсорсный в частности) сильно изменились. Мне во FreeBSD приходилось сталкиваться с описываемыми проблемами, и я точно так же пришел к формуле «в целом мне без разницы, могу заапрувить и так». Это бывает непросто, особенно если вас действительно волнует качество какого-то кода, но, в конце концов, это всего лишь код, а ценителей ньюйоркского стиля с его bluntness и honesty нынче довольно немного.
                                                                                                                                                    поведение Линуса, например, вполне допустимо.
                                                                                                                                                    Во-первых, Линусу прощается сильно больше других в силу масштаба фигуры, а во-вторых, даже он посчитал в какой-то момент нужным извиниться и взять тайм-аут, чтобы скорректировать своё поведение.
                                                                                                                                                    +2

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

                                                                                                                                                    Вот тогда только или наверх идти, или валить.

                                                                                                                                                      +9

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

                                                                                                                                                      Типичная ошибка человека, не видящего всей картины. Я тоже такой. :)

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

                                                                                                                                                      Пример из жизни:

                                                                                                                                                      Есть огромный проект с кучей легаси. В коде проекта полным-полно директив условной компиляции. Директив очень много (десятки тысяч) и расставлены они автоматически - скриптом. Разработчик уверен, что 95% этих директив не нужны и что их можно сократить. Разработчик на 100% прав, но его инициативы вежливо отклоняются.

                                                                                                                                                      Причина проста: продукт уже прошел этап тестирования заказчиком и вот-вот будет отгружен. Сроки уже согласованы, договоры подписаны. Изменение тысяч файлов означает, что все тестирование нужно проводить заново, сроки поедут, по договорам придется платить неустойки и т. п.

                                                                                                                                                      Пример второй:

                                                                                                                                                      Проект средних размеров, но юнит-тестов в нем практически нет. Инициативная группа товарищей (для определенности - двое) пытается внедрить культуру юнит-тестирования: заводят на рабочей машине CI-сервер, настраивают на нем билды и проверяют все коммиты. Если коммит ломает сборку - система рассылает "письма счастья".

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

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

                                                                                                                                                      Я попросил своего руководителя привести мне конкретные примеры токсичности в моем поведении.

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

                                                                                                                                                      Оказывается, если не настаивать на своем мнении, то у коллеги не включается чувство противоречия,

                                                                                                                                                      Это называется софт-скиллс. Не нужно идти на конфликт там, где от этого нет никакой пользы. Поэтому в англоязычных странах используются очень мягкие формулировки - could we please и все такое.

                                                                                                                                                      Вопреки популярному здесь в сообществе мнению "работу работать нужно, а не тратить время на эти бесполезные вежливые расшаркивания",

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

                                                                                                                                                        +1
                                                                                                                                                        В общении внутри команды надо быть гибким, допускать, что другие могут ошибаться, и ты сам можешь быть не прав и это нормально — мы все не без греха. Еще крайне важно отстаивать свою точку зрения без агрессии — иногда, даже даже если кто-то прав, но но при этом ведет себя агрессивно («Вы что — такие тупые, что не можете понять элементарных вещей?) — нападение вызывает защитную реакцию остальной команды, и его идеи не принимаются. Мелкие, незначительные неточности в коде можно пропустить, не акцентируя на этом внимания, потом поправить, при случае.
                                                                                                                                                        Вообще, умение общаться с людьми, не вызывая у них негативных эмоций — это искусство, которое надо изучать и шлифовать.
                                                                                                                                                        Я часто встречал грамотных, квалифицированных специалистов в своем деле, которые совершенно не умели работать в команде — они всех считали тупыми неумехами, а себя суперзвездами. Только как правило получали ЗП эти суперзвезды меньше всех и от них избавлялись при первом же удобном случае.
                                                                                                                                                          0
                                                                                                                                                          Пора бы уже начать увольнять за использование ярлыка «токсичный» по отношению к межличностным отношениям. Пусть уволенный курит толковый словарь и учится жить без навешивания ярлыков.
                                                                                                                                                            +5

                                                                                                                                                            Почему вы такой токсичный?

                                                                                                                                                              +1

                                                                                                                                                              Почему вы переходите на личности?

                                                                                                                                                                +1
                                                                                                                                                                *прищуриваясь и, предвкушая ностальгию*
                                                                                                                                                                А почему ви, таки, отвечаете вопгосом на вопгос?
                                                                                                                                                            +2
                                                                                                                                                            На самом деле вопрос надо было ставить иначе: а в чем причина того, что инициативы по ликвидации техдолга встречают с такой прохладой? Может, проект вот-вот сдают? Может, мы и так по срокам не успеваем и нам дай бог основной функционал доделать к сдаче? Или это вообще делается специально — этакий задел на будущее? Ведь пока мы правим баги, команду не разгонят.

                                                                                                                                                            Так и есть это просто грязная и мерзкая манипуляция, которую автор принял и повелся на нее. Вот это токсичность, хоть и завуалированная. Жаль не все это понимают. Тут полностью с вами согласен. Все технические споры решаются только наводящими вопросами и уточнениями, пруфами, а не преходом на личности, и деланием человека неадекватом. Как только сменили контекст с технического на другой и перешли к личности, это кончились аргументы, и уже пошли грязные манипуляции против человека.
                                                                                                                                                              +1

                                                                                                                                                              Со временем в команду пришли другие новички, тоже с идеей "надо все переделывать". Тут я и узнал себя со стороны и подумал: "наивные, еще не знают, во что они ввязались". Манипуляции не было, просто это занимает время осознать, как правильно подойти к переписыванию работающей продакшен-системы (не меньше года работы). В результате мне удалось переложить историю на язык бизнеса и продать её. Но это уже другая история, достойная отдельной статьи.

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

                                                                                                                                                                  Дело в том, что руководитель хоть и выслушивал, но действий не происходило. Меня это не устраивало, и я продолжал накалять ситуацию. Тут важно заметить, что у кризису ситуацию привёл не один конкретный случай, а совокупность.

                                                                                                                                                                  Самым лучшим выходом оказалось перевести разговор в текстовый вид. Это позволило закрепить текущее состояние и договориться об улучшениях

                                                                                                                                                                    –1
                                                                                                                                                                    Тогда в принципе был 100% прав про пассивного руководителя и пассивную команду…
                                                                                                                                                                    В принципе в таких проектах не всегда даже возможно что-то изменить в лучшую сторону. Поэтому лучший вариант искать другую работу.
                                                                                                                                                                  0

                                                                                                                                                                  как правильно подойти к переписыванию работающей продакшен-системы

                                                                                                                                                                  Если я правильно понимаю ситуацию, то это легко можно объяснить человеку, который готов слушать - это "операция на работающем сердце". Всё время операции система должна работать, причём правильно. Фазы тестирования, выведения в PROD занимают несколько недель (потому, что система должна проработать на beta неделю, ведь выходные отличаются по нагрузке от будних, а понедельник - от пятницы).

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

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

                                                                                                                                                                0

                                                                                                                                                                Тоже есть подобный опыт. Бывает, что коллега выкладывает на code review какую-то полную дичь. Где в классе вместо двух стандартных для подобной задачи методов isSupported / doSomething находится какая-то инициализация, хранение этого всего в свойствах и взаимодействие через 5 таких же кривых методов. На мои робкие попытки указать, что может стоит сделать как-то иначе, что-то улучшить следует стандартный ответ, что "это твое мнение, а у меня другое". И что делать в подобных ситуациях… Менеджер в коде понимает вряд ли больше.

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

                                                                                                                                                                    На новом месте такое тоже может случиться. Сложно при устройстве на работу отследить такие вещи.

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

                                                                                                                                                                        А на удаленке? :)

                                                                                                                                                                          0
                                                                                                                                                                          Кидает таки не компания. Особенно большая. А конкретный человек.
                                                                                                                                                                      +3

                                                                                                                                                                      Вариант сеньора с хорошими софтскиллами: описать это в ревью, предложить решение (в общих чертах), завести под него багу с лейблом "техдолг". Потом, своим личным примером показать как надо – переделать на "нормальный" isSupported/doSomething. Ну и поднять тему "давайте везде делать так" на тиммитинге.

                                                                                                                                                                        0
                                                                                                                                                                        А если у вас не 2 человека в команде, а 20-ть? Вы сколько лет жизни готовы потратить на заведение техдолг багов, а потом их фикс и получение люлей, бо остальные задачи не сделаны, а ваши фиксы ломают тесты и блочат релизы, бо про баг все знают и его все любят и он фактически фича?
                                                                                                                                                                          +3

                                                                                                                                                                          Я считаю что если в команде 20 человек, ее надо делить как минимум на две а то и три.


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

                                                                                                                                                                            –2
                                                                                                                                                                            Ну, тоесть вы как и автор в начале, считаете что уволить надо всех, кроме вас. В целом, конечно, вариант… Но есть нюансы.
                                                                                                                                                                              +1

                                                                                                                                                                              Не надо мне приписывать то, чего я не говорил.

                                                                                                                                                                          +2

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

                                                                                                                                                                            0

                                                                                                                                                                            Конкретно в моей ситуации помог ещё такой приём: написать комментарий "я считаю вот так, но и тебе как профессионалу тоже доверяю". Автор кода начинает по-другому смотреть на свой код - "мне даже другие доверяют, а доверяю ли я себе сам?" - и перепроверяют свой код тщательнее ревьювера

                                                                                                                                                                              –3
                                                                                                                                                                              Вот это уже не корректно. Токсичный троллинг.
                                                                                                                                                                                +2
                                                                                                                                                                                только там нет 1) токсичности 2) троллинга.

                                                                                                                                                                                Но я Вам доверяю
                                                                                                                                                                            0
                                                                                                                                                                            Вариант сеньора с хорошими софтскиллами
                                                                                                                                                                            Во так сделаешь какой-нибудь mock, чтобы потом было проще мерджить свою фичу. Реакция — избыточно и «слишком сложно», изменения откатываются без разговора, фича перепиливается. В итоге смотришь на свой коммит (который ты молча пилил), на репозиторий, и думаешь — а ну тебя в жопу, и возвращаешься туда, куда этот «сеньор с хорошими софтскиллами» добраться не может, а если ему так нравится, пусть дрючится сам.
                                                                                                                                                                            А «сеньор с хорошими софтскиллами» еще больше убеждается в своей крутости, незаменимости и полезности, мол, пофиксил этого несмышленого коллегу.
                                                                                                                                                                            Альтернативный вариант — написать «куда ты лезешь, говнюк, я не дебил и знаю что делаю, просто отойди и займись своими делами», но тогда уже тебя обзовут токсичным непрофессионалом, и это будет правдой.
                                                                                                                                                                        +3
                                                                                                                                                                        Дейл Карнеги давно уже писал про это. Надо не заставлять человека, не вступать с ним в конфликт, а, например, спрашивать его мнение насчет вашего фикса. При этом человеку кажется, что инициатива исходит от него, соотвественно не задета гордость и тд.

                                                                                                                                                                        Ну элементарное же манипулирование, основы, любой умный человек на Западе знает и умеет применять.
                                                                                                                                                                          0
                                                                                                                                                                          Писать-то писал, но судя по тому, как сложилась его жизнь, сам он написанному не следовал.
                                                                                                                                                                            0
                                                                                                                                                                            Ну вообще да, согласен. Вроде читал, что он покончил жизнь самоубийством. Но сами советы от этого не стали менее эффективными.
                                                                                                                                                                              0
                                                                                                                                                                              Он умер от болезни. Не все написанное в интернете правда.
                                                                                                                                                                                +1
                                                                                                                                                                                Вы тоже это написали в интернете. Какие причины верить вам? ;-)
                                                                                                                                                                          +4
                                                                                                                                                                          Первая за хрен знает сколько времени статья с отличным, живым кейсом, прикладным советом для его решения, и ретроспективой произошедшего.

                                                                                                                                                                          Спасибо, прочел с удовольствием.
                                                                                                                                                                            +4
                                                                                                                                                                            да врет все ТС ) не бывает таких людей, склонных к глубокому самоанализу. скорее на его работе есть такой коллега, который всех достал, а он прост выкатил рассуждения как бы от его лица.
                                                                                                                                                                              0
                                                                                                                                                                              С большой вероятностью. Когда говорят про профессиональную этику, то в принципе термин токсичность совсем не применим, да и указывать на токсичность человека это изначально токсично.
                                                                                                                                                                                +1
                                                                                                                                                                                Даже если и так, все верно написал.
                                                                                                                                                                                0

                                                                                                                                                                                Автору респект и уважуха.

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

                                                                                                                                                                                Я не знаю, это мне так (не)везло, или в код-серватории всё-таки проблемы? Самое лучшее, что видел (это было близко к моему идеалу), когда люди были адекватны и влезая в новую тиму сами просили взять над ними шефство. Такие, типа, «частные» код-ревью. Было, кстати, когда такой человек оказывался Коломбо: «Я, конечно, щас какую-нибудь глупость скажу...», а потом в шкафах скелеты обнаруживались, хе-хе.

                                                                                                                                                                                P.S. Ага, слово «чайка» уже прозвучало в комментариях. Не дочитал.

                                                                                                                                                                                  0
                                                                                                                                                                                  Я не знаю, это мне так (не)везло, или в код-серватории всё-таки проблемы
                                                                                                                                                                                  Тут в соседнем посте рассуждают о том, что двор был лучшей школой жизни и социализировал на 10/10. А во дворе как: критика — предъява, нужно держать удар, иначе тебя раздавят. Так и живем. Жизненные привычки несовместимы с творческой атмосферой и больше воспроизводят атмосферу казармы. Со временем «твой код — говно» трансформируется в «извини, но твой код — говно», а затем — «не мог ли бы ты соизволить пофиксить свой говнокод?», и это считается большим прогрессом, практически объективной критикой, на которую нельзя обижаться.
                                                                                                                                                                                    0

                                                                                                                                                                                    Не знаю, по-моему, тут нет никакой связи. (Из своего опыта я её не вижу). Ну, например: у нас в одной команде был один... гопник дворово-социализированный элемент. Мужик в годах, кстати. Лет на 10 старше всех. Юмор, манера общаться — всё соответствующее. Так вот, он никогда не лез в чужой код и терпеть не мог, когда кто-то лезет в его. Между прочим, код он писал, мягко говоря, не тот, который хочется видеть. Но он тащил на себе супер-сложную задачу (типа, взять исходники Postgres и сделать на их основе новую СУБД для нашей платформы) и делал это хорошо. Ну, начальство поступило, по-моему, самым разумным способом в этой ситуации: просто заизолировало его проект и не лезло к нему. Пока он не дописал, гы-гы.

                                                                                                                                                                                    Напротив, в другом коллективе был такой мальчик: вежливый, с улыбочкой, но до того доставучий, и, главное, всё не в тему. Он не говорил: «Код — говно», он именно, что всеми этими карнеги-стайл-фишками оперировал. Проблема в том, что... эх, щас обидятся сказочные поняши... толку от него было, как от статического кодоанализатора. То, до чего он докапывался, БЫЛО ПРОБЛЕМОЙ ТОЛЬКО ФОРМАЛЬНО. Я бы предпочёл, чтоб мне по фене предъявили за то место, где ошибка в адресной арифметике приводит к порче памяти второго порядка (совершенно неотлаживаемая какашка), чем с тратить время на этого... вежливого лося. Короче, как в поговорке, «Хуже нет дурака, чем дурак с инициативой». Его опыт, кстати, хотели расширить на все команды, чтоб, значит, все мешали всем, но я это кино не досмотрел и чем закончилось — не знаю.

                                                                                                                                                                                    Ладно, давайте начистоту: я считаю, что код-ревью это подход к проблеме с неправильного конца. Когда ты лично несёшь ответственность за свои коммиты, когда в прод запушил какую-нибудь херню, а у тебя 10000 пользователей отвалилось (это у меня такое один раз было), ты сам начинаешь просить коллег посмотреть, проверить, разделить, тысызыть, с тобой ответственность, хотя бы моральную. При этом ты просишь, когда речь идёт о реально важных вещах. А когда какой-нибудь дурак, не разбирающийся в проблеме, над которой другой человек думает нон-стопом не первую неделю, лезет со своими «в гугле делают не так!» (ИМХО, одно из самых бесячих обоснований: гугл при разговоре не присутствует и сказать ничего не может, просто кто-то ссылается на его авторитет) — ну, см. текст статьи. Начальник правильно всё сказал автору. А формальные код-ревью просто по факту каждого коммита — это политика, поощряющая скорее второе, чем первое.

                                                                                                                                                                                      –1
                                                                                                                                                                                      Опаньки…
                                                                                                                                                                                      Но он тащил на себе супер-сложную задачу (типа, взять исходники Postgres и сделать на их основе новую СУБД для нашей платформы) и делал это хорошо.

                                                                                                                                                                                      Слышь пацанчег, это случаем компания не из тех, что даже толком копирайты на опен и либре офис не могут затереть и продвигают их «офигенный офис» в госреестр, чтобы протолкнуть в госзакупки и сделать деньги из воздуха? Эти компании даже в развитие софта и решение багов не вкладывали, и не возвращали часть кода опенсорс сообществу, чистое потребительство. Есть которые возвращают, но было несколько компаний именно таких. Про эту пару лет назад писали на нескольких ресурсах на тему импортозамещения… Очень похоже на одну из них и контингент соответствующий…
                                                                                                                                                                                        0

                                                                                                                                                                                        Там же стояло слово «типа». «Типа» значит «задача такого же уровня сложности». Чтобы, с одной стороны, не разглашать на публике подробности конкретного проекта (я считаю это неэтичным), а с другой — каждый мог оценить сложность. Нет, это не был Postgres (и вообще СУБД). Но по сложности похоже.

                                                                                                                                                                                        Я отвечаю на ваш (прямо скажем — не слишком вежливый) комментарий только потому, что разделяю ваше плохое отношение к тому, чтобы взять чужие исходники, а потом выдать их за свои, а тем более — получить на это госденьги. Люди, которые сделали т.н. «Фотон» (перебили копирайт в MultiEdit'е), мне глубоко отвратительны. Тем не менее, хорошо бы сначала было дождаться моего ответа, а потом изливать яд. Нет, в том проекте никаких госконтрактов не было, буква каждой лицензии была выполнена, и не было совершено ничего аморального.

                                                                                                                                                                                          –1
                                                                                                                                                                                          Честно говоря вас не обвинял даже и не давил, это был просто сарказм.
                                                                                                                                                                                        +1
                                                                                                                                                                                        Не знаю, по-моему, тут нет никакой связи. (Из своего опыта я её не вижу).
                                                                                                                                                                                        А я вижу в каждом примере. Везде же одно и то же: репозиторий — это поле боя, а мы на войне.
                                                                                                                                                                                        Случай с молодым гопником из прошлого коммента: это тотальная война с ковровыми бомбардировками.
                                                                                                                                                                                        Случай с мудрым гопником, который уже подрос и силы уже не те: мой код — моя крепость. Позиционная война.
                                                                                                                                                                                        Случай с битым и затравленным гопником: это то, что я назвал «не мог ли бы ты соизволить пофиксить свой говнокод?». Пассивная агрессия, короче. Формально не докопаешься, но эмоциональный эффект тот же. Гибридная война, выбор 21 века.
                                                                                                                                                                                        В целом такой дворовой «человек человеку — волк».

                                                                                                                                                                                        А формальные код-ревью просто по факту каждого коммита — это политика, поощряющая скорее второе, чем первое.
                                                                                                                                                                                        Это политика, позволяющая максимизировать передачу информации между исполнителями. То, что при этом исполнители этот процесс превращают в поле боя — это нифига не здоровая фигня. Хотя как это починить я не знаю. Сам далеко не безгрешен.
                                                                                                                                                                                          0

                                                                                                                                                                                          Это политика, позволяющая максимизировать передачу информации между исполнителями.

                                                                                                                                                                                          ...независимо от того, надо это или нет. Вот это и плохо (с моей точки зрения). Я за более гибкий подход и за передачу только той информации, которая нужна.

                                                                                                                                                                                          Выше я привел пример с переписыванием Postgres (на самом деле другого гиппопотама — видимо, надо это подчеркнуть, слово «типа» недостаточно). Не было бы ничего тупее со стороны любимого (кроме шуток — обожаю этих парней!) бывшего начальства, чем заставить, например, меня (или кого-то другого) ревьюить его правки. Что я мог там наревьюить? До имён переменных доковыряться? Нет, они заизолировали его проект и правильно сделали. Если бы я всё-таки был вынужден это ревьюить, я бы полгода только в тему вникал. Но я бы не вникал, я бы из такого дурдома уволился.

                                                                                                                                                                                          Тем не менее, мы друг друга периодически просили «просто посмотреть свежим взглядом». Или даже «поговори со мной об этом!» (кажется, это называется spiritual duck — был такой мем на StackOverflow, пока его не стёрли). Особенно, когда нужен был опыт (компетенция) другого человека. Зачем этот полезный поток информации забивать всем подряд — я не понимаю.

                                                                                                                                                                                          0
                                                                                                                                                                                          порче памяти второго порядка

                                                                                                                                                                                          Что это такое?
                                                                                                                                                                                            +1

                                                                                                                                                                                            Допустим, вы аллоцируете под данные на 4 байта больше, чем нужно, а размер вписываете в начало буфера. Если в результате ошибки при работе с указателями вы запишете достаточно большое число (больше изначального размера) в середину этого буфера, это будет просто порча памяти. А если повезёт попасть в самое начало, то ваша порча памяти приведёт к тому, что при обработке данных (каждый элемент изменить по заданному правилу) будет перезаписана память за пределами буфера, т.е. порча памяти порождает порчу памяти следующего порядка. Не уверен, что термин общеупотребительный.

                                                                                                                                                                                        0

                                                                                                                                                                                        Я не знаю, это мне так (не)везло, или в код-серватории всё-таки проблемы?

                                                                                                                                                                                        Это вам так не везло (что не исключает проблем в консерватории, конечно).

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

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

                                                                                                                                                                                        0
                                                                                                                                                                                        Коллеги не всегда с ними соглашались, однако я не сдавался и настаивал на изменениях, потому что был на сто процентов уверен, что для проекта так будет лучше.

                                                                                                                                                                                        Точно лучше? Уверенность в своей правоте — не аргумент. Нужно уметь аргументировать свою позицию.

                                                                                                                                                                                        Порой споры принимали ожесточенный характер

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

                                                                                                                                                                                        Свою позицию можно и нужно излагать четко и прямо. А для того чтобы к ней прислушивались, достаточно не переходить на личности и хотя бы немного постараться учесть сторону собеседника.
                                                                                                                                                                                          +3
                                                                                                                                                                                          Комментарии ценнее статьи. Презабавно читать тексты тех самых «токсичных» в терминологии статьи, «душных», как это описали в комментариях, ЧСВшников, которые оправдывая свой нарциссизм, только закапывают себя глубже, предоставляя эталонный поток сознания обсуждаемых персонажей. Всё в полный рост — есть два мнения — моё и неправильное, все, кто со мной не согласен — просто никчемные ленивые и тупые серости и неспособны понять мои великие идеи, они все ограничены и ни к чему не стремятся, и вообще обижают ни за что. Даже пассивным молчанием меня, бедняжку, атакуют.
                                                                                                                                                                                            0
                                                                                                                                                                                            Надо во всё знать меру бизнесу не нужен идеальный код. И не факт что хорошо написанный код проживёт дольше плохого.
                                                                                                                                                                                            Сейчас например закрывается один проект который я сам начинал и вёл. Работает, мейтениться, функционала и расширяемости больше и дешевле второго проекта который нам втюхивают главная фирма после покупки нас и единственный аргумент почему мы мигрируем к ним, а не они к нам, это то что они уже втюхали туда в 10 раз больше бабла и не хотят признавать эту ошибку оффициально.
                                                                                                                                                                                            Так что сколько потраченных нервов и времени можно было бы сьекономить, особенно когда выясняли отношения с ФЕ говнокодерами из аутсорс фирмы.
                                                                                                                                                                                              0
                                                                                                                                                                                              Тоже был подобный кейс. И в тоже время вы не можете сказать что ваш проект лучше, ведь они купили вас, а не вы их. Это означает что их постановка процессов(которая в том числе скорее всего маппится на разные сферы, в том числе и на выполнение проектов) ценится рынком лучше
                                                                                                                                                                                              +2
                                                                                                                                                                                              Очень хорошо что история со счастливым концом. И в комментариях уже всё правильно обсудили про софт-скиллз. Но предлагаю посмотреть на ситуацию с ещё большей высоты. А почему вообще автор решил что его взгляд на техдолг верный?
                                                                                                                                                                                              немало технического долга, который меня сильно расстраивал
                                                                                                                                                                                              а остальных, видимо, не расстраивал. По всей видимости, никто не видел никакой проблемы, и этих людей было заметно больше чем один автор. Более того, когда автора попросили формализовать проблему, это закончилось тем что
                                                                                                                                                                                              но в итоге так и не смог привести внятного и весомого аргумента
                                                                                                                                                                                              Так был ли вообще какой-то объективный техдолг?
                                                                                                                                                                                              Короче говоря, мне кажется что автор просто был юн и горяч, и его мнение по многим вопросам казалось ему самому очень важным, и он доставал этой «важностью» всех окружающих.

                                                                                                                                                                                              Хочу резюмировать комментарий вопросом, а почему вообще люди считают своё мнение заметно значимым? И часто более значимым чем мнение коллег.
                                                                                                                                                                                                +2
                                                                                                                                                                                                Начал читать, хотел минусануть, а потом плюсанул.
                                                                                                                                                                                                Респект автору, что умеет работать над ошибками. Редко встречал людей, анализирующих свои взаимоотношения с другими, а не встающих в позицию Д'Артаньяна. На последней работе два человека так закончили увольнениями.
                                                                                                                                                                                                Мне повезло сначала увидеть со стороны (на примере первого), как выглядит «токсичный» код-ревьювер, так что когда сам начал ревьювить код, уже мягче подходил к процессу. Так ведь на самом деле лучше работает.
                                                                                                                                                                                                  0

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

                                                                                                                                                                                                    +2
                                                                                                                                                                                                    Уважаемые, а накидайте плиз литературы на тему того, как работать с людьми у которых два мнения — их и неправильное, или эмоциональный интеллект в возрасте 40+ лет на уровне 5-летнего ребенка, и любое несогласие приводит к выплеску эмоций? Только ради всего святого не будем обсуждать, зачем вообще с ними работать — иногда выбора нет, просто хотелось бы быть более прошаренным, что-ли.
                                                                                                                                                                                                      0
                                                                                                                                                                                                      вроде была такая «Никогда не работайте с мудками».

                                                                                                                                                                                                      а если серьезно, то сам попадал в такую ситуацию. простое решение работать в разных проектах, как правило это можно сделать не покидая компании.
                                                                                                                                                                                                      +1

                                                                                                                                                                                                      Что-то мне кажется, что история эта выдуманная :) в ней все персонажи очень положительные :), все действуют, на первый взгляд, правильно, но… Очень много вопросов возникает о таком персонаже как "руководитель". Такое нейтральное название — руководитель. Кто он, чем занимается, какая его реальная роль — не ясно. Он грамотно ответил, и разрулил проблему, но… при этом полностью игнорировал проблему до этого. Это как-то не сходится. Ну и некоторые использованные слова как-то плохо ассоциируются с простым разработчиком :)


                                                                                                                                                                                                      Я так понимаю и бурное обсуждение вызвано именно нереальностью истории :)

                                                                                                                                                                                                        +1

                                                                                                                                                                                                        Выше писали, что может быть сотня причин игнорирования проблемы. Сроки, деньги и т.д

                                                                                                                                                                                                        0
                                                                                                                                                                                                        Во всем нужен здравый смысл. Хороший код сам по себе мало интересен бизнесу. Нужно чтобы поставленные задачи решались, и продукт был нобходимого качества для пользователей… Банально да, но к пониманию этой банальности сам потратил не один год.

                                                                                                                                                                                                        С практической точки зрения, в подобной ситуации поможет хороший тим/тех лид.
                                                                                                                                                                                                          0

                                                                                                                                                                                                          Soft Skill - называется. Мне сейчас сделали предложение, но есть проблемка, примерно как автор и описывает. Хорошие советы - возьму на вооружение.

                                                                                                                                                                                                            0
                                                                                                                                                                                                            Надо не забывать о том, что лучшее — враг хорошего. Порой упарывание в чистоту кода может существенно замедлить развитие проекта.
                                                                                                                                                                                                              +1
                                                                                                                                                                                                              Вам крупно повезло дважды. Первый раз-это то что не уволили сразу без обьяснения причин. Второй раз с руководителем. Золотой человек. Ну и ещё вы изменили свое мнение после серьезных фактов.
                                                                                                                                                                                                                +1

                                                                                                                                                                                                                История о том, как миддл стал сеньором

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

                                                                                                                                                                                                                  Кто-то написал неподдерживаемый код или сдублировал или устроил мэджик намбер — пресекать. «Перенесите это в переменную, это антипаттерн».

                                                                                                                                                                                                                  Кто-то назвал переменную не как вам больше нравится или поставил пустую строчку — пускай. Еще лучше какой-нибудь автолинтер прикрутить. Есть правило в автолинтере — линтер или автор сам исправит без ревью. Нет правила — значит либо добавляем после согласия и buy-in команды либо забиваем болт.
                                                                                                                                                                                                                    0
                                                                                                                                                                                                                    Осознание этого, это плюс в карму и ступень в разивитии. Не все до этого доходят сами).
                                                                                                                                                                                                                      0
                                                                                                                                                                                                                      Отличный пример, почему разработчикам нужны так многими нелюбимые (если не ненавидимые) софт-скиллы. Тут надо еще отметить, что под софт-скиллами многие понимают только умение говорить — иными словами правильно донести свою аргументацию до противоположной стороны. Между тем в статье нагляднейше показано, что софт-скиллы — это не только умение говорить, но и не менее важное умение слушать, что тебе говорят окружающие.

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

                                                                                                                                                                                                                      А вот здесь возникает вопрос, почему совещание не модерировалось. Нужен кто-то, кто будет жестко удерживать собравшихся в рамках заранее определенной темы. Почему человека не остановили в самом начале, сказав, что поднимаемая им тема не относится к заранее заявленной?
                                                                                                                                                                                                                        0

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

                                                                                                                                                                                                                          0
                                                                                                                                                                                                                          Чтобы определить, является дискуссия оффтопиком или нет, нужно сначала дослушать выступающего до конца. А это уже отнимает время.

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

                                                                                                                                                                                                                          Роль модератора полезная, но недостаточная, нужно еще и само-модерацией заниматься.

                                                                                                                                                                                                                          В идеальном варианте — да, но не всегда получается. Если человек действительно увлечен излагаемой идеей, и считает ее важной, то он вполне может потерять контроль.
                                                                                                                                                                                                                        0
                                                                                                                                                                                                                        На днях наталкивался на неплохую статью на эту тему: How to be good at Code Reviews
                                                                                                                                                                                                                          0
                                                                                                                                                                                                                          отличная статья просто.
                                                                                                                                                                                                                          технический прогресс последних десятилетий вытеснил более «староверческие» навыки типа риторики, чувства собеседника, ощущения своего положения в социуме, умения свободно высказать свою точку зрения по вопросу предполагающему более чем одно верное решение.

                                                                                                                                                                                                                          благо ваш руководитель оказался достаточного скила чтоб погасить конфликт и одновременно перевоспитать вас сохранив на рабочем месте. не всегда это удается.
                                                                                                                                                                                                                            0
                                                                                                                                                                                                                            Неожиданно :)
                                                                                                                                                                                                                            Я ожидал что-то вроде, «у меня были токсичные коллеги и вот к чему это привело...»
                                                                                                                                                                                                                            Ну или «да, я понял, что я был в некоторой степени токсичный, и меня уволили, но у меня были к этому следующие серьезные основания...»
                                                                                                                                                                                                                            А тут вообще другая тема. Рад за всех — и за автора и за начальника и за коллег :)
                                                                                                                                                                                                                              0

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

                                                                                                                                                                                                                                +2
                                                                                                                                                                                                                                Я конечно понимаю, что внутри компаний есть разные практики. И опенсорц — это не коммерческая разработка. Но почитав эту статью, я весьма удивлен, в плане «неужели такое „токсичное“ бывает?». В LibreOffice ревью патчей выглядит очень просто и совершенно не токсично. И люди абсолютно незнакомые конечно при этом. В патч приходит разработчик и просто ставит +1, +2 и вливает патч в кодобазу, если все ОК. Если его что-то не устраивает, то он ставит -1 и пишет, а что именно ему не нравится, тупо конструктив, прямо построчно по патчу. Если патч что-то явно сломает (даже если патч прошел дженкинса), то ставят -2 и пишут, а что сломается, точно так же тупо конструктивно.
                                                                                                                                                                                                                                Если патчеписатель хочет, чтобы патч приняли — он спокойно воспринимает критику, правит код, спрашивает совета, обосновывает свою точку зрения. К патчу может быть овер 100 комментариев и они все в спокойном конструктивном тоне.
                                                                                                                                                                                                                                За шесть лет наблюдения за проектом я видел всего ОДИН случай, когда патчеписатель требовал, чтобы патч его был принят, в достаточно грубой манере. От него все отвернулись, патч был просто заигнорен разработчиками. Правда потом случилось смешное и патч был принят все же, потому что оказался корректным сам по себе.
                                                                                                                                                                                                                                Ну а то, что начальник из статьи оказался ОЧЕНЬ грамотным начальником и весьма достойно разрулил ситуацию — это редко бывает.
                                                                                                                                                                                                                                  0
                                                                                                                                                                                                                                  Если патчеписатель хочет, чтобы патч приняли — он спокойно воспринимает критику, правит код, спрашивает совета, обосновывает свою точку зрения.
                                                                                                                                                                                                                                  Всё так. На этом этапе он вынужден воспринимать критику, иначе его патч не примут. А дальше бывает по-всякому. Например, если чувак регулярно засылает в целом годные патчи (пусть не особо вылизанные, но он охотно их причесывает по просьбе ревьюера, или коммитер сам их приводит в надлежащий вид), то в какой-то момент чуваку могут дать коммит-бит, приставив на первых порах ментора. Часто бывает, что ментор ревьюит патчи вполглаза, а вскоре и вовсе дает automatic implicit approval. На этом этапе толерантность к критике у чувака обычно снижается, в том числе и потому, что теперь ему не требуется благосклонность ревьюеров — он уже коммитит свои патчи сам, без посредников. В худшем случае такой чувак сам становится ментором для новобранцев, посредственным и не умеющим привить им должную культуру разработки. Конечно, бывает и по-другому, но я немало повидал таких чуваков, не заинтересованных в улучшении своего кода и при этом болезненно воспринимающих практически любую критику или игнорирующих её вовсе.
                                                                                                                                                                                                                                  0

                                                                                                                                                                                                                                  Как менеджер с большим стажем, позволю себе дать небольшой совет.

                                                                                                                                                                                                                                  Дело не в том, что люди обидчивы. А в том, что никто не видит всех нюансов целиком. А частный исполнитель не всегда понимает всю конечную задачу.

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

                                                                                                                                                                                                                                  Ещё раз: не говорите как делать, а указывайте на проблему и последствия. Это придаёт переделке смысл. «Так неправильно» это не указание на проблему.

                                                                                                                                                                                                                                    +1

                                                                                                                                                                                                                                    После прочтения статьи понял только, что руководитель у ТС хороший.

                                                                                                                                                                                                                                      0

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

                                                                                                                                                                                                                                        –2
                                                                                                                                                                                                                                        Я понимаю если люди бьются за технологические вещи к примеру code coverage выше 80 процентов. Но код ревью это чистой воды вкусовщина на вроде нравится или не нравится. Критерий там только один если код работает согласно тест кейсам и удовлетворяет definition of done. Можно поговорить на код ревью, но устраивать из этого драму?!
                                                                                                                                                                                                                                          +1
                                                                                                                                                                                                                                          почитал комментарии и понял что мне все это напоминает книгу «дурная компания» торина, какое-то противоестественное желание узнавать, что есть места где хуже чем у меня
                                                                                                                                                                                                                                            +1
                                                                                                                                                                                                                                            «тут можно было сделать и по-другому, более оптимально, но в целом мне без разницы, могу заапрувить и так» — это главный смысл этой истории, это называется здоровый пофигизм, ты таким образом правильно делишься ответственностью и лучше вовлекаешь участников проекта, они не чувствуют что ты им навязал свое мнение
                                                                                                                                                                                                                                              –1
                                                                                                                                                                                                                                              junior: исправлена опечатка в комментарии
                                                                                                                                                                                                                                              senior: нужно добавить Фабрику Декораторов Фасада
                                                                                                                                                                                                                                                0
                                                                                                                                                                                                                                                Вот поэтому я и ушел полностью в сисадминство, до этого был DevOps`ом с уклоном в программиста.
                                                                                                                                                                                                                                                Надоели все эти ревью и прочий бред.
                                                                                                                                                                                                                                                  0
                                                                                                                                                                                                                                                  У меня такой подход к ревью. Если я вижу откровенный говнокод — не утверждаю. Дурно пахнет, срочный фикс, QA проверили — чёрт с вами. Явная фигня и лучше переписать — пишу коммент рекомендую сделать так. Говорю с автором, и либо он переделывает и я утверждаю, либо просто утверждаю. Мы делаем ревью не по факту коммита, а по факту merge request.
                                                                                                                                                                                                                                                    0
                                                                                                                                                                                                                                                    Видел две стороны медали

                                                                                                                                                                                                                                                    — и когда джуниоры, еще студенты, только прошедшие лабу, приходили на проект со словами «там такоооой говнокод, там такооое, все надо переписать». А сами прочитали две книжки, но if с else еще толком связать не могут, а ЧСВ выше крыши;
                                                                                                                                                                                                                                                    — и когда приходишь на проект себе тихонько и через 2 недели понимаешь, что с существующей «архитектурой» самое малейшее изменение требует от тебя 2 дня багфикса с залезанием во все детали, а от QA — регрессию как минимум всего моделя. И что команда состоит на 80% из людей, которые фиксят баг перерисовкой всего экрана при сдвиге на каждый пиксель, не видят ничего в 30-ти синглтонов, беспорядочно дергающих методы друг друга, и broadcast notification-ах.

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

                                                                                                                                                                                                                                                    Что я могу сказать? Универсального совета тут точно нет, нужно смотреть через призму своего опыта в каждом случае отдельно.

                                                                                                                                                                                                                                                    Лично я на первых не обращаю внимания — нужно просто холодно попросить список вещей, которые малыш видит как говнокод, с аргументацией почему он так считает и путями решения. 5% что-то сделают, 95% умерит свой пыл на первом же реальном кейсе. У малыша просто нет опыта, чтобы понять, почему люди писали так, а не так как написано в той классной статье — в той или иной степени все это проходили.

                                                                                                                                                                                                                                                    Во втором случае я не вижу причин не уйти, если там конечно не зарплата в 10к долларов чистыми и страховка в Принстон Плейсборо. И квартиры дают бесплатно. Тогда можно сидеть и терпеть. Но какой смысл бороться с ветряными мельницами? Пусть и правда сидят так дальше, раз всех все устраивает. Да, таких проектов даже большинство, ну и что, есть армия любителей таких проектов.

                                                                                                                                                                                                                                                    У меня есть знакомый, который на них специализируется. Устраивается на удаленку на не самую топовую зарплату на такой распил — там на 2.7к, там на 3.0. Работает там 2 часа, там 2 часа, единственная проблема — митинги иногда пересекаются. Но это всегда можно как-нибудь разрулить, тут уже хочешь жить умей вертеться. Как вам зарплатка в 5.7 чистыми в Брестской области в каком-то там сельсовете? И плевать он хотел на чистоту кода и архитектуру, лишь бы появиться на дэйли, каком-то еще митинге и сделать 2-3 коммита для потемнения ячейки в профиле гита.

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

                                                                                                                                                                                                                                                    В общем, ищите свое и держите нос по ветру. Самое главное — понимать, чего на самом деле хочешь. Всех денег не заработаешь, а счастливы на работе единицы. Я иногда бываю счастлив. Это куда лучше чем у 90%.

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

                                                                                                                                                                                                                                                    Самое читаемое