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

Сказал главный парень. Это не правительство и не политическая партия. Вы не можете никого выгнать или возглавить восстание.

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

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

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

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

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

БЕГИТЕ Серьезно, я не знаю, зачем кому-то хотеть быть там. Спросите себя, есть ли в том, что вы сказали нам, что-то, что не означает гибель продукта? Я уверен, вы знаете это. Если на то пошло, я сомневаюсь в базовом интеллекте основателя. Из разработчиков обычно получаются очень паршивые менеджеры проектов/программ. Это отдельный набор навыков, и они должны уравновешивать друг друга. Это как сказать «нам не нужны отдельные тестировщики, отлично работает тестирование разработчиков». Оба являются рецептами катастрофы. Удачи. Я имею в виду, что.

Описание ситуации ОП, вероятно, одностороннее. Все нормально.

Я стареющий разработчик (~ 54 года), которого пригласили в компанию не для того, чтобы управлять, а для того, чтобы дать некоторый опыт. (ИТ-босс на самом деле сказал «седые волосы», лол.) В целом команда разработчиков была гораздо более искусной, чем любая команда, с которой я работал раньше. Они многому меня научили, особенно смирению! Но мы нашли места, где их технологическое волшебство не решало проблемы, а в некоторых случаях скрывало эти проблемы, в конечном итоге усугубляя их. Здесь я действительно смог внести свой вклад.

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

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

Он ненавидит IDE

Я знаю несколько таких. Это заставляет меня закатить глаза, но в конечном счете мне все равно. Если люди производят с помощью vi, то ок. Я люблю свои IDE.

Он не рефакторит код и не заботится о стиле (что несовместимо с его собственным кодом).

Красный флаг в первой части. Он копипастер? Я также виноват в том, что не забочусь о стиле, но это потому, что я использую свою IDE, чтобы мгновенно сделать свой код Python совместимым с PEP8. Но он не использует IDE...

Кстати, стиль ранее проверялся ночной сборкой, которая начала давать сбои с приходом нового лида.

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

Это также вызывает тревогу, но по другим причинам, чем вы могли ожидать. До того, как этот парень был нанят, сколько раз владельцу говорили, что он не может сделать X (показать демо, использовать систему и т. д.), потому что ночная сборка не удалась? Что, если владелец поймет, что проблема заключается в ночной сборке? Как вы думаете, что он сказал бы Лиду сделать?

Но меня беспокоит отношение Лида; автоматические тесты потрясающие. Как и прежде, босс может не понимать ценности тестов, но он точно знает, что Y% зарплаты разработчиков идет на их оплату. Когда я пришел в свою нынешнюю компанию, «мафия со 100% охватом тестами» взяла на себя штат разработчиков и значительно увеличила расходы. Одно плохое яблоко спустя, и команда разработчиков снова замурлыкала.

Он думает, что контроль версий в основном бесполезен...

Это красный флаг высшего порядка. Он максимально неправ. Он безответственно относится к деньгам владельца.

Он преувеличивает важность оптимизации кода.

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

Он пишет весь SQL вручную и отвергает идею ORM.

Виновен по обвинению! Я не понимаю страх людей перед SQL. Я не понимаю, как хоронить SQL, который очень прост, под слоями ORM, которые запутывают. Не могу вам здесь помочь :-D Но, пожалуйста, свалите весь свой SQL в одно место - не распределяйте его по всему коду.

и двое из пяти разработчиков никогда раньше не использовали SQL.

Это неприемлемо. Это 2016 год. Им нужно повышать квалификацию.

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

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

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

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

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

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

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

Тем не менее, адаптивный дизайн может быть очень интересным для этого приложения,...

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

Он просит команду перестать пользоваться интернетом (особенно StackOverflow) и полагаться на свои мозги, офлайн-документацию (я даже не знал, что Microsoft до сих пор продает компакт-диски MSDN!) и книги.

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

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

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

Теперь, что вы можете сделать?

1) Объясните лиду, что использование автоматизированного тестирования и управления кодом — это правильный путь. Может потребоваться время, чтобы завоевать доверие с ним - владелец, вероятно, сказал ему, что посох неисправен. Посмотрите, сможете ли вы помешать ему давать широкие указания, такие как «удалить всю эту бесполезную тестовую хрень и перепрофилировать сервер SVN». Это даст вам время показать ценность.

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

3) Продолжайте автоматизированное тестирование (или модульные тесты) на личном уровне. Как и раньше, не упоминайте об этом, но и не скрывайте.

4) Работайте с Лидом, чтобы определить, каковы фактические предполагаемые проблемы. Будьте открытым; Могу поспорить, что есть реальные проблемы с персоналом. Работайте с лидом, чтобы решать проблемы, а не симптомы.

5) Обсудить с руководителем различные темы разработки, такие как преимущества водопада и agile. Ни то, ни другое не идеально. Задайте ему такие вопросы, как «При каких обстоятельствах автоматизированное тестирование будет целесообразным»? Если он дает сомнительный ответ, спросите его, как успешные компании, такие как Google, смогли процветать, несмотря на это.

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

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

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

двадцать пять лет в IT [...] изменить свое отношение

Не получится, извини.

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

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

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

Есть только 2 вещи, которые я могу придумать, чтобы улучшить ситуацию на этой работе:

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

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

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

Первый красный флагFor a few years, the founder was unhappy about the technical skills of the employees

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

