Регистрация
24 мая 2021 в 09:17

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

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

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

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

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

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

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

    Анализ

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

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

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

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

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

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

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

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

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

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

    Выводы

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

    Теги:
    Хабы:
    Реклама
    Баннер исчез, и под ним проявились пиктограммы от НЛО Посмотреть

    Похожие публикации

    Вакансии

    Больше вакансий на Хабр Карьере
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +51

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

        +41

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

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

          –2

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

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

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

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

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

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

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

                +14

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

                +53

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

                                      Ну чтобы понимать, что вы подразумеваете под "очень часто". С моей точки зрения, "очень часто" предполагает распространенное явление, ну т.е. хотя бы 50%+ коммерческого кода пошарено. Если же пошарено ну где-то ~10% — то можно считать, что коммерческий код вообще не шарят.


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

                                      Так факт "коммерческим кодом делятся" ни как не противоречит тому, что "коммерческим кодом вряд ли делятся".

                                        0
                                        Под «очень часто» можно понимать очень многое, в зависимости от контекста.

                                        Вот если 90% кода было открытым, это «очень часто» для вас? А если этим бы занималось всего 5% компаний? А если бы это приходилось на 1% предметных областей (к примеру, только базы данных были бы открытыми), это все еще очень часто? Ну или если бы только 1% это кода был бы достоен внимания, а остальное мусор?

                                        Ну то есть, если вы решили, что я имел ввиду какую-то статистику, то почему именно такую?

                                        Если дождь идет каждый час, это очень часто? А при этом он занимает всего 5% от общего количества времени в сутках?

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

                                        Так факт «коммерческим кодом делятся» ни как не противоречит тому, что «коммерческим кодом вряд ли делятся».

                                        Почему не противоречит? Откуда вы знаете, что имел ввиду автор? Быть может, он имел ввиду — «коммерческим кодом НЕ делятся, но я в этом не уверен на 100%». То есть, он имел имел ввиду не процент от общего количества, а саму вероятность существования такого явления. А я ему показал — товарищ, посмотри, такое явление существует с вероятностью 100%. На что он бы мог ответить — «хмм, действительно! как же я ошибался!». Давайте ка мы сначала добьемся от него четкого определения, а уж потом продолжим дискуссию.
                            0

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

                                          0

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

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

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

                                            +13

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

                                                                          +2

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

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


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

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

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

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

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

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

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

                                                                                                0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

                                                                                                                              +3

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

                                                                                                                                –1

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

                                                                                                                                  +4

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

                                                                                                                            +7

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

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

                                                                                                                              0

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                                                                +4

                                                                                                                                                Docker, RabbitMQ

                                                                                                                                                Хипстерство

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

                                                                                                                                                  +1
                                                                                                                                                  RabbitMQ это хипстерство? Oh my… у меня для вас плохие новости :)
                                                                                                                                                –8
                                                                                                                                                Токсичность это термин из сленга радикальных феминисток, ЛГБТ & 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
                                                                                                                                                                      Волков бояться в лес не ходить? С опытом учишься видеть токсичные компании. Банально можно посмотреть как устроен офис, какое отношение к сотрудникам, что с обучением, есть ли мозговые штурмы, есть ли кофемашина, что с ДМС, какая миссия компании и т.д. В принципе один раз мне попалась компания с высокими ценностями и