[Управление разработкой, Управление проектами, Карьера в IT-индустрии] Каково работать вместе с очень ужасным разработчиком (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В команде разработки завёлся разработчик, который халтурит, и ты ничего не можешь с этим поделать. Если у вас никогда не было такого опыта, я вам завидую.
В былые времена у всех, от стажёра отдела QA до руководства, имелся какой-нибудь опыт кодинга. Те времена давно уже миновали, и теперь у нас есть несколько уровней «мастеров» методологии и менеджеров, за свою жизнь не написавших ни строки, считающих любые жалобы на чужую работу самовольством и личными конфликтами, а также не принимающих никакой критики своих технических навыков.
Если я скажу, что тот или иной член команды халтурит, и даже объясню всё вежливо и с техническими подробностями, менеджеры воспримут это как «ссору» и сосредоточат всё своё внимание на сплочённости коллектива, подразумевая, что проблемы создаю именно я.
Внешние факторы
До недавнего времени я работал в распределённой команде, трудившейся на английскую компанию. Один из членов команды, которого я буду называть Л., не только писал ужасный код (подробнее об этом ниже), но и был в три раза громче всех остальных на ежедневных планёрках в Zoom. Своим пронзительным голосом, не заботясь о правильном английском произношении, он настаивал на том, что ему нужно показать свой экран, но на самом деле не демонстрировал ничего информативного — мы просто смотрели, как он двигает курсором мыши.
Он обладал механистическими привычками. Его реакция на любую смену темы была всегда одинаковой. Настала его очередь говорить? «Давайте я покажу свой экран». Появилось сообщение об ошибке? Получайте полноэкранный скриншот в BMP с огромным прямоугольником, внутри которого самого сообщения почти не видно. Нужно объяснить ключевое слово? Ещё один скриншот. Спасибо, Л., мы ведь не знали, как пишется «foreign key».
Я уже начал бояться созвонов, потому что его пронзительный громкий голос вызывал у меня головную боль. Все остальные члены команды освоили английский в достаточной для понимания степени, а Л. смещал ударения в словах («Chrome conSOLE») и это напомнило мне, почему так много компаний, выведших техподдержку на аутсорс в его стране, теперь переносили её в Филиппины.
Примечание: многие люди в комментариях начали называть меня ксенофобом за упоминание «акцента» Л. Наверно, немногие из вас встречались с реальной ксенофобией, потому что это явно не она.
Произношение Л. было таким же, как его работа: едва приемлемым, но не более того. Он был очень громким и его голос напоминал работу камнедробилки. Я был единственным англоязычным в группе разработки; всем остальным удавалось сохранять умеренную громкость речи и произносить слова так, чтобы их понимание не было пыткой.
Это никак не связано с акцентом. Я привык к иностранным акцентам. Это просто ещё одно проявление его посредственности.
Он не реагировал на то, что ему говорили и вносил изменения в поведение интерфейсов и API, не сообщая об этом никому. Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить, мы обнаруживали эти беспричинные изменения, только когда что-то ломалось.
Хуже всего было то, что у Л., похоже, каждые несколько минут происходила когнитивная перезагрузка. В той компании ветки Git были настроены совершенно неправильно — две master-ветки для одного репозитория, одна для фронтэнда, другая для бекэнда. Мой код криптографии относился к master-ветке фронтэнда. Мы говорили о ветках с упоминанием их названий примерно десять минут, и было совершенно понятно, что я выполняю мою работу во «frontend-crypto», которую мы упоминали много раз.
Внезапно он спросил меня, совершенно не к месту: «Крис, а в какой ветке ты работаешь?»
Подобные вещи случались много раз и менеджеры терпеливо объясняли ему то, что мог бы усвоить и восьмилетний ребёнок. Они видели, что он не понимает, но по какой-то причине это становилось проблемой только тогда, когда я выказывал своё недовольство необходимостью снова и снова объяснять простые вещи.
Плохой код
Обычно я работаю с семейством языков C и в веб-разработке пишу на C#. Мне пришлось выучить JavaScript, Python и Django. В результате теперь я почти исключительно пишу на JavaScript и работаю во фронтэнде. Обычно я бекэнд-разработчик; в том проекте всю работу по бекэнду выполнял Л.
Он выполнял много работы и вся она была низкокачественной. Он не соблюдал отраслевые стандарты и стремился выполнять как можно меньше работы.
Я пишу конечную точку
Мне нужен был новый API, который бы возвращал две или больше строк для получателей, присутствовавших или отсутствовавших в базе данных. Я не знаю Django достаточно хорошо, чтобы сделать это идеально, не понимаю, где заканчивается Python и начинается Django (мне сильно не нравится Django, в нём нет целостности и идиоматичности), но написал всю логику и коды состояний.
Допустим, я прошу этот API поискать ключи шифрования десяти людей. Вот найденное количество и коды состояний HTTP на моём плохом Django:
Возвращённое Код HTTP
количество
10 200 (полный успех)
1-9 206 (частичный успех)
0 204 (данные не найдены)
Ошибка сервера 500 (исключение)
Если ответ содержит меньше строк, чем запрошенное количество, то я возвращал массив их идентификаторов «not-found».
Я обратился к Л., чтобы он исправил мой синтаксис Django, но не переписывал логику, и вот что он сделал:
Возвращённое Код HTTP
количество
10 200 (полный успех)
1-9 200 (неправильно)
0 200 (неправильно)
Ошибка сервера 400 (неправильно)
То есть даже если не возвращалась ни единая строка, он называл это полным успехом и он удалил мой массив не найденных строк, поэтому клиенту пришлось бы перечислять возвращаемые данные, сравнивать с запросом и определять, какие из них не были возвращаены. А ошибка сервера возвращала 400, Bad Request, что совершенно неверно.
Этот человек должен был оказаться специалистом по бекэнду. Я ожидал, что он знает эти коды; я не знаю их все, но знаю с десяток наиболее распространённых. И даже имея на руках всю логику и требуемые коды состояний, он всё это выбросил и сделал «по-своему».
Ради справедливости надо сказать, что существует множество подходов к тому, как обрабатывать промежуточные уровни успешного выполнения действий API. Я почти никогда не видел никаких кодов состояний 2XX, кроме 200; 200 и 500 — это единственные коды, которые возвращает большинство разработчиков. Большинство разработчиков знает только три или четыре кода состояний. Л. знал два и один из них был неправильным.
Можно было бы благородно допустить что у Л. есть собственный подход, отличающийся от моего; на мой взгляд, если кодов больше, чем четыре, значит, на то есть причина, и поэтому я их использую. Однако уже проработав с ним несколько месяцев, я был уверен, что он просто скопипастил во все строки одну и ту же, вероятно, взятую с StackOverflow. Он сохранил мою логику фильтрации для всех заданных мной случаев (0, 1–9, 10), но вставил для всех них одинаковую строку.
Как бы то ни было, API — это транзакция, и если он изменил его поведение, то обязан был сообщить остальным о своих изменениях, потому что мы ожидали более подробных кодов состояний. Но он не только этого не сделал, но и никогда не отвечал мне, когда я его об этом спрашивал. Это непохоже на командную работу. Именно так мы всегда с ним и работали. Поскольку у проекта не было QA, то вероятнее всего, первыми дыры в логике увидят клиенты.
Реакция руководства
Я был в гневе. Я сделал всё правильно, за исключением синтаксиса Django, который он бы мог исправить за минуту, но вместо этого он переписал весь код, значительно изменив его логику. И разумеется, его код выглядел так, как будто на клавиатуре подрались два кота.
Я попытался спросить у Л., почему он внёс эти изменения, но когда он как обычно проигнорировал меня, я попросил менеджеров созвониться по конференц-связи. Я показал им то, что я написал сам. Они выразили своё недовольство и сказали, что поговорят об этом с Л. Не думаю, что они с ним говорили, потому что спустя две недели в коде ничего не поменялось.
И этому человеку платили.
Если они не поговорили с Л., то, вероятно, решили, что я вызываю в команде конфликты, хоть никогда мне об этом не сообщали. Это была моя последняя часть работы, всё написанное мной работало, за исключением этого испорченного API. Я закончил, освоил три новых языка и получил опыт в создании очень крутой реализации криптографии.
Я даже не старался больше поговорить с Л. Какой смысл? Он продолжал выполнять свой минимально допустимый уровень халтуры и в рамках его рабочей этики это было совершенно нормально. В предыдущих обсуждениях структуры проекта он не внёс ничего. Я мог бы заняться его менторством, но за несколько месяцев работы с ним уже понял, что он бы игнорировал меня и продолжал работать привычным ему способом: халтурным, кустарным и бессвязным.
Менеджеры, не знающие кода
Как и многие люди, утверждающие, что «навыки работы с людьми» важнее «навыков кодинга», менеджеры этого проекта были более заинтересованы в сохранении комфорта в команде, чем в создании качественного продукта. Поскольку для этого приложения была очень важна безопасность, требовалось работать максимально тщательно, но вместо этого они позволили оставить переписанный Л. код.
Вероятно, они восприняли мой отчёт как «трения» между мной и Л.; я нормально общался со всеми и у меня получалось скрывать своё недовольство Л., его постоянным загадочным забыванием контекста и ужасным кодом. Однако на этом моя часть работы была практически завершена и ситуация никак на меня не повлияла.
Вот что происходит, когда считаешь разработку ПО общественной деятельностью. Это совершенно точно не похоже на проектирование.
Но если бы я был руководителем, Л. уже бы искал другую работу.
Этика работы в разработке ПО — это спектр, в котором существует два полюса:
- Делать всё максимально идеально, и к чёрту все дедлайны
- Выполнять минимально возможный объём и сделать своим единственным приоритетом выполнение списка задач. Устранять слабые места написанием юнит-тестов (которых мы не писали).
Мы с Л. находились на противоположных полюсах этого спектра. Прибавим к этому его незаинтересованность в общении, и получим настоящий бардак.
На правах рекламы
У вас могут быть не лучшие коллеги, но за надёжные серверы вам не нужно волноваться. Наша компания предлагает серверы с Linux или Windows. Не экономим на железе — только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Chris Fox
===========Похожие новости:
- [Управление разработкой, Управление проектами, Agile, Удалённая работа] Обзор 10 бесплатных систем управления. Что даром, а за что придется платить
- [Промышленное программирование] О несомненной пользе применения современного оборудования Simatic
- [Анализ и проектирование систем, ERP-системы, Управление разработкой, DevOps] Как сделать хорошую интеграцию? Часть 2. Идемпотентные операции – основа устойчивой интеграции
- [Open source, Разработка под Linux, AR и VR, Игры и игровые приставки] Сегодня большинство Windows-игр отлично запускаются под Linux. Спасибо, Proton
- [Ненормальное программирование, PHP, Программирование, Математика] Двоичные и побитовые операции в PHP (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом, Карьера в IT-индустрии, Интервью] Product Owner vs Product Manager или Product Owner/Product Manager
- [Карьера в IT-индустрии, История IT] Путь в IT — воспоминания бумера, часть 1 из 3
- [Системное программирование, C, Изучение языков] 4 ошибки, которые легко и просто допустить в языке С
- [Карьера в IT-индустрии, Статистика в IT, IT-компании] Как пройти собеседование в FAANG: статистика
- [Управление проектами, Growth Hacking, Развитие стартапа, Управление продуктом] Как приоритизировать продуктовые гипотезы на основе юнит-экономики: разбираем примеры
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_karera_v_itindustrii (Карьера в IT-индустрии), #_plohoj_kod (плохой код), #_programmirovanie (программирование), #_upravlenie_proektami (управление проектами), #_blog_kompanii_vdsina.ru_hosting_serverov (
Блог компании VDSina.ru хостинг серверов
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:49
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В команде разработки завёлся разработчик, который халтурит, и ты ничего не можешь с этим поделать. Если у вас никогда не было такого опыта, я вам завидую. В былые времена у всех, от стажёра отдела QA до руководства, имелся какой-нибудь опыт кодинга. Те времена давно уже миновали, и теперь у нас есть несколько уровней «мастеров» методологии и менеджеров, за свою жизнь не написавших ни строки, считающих любые жалобы на чужую работу самовольством и личными конфликтами, а также не принимающих никакой критики своих технических навыков. Если я скажу, что тот или иной член команды халтурит, и даже объясню всё вежливо и с техническими подробностями, менеджеры воспримут это как «ссору» и сосредоточат всё своё внимание на сплочённости коллектива, подразумевая, что проблемы создаю именно я. Внешние факторы До недавнего времени я работал в распределённой команде, трудившейся на английскую компанию. Один из членов команды, которого я буду называть Л., не только писал ужасный код (подробнее об этом ниже), но и был в три раза громче всех остальных на ежедневных планёрках в Zoom. Своим пронзительным голосом, не заботясь о правильном английском произношении, он настаивал на том, что ему нужно показать свой экран, но на самом деле не демонстрировал ничего информативного — мы просто смотрели, как он двигает курсором мыши. Он обладал механистическими привычками. Его реакция на любую смену темы была всегда одинаковой. Настала его очередь говорить? «Давайте я покажу свой экран». Появилось сообщение об ошибке? Получайте полноэкранный скриншот в BMP с огромным прямоугольником, внутри которого самого сообщения почти не видно. Нужно объяснить ключевое слово? Ещё один скриншот. Спасибо, Л., мы ведь не знали, как пишется «foreign key». Я уже начал бояться созвонов, потому что его пронзительный громкий голос вызывал у меня головную боль. Все остальные члены команды освоили английский в достаточной для понимания степени, а Л. смещал ударения в словах («Chrome conSOLE») и это напомнило мне, почему так много компаний, выведших техподдержку на аутсорс в его стране, теперь переносили её в Филиппины. Примечание: многие люди в комментариях начали называть меня ксенофобом за упоминание «акцента» Л. Наверно, немногие из вас встречались с реальной ксенофобией, потому что это явно не она.
Произношение Л. было таким же, как его работа: едва приемлемым, но не более того. Он был очень громким и его голос напоминал работу камнедробилки. Я был единственным англоязычным в группе разработки; всем остальным удавалось сохранять умеренную громкость речи и произносить слова так, чтобы их понимание не было пыткой. Это никак не связано с акцентом. Я привык к иностранным акцентам. Это просто ещё одно проявление его посредственности. Он не реагировал на то, что ему говорили и вносил изменения в поведение интерфейсов и API, не сообщая об этом никому. Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить, мы обнаруживали эти беспричинные изменения, только когда что-то ломалось. Хуже всего было то, что у Л., похоже, каждые несколько минут происходила когнитивная перезагрузка. В той компании ветки Git были настроены совершенно неправильно — две master-ветки для одного репозитория, одна для фронтэнда, другая для бекэнда. Мой код криптографии относился к master-ветке фронтэнда. Мы говорили о ветках с упоминанием их названий примерно десять минут, и было совершенно понятно, что я выполняю мою работу во «frontend-crypto», которую мы упоминали много раз. Внезапно он спросил меня, совершенно не к месту: «Крис, а в какой ветке ты работаешь?» Подобные вещи случались много раз и менеджеры терпеливо объясняли ему то, что мог бы усвоить и восьмилетний ребёнок. Они видели, что он не понимает, но по какой-то причине это становилось проблемой только тогда, когда я выказывал своё недовольство необходимостью снова и снова объяснять простые вещи. Плохой код Обычно я работаю с семейством языков C и в веб-разработке пишу на C#. Мне пришлось выучить JavaScript, Python и Django. В результате теперь я почти исключительно пишу на JavaScript и работаю во фронтэнде. Обычно я бекэнд-разработчик; в том проекте всю работу по бекэнду выполнял Л. Он выполнял много работы и вся она была низкокачественной. Он не соблюдал отраслевые стандарты и стремился выполнять как можно меньше работы. Я пишу конечную точку Мне нужен был новый API, который бы возвращал две или больше строк для получателей, присутствовавших или отсутствовавших в базе данных. Я не знаю Django достаточно хорошо, чтобы сделать это идеально, не понимаю, где заканчивается Python и начинается Django (мне сильно не нравится Django, в нём нет целостности и идиоматичности), но написал всю логику и коды состояний. Допустим, я прошу этот API поискать ключи шифрования десяти людей. Вот найденное количество и коды состояний HTTP на моём плохом Django: Возвращённое Код HTTP
количество 10 200 (полный успех) 1-9 206 (частичный успех) 0 204 (данные не найдены) Ошибка сервера 500 (исключение) Если ответ содержит меньше строк, чем запрошенное количество, то я возвращал массив их идентификаторов «not-found». Я обратился к Л., чтобы он исправил мой синтаксис Django, но не переписывал логику, и вот что он сделал: Возвращённое Код HTTP
количество 10 200 (полный успех) 1-9 200 (неправильно) 0 200 (неправильно) Ошибка сервера 400 (неправильно) То есть даже если не возвращалась ни единая строка, он называл это полным успехом и он удалил мой массив не найденных строк, поэтому клиенту пришлось бы перечислять возвращаемые данные, сравнивать с запросом и определять, какие из них не были возвращаены. А ошибка сервера возвращала 400, Bad Request, что совершенно неверно. Этот человек должен был оказаться специалистом по бекэнду. Я ожидал, что он знает эти коды; я не знаю их все, но знаю с десяток наиболее распространённых. И даже имея на руках всю логику и требуемые коды состояний, он всё это выбросил и сделал «по-своему». Ради справедливости надо сказать, что существует множество подходов к тому, как обрабатывать промежуточные уровни успешного выполнения действий API. Я почти никогда не видел никаких кодов состояний 2XX, кроме 200; 200 и 500 — это единственные коды, которые возвращает большинство разработчиков. Большинство разработчиков знает только три или четыре кода состояний. Л. знал два и один из них был неправильным. Можно было бы благородно допустить что у Л. есть собственный подход, отличающийся от моего; на мой взгляд, если кодов больше, чем четыре, значит, на то есть причина, и поэтому я их использую. Однако уже проработав с ним несколько месяцев, я был уверен, что он просто скопипастил во все строки одну и ту же, вероятно, взятую с StackOverflow. Он сохранил мою логику фильтрации для всех заданных мной случаев (0, 1–9, 10), но вставил для всех них одинаковую строку. Как бы то ни было, API — это транзакция, и если он изменил его поведение, то обязан был сообщить остальным о своих изменениях, потому что мы ожидали более подробных кодов состояний. Но он не только этого не сделал, но и никогда не отвечал мне, когда я его об этом спрашивал. Это непохоже на командную работу. Именно так мы всегда с ним и работали. Поскольку у проекта не было QA, то вероятнее всего, первыми дыры в логике увидят клиенты. Реакция руководства Я был в гневе. Я сделал всё правильно, за исключением синтаксиса Django, который он бы мог исправить за минуту, но вместо этого он переписал весь код, значительно изменив его логику. И разумеется, его код выглядел так, как будто на клавиатуре подрались два кота. Я попытался спросить у Л., почему он внёс эти изменения, но когда он как обычно проигнорировал меня, я попросил менеджеров созвониться по конференц-связи. Я показал им то, что я написал сам. Они выразили своё недовольство и сказали, что поговорят об этом с Л. Не думаю, что они с ним говорили, потому что спустя две недели в коде ничего не поменялось. И этому человеку платили. Если они не поговорили с Л., то, вероятно, решили, что я вызываю в команде конфликты, хоть никогда мне об этом не сообщали. Это была моя последняя часть работы, всё написанное мной работало, за исключением этого испорченного API. Я закончил, освоил три новых языка и получил опыт в создании очень крутой реализации криптографии. Я даже не старался больше поговорить с Л. Какой смысл? Он продолжал выполнять свой минимально допустимый уровень халтуры и в рамках его рабочей этики это было совершенно нормально. В предыдущих обсуждениях структуры проекта он не внёс ничего. Я мог бы заняться его менторством, но за несколько месяцев работы с ним уже понял, что он бы игнорировал меня и продолжал работать привычным ему способом: халтурным, кустарным и бессвязным. Менеджеры, не знающие кода Как и многие люди, утверждающие, что «навыки работы с людьми» важнее «навыков кодинга», менеджеры этого проекта были более заинтересованы в сохранении комфорта в команде, чем в создании качественного продукта. Поскольку для этого приложения была очень важна безопасность, требовалось работать максимально тщательно, но вместо этого они позволили оставить переписанный Л. код. Вероятно, они восприняли мой отчёт как «трения» между мной и Л.; я нормально общался со всеми и у меня получалось скрывать своё недовольство Л., его постоянным загадочным забыванием контекста и ужасным кодом. Однако на этом моя часть работы была практически завершена и ситуация никак на меня не повлияла. Вот что происходит, когда считаешь разработку ПО общественной деятельностью. Это совершенно точно не похоже на проектирование. Но если бы я был руководителем, Л. уже бы искал другую работу. Этика работы в разработке ПО — это спектр, в котором существует два полюса:
Мы с Л. находились на противоположных полюсах этого спектра. Прибавим к этому его незаинтересованность в общении, и получим настоящий бардак. На правах рекламы У вас могут быть не лучшие коллеги, но за надёжные серверы вам не нужно волноваться. Наша компания предлагает серверы с Linux или Windows. Не экономим на железе — только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Chris Fox ===========Похожие новости:
Блог компании VDSina.ru хостинг серверов ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_karera_v_itindustrii ( Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:49
Часовой пояс: UTC + 5