Второй красный флагtwo of the five developers never used SQL before

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

Трудно представить, что это I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a******.было сказано на самом деле, но я приму это за чистую монету и поверю вам.

Тем не менее, примите во внимание первый тревожный сигнал, о котором я упомянул, и «несчастье», с которым основателю пришлось столкнуться в течение многих лет.

К этому добавлю: вы, ребята, уже много лет знаете о несчастье основателя?!

Как эта информация была доведена до вас?

Я склонен думать, что этот парень делает именно то, для чего его наняли; привести вас в форму.

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

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

Похоже, основатель не доверяет вам, ребята.

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

• По их словам, парень грубиян и не имеет никакого уважения к другим членам коллектива. Одна недавняя цитата из его разговора с младшим программистом перед командой очень показательна: «Я проработал в этой отрасли двадцать пять лет, а вы? Что вы наделали? Ты был кодовой обезьяной в течение трех лет. Так что заткнись, ты, придурок! Никому нет дела до твоего мнения, *****».

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

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

по-видимому, прошлые практики не принесли результатов, которых хотел основатель.

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

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

1. Он ненавидит IDE, автодополнение и функции, призванные помочь программистам писать код быстрее, и утверждает, что для продуктивной работы команда должна использовать Notepad++. Хотя это имеет смысл в других обстоятельствах, трудно представить, чтобы разработчики C# вдруг отказались от Visual Studio в пользу Notepad++.

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

2. Он не занимается рефакторингом кода и не заботится о стиле (который несовместим с его собственным кодом) по той причине, что «он заботится только о вещах, которые действительно имеют значение». Кстати, стиль ранее проверялся ночной сборкой, которая начала давать сбои с приходом нового лида.

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

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

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

4. Он считает, что контроль версий в основном бесполезен, и, кажется, неправильно понимает, как его использовать. Это приводит к ситуациям, когда он разрабатывает фичу в одиночку три-пять дней, а когда, наконец, коммитит свои изменения, то и вовсе «забирает мое» за все конфликты. Если другие члены команды жалуются, что их код был стерт, он предлагает им переписать его. Несколько раз другие участники делали то же самое, удаляя код ведущего разработчика. Он выглядел удивленным (похоже, он не знает, как использовать svn log или diffs) и снова внес свои изменения, жалуясь, что «они были загадочным образом потеряны», и обвиняя SVN в том, что он облажался.

Здесь виноваты все. Никто не делает резервную копию? Если у него проблемы с контролем версий, команда обязана работать как команда, а не просто доставлять ему неприятности.

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

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

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

6. Он пишет весь SQL вручную и отвергает идею ORM. Следует отметить, что текущий продукт основан на ORM Entity Framework от Microsoft, и двое из пяти разработчиков никогда раньше не использовали SQL.

Тогда двоих из пяти разработчиков следует уволить. Если вы полагаетесь на ORM, вы никогда не сможете залезть внутрь и исправить что-то вручную. Я начинаю понимать, почему он в отчаянии назвал кого-то «кодовой обезьяной». ORM хороши и хороши, но вам нужно понимать SQL, если вы когда-нибудь собираетесь выйти за пределы ограничений ORM.

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

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

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

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

9. Он просит команду перестать пользоваться интернетом (особенно StackOverflow) и полагаться на свои мозги, офлайн-документацию (я даже не знал, что Microsoft до сих пор продает компакт-диски MSDN!) и книги.

Хорошо для него. Похоже, он хочет знать, кто может делать домашнее задание самостоятельно, а кто жульничает.

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

Что нужно сделать команде, чтобы:

• Либо выбросить лидера из команды или компании,

• Или заставить его изменить свое отношение к команде?

Как насчет того, чтобы работать с ним и не саботировать каждое его движение?

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

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

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

Увольнение должно быть крайней мерой.

Собственнику необходимо нанять менеджера по персоналу

Другие ответы намекают на это, но слон в комнате заключается в том, что владелец (по понятным причинам), похоже, испытывает трудности с успешным выполнением кадровых функций, таких как наем, обучение, увольнение и т. д. Показательный пример: владелец укомплектовывает неэффективную команду, мирится с ними годами, затем нанимает 25-летнего ветерана, чтобы исправить ситуацию, а затем нанимает консультанта, когда 25-летний ветеран не может ничего исправить. Владелец, кажется, не знает, как управлять кадровой стороной бизнеса. Ничего страшного, есть люди, которые этим зарабатывают на жизнь, поэтому в большинстве организаций есть менеджеры по персоналу. Владелец должен нанять одного стата. Это позволит владельцу сосредоточиться на стратегической стороне бизнеса, так что это беспроигрышный вариант.

Возможно, ОП мог бы помочь с собеседованием (в конце концов, владельцу, похоже, нужна помощь в этом отношении)?

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

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

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

1. Поговорила ли вся команда вместе с этим разработчиком и попыталась ли объяснить преимущества таких вещей, как контроль версий и IDE? Откровенное обсуждение в массовом порядке может помочь

2. Я согласен, что оскорблять других разработчиков непрофессионально, и это нужно ему убедительно объяснить. Спросите его, доволен ли он, если другие используют тот же тон

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

4. Спросите его, доволен ли он тем, что становится старым и сварливым старым придурком с атрофированным разумом, поскольку он не узнает ничего нового.

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