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

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

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

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

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

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

Честно говоря, это, наверное, не стоит стресса для вас и вашей команды. *Я бы посоветовал каждому из вас начать искать новую работу и уйти, когда вы ее найдете. Когда человек уходит, убедитесь, что они сказали боссу почему. * В конце концов, он может получить картину. Серьезно, я не знаю, зачем кому-то понадобилось быть там. Спросите себя, есть ли что-нибудь в том, что вы сказали нам, что не пишется по буквам “в конечном итоге обречен” на продукт? Я уверен, что вы знаете это. Я ставлю под сомнение основной интеллект основателя. Разработчики обычно делают очень паршивых менеджеров проектов/программ. Это отдельный набор навыков, и они должны уравновешивать друг друга. Это как сказать “нам не нужны отдельные тестеры, тестирование разработчиков отлично работает”. Оба рецепта - это рецепты катастрофы. Удачи. Я серьёзно.

Описание ситуации в ОП, скорее всего, одностороннее. Ничего страшного.

Я стареющий разработчик (~54 yo), которого привели в компанию не для того, чтобы править, а для того, чтобы обеспечить некоторый опыт. (IT-босс на самом деле сказал “седые волосы”, Лол.) Персонал разработчиков был far более опытным, в целом, чем любая команда, с которой я работал ранее. Они научили меня многому, особенно смирению! Но мы нашли места, где их технологическое мастерство не решало проблемы, а в некоторых случаях скрывало эти проблемы, в конечном счете делая их еще хуже. Именно здесь я смог внести реальный вклад.

Ваш ведущий голос звучит очень автократично. Звучит так, как будто он получил мандат от владельца. Владелец недоволен штатом разработчиков и привёл этого “жёсткого безрассудца”, чтобы увеличить скорость доставки.

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

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

Я знаю несколько, которые делают. Он заставляет меня закатывать глаза, но в конце концов мне все равно. Если люди производят с использованием vi, то хорошо. Мне нравятся мои IDE.

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

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

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

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

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

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

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

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

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

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

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

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

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

Это неприемлимо. Это 2016 год.

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

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

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

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

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

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

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

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

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

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

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

• *

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

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

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

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

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

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

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

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

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

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

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

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

Не будет работать, извините.

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

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

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

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

1. Найти посредника. Есть несколько основателей, или что-то вроде членов правления?

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

• *

* Хотя большинство пунктов, поднятых ОП, не обязательно делают незнакомца некомпетентным, его подход к Контролю версий и непрерывной интеграции в команде из 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 ******. было на самом деле произнесено, но я приму это за чистую монету и поверю вам.

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

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

Как эта информация была разглашена вам?

• *

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

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

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

Звучит так, как будто основатель не доверяет вам, ребята.

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

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

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

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

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

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

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

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

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

1. Он не рефакторизирует код и не заботится о стиле (который несовместим с его собственным кодом), причина в том, что “он заботится только о вещах, которые на самом деле имеют значение”. На заметку, стиль ранее проверялся ночной сборкой, которая начала терпеть неудачу с момента появления нового свинца. Стандарты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Увольнение должно быть последним средством.

Владелец должен нанять менеджера по персоналу

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

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

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

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

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

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

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

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

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

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