Как быть с некомпетентным лидом?

Итак, мы команда из двух человек, непосредственно подчиняющихся нашему директору. У меня 4-5 лет опыта, а у моего товарища по команде более 20 лет опыта. По понятным причинам он мой ведущий. Мы оба программисты, и мы напрямую взаимодействуем с нашими клиентами.

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

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

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

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

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

Как передать это сообщение?

Если вы команда, то его код — это ваш код, и вы в равной степени отвечаете за все части каждой системы. Если вы не так себя ведете, то вы не команда.
Кстати, название вашего вопроса говорит о том, что вы никогда не сможете эффективно общаться с этим человеком. Ваш титул указывает на то, что вам не хватает базового уровня уважения, необходимого для позитивного взаимодействия.
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: Нет, это не так. Я встречал разработчиков с 4-5-летним опытом, которые могут кодировать штаны другого разработчика с 20+ годами опыта.
Если ваш директор должен одобрить производственный код, означает ли это, что он считает «быстрый и грязный код» вашего лидера приемлемым в соответствии со стандартами компании?
@ДжимГ. Пожалуйста, не злоупотребляйте синтаксисом кода для кавычек. Курсив в сочетании с обычными кавычками является предпочтительным методом цитирования комментариев.
Либо этот человек является руководителем группы и, следовательно, отвечает за качество кода, либо вы равны и подчиняетесь тому же менеджеру. Ни в том, ни в другом случае вам не придется защищать его плохой код. Голосование за закрытие.
Я думаю, что некоторые люди делают предположения о том, как что-то может быть сделано на рабочем месте ОП. Абсолютно не всегда верно, что в команде все «одинаково ответственны» за продукт. ОП должен исправлять то, что он может, в рамках ограничений ситуации и не жаловаться в критический момент исправления, НО это не означает, что он должен брать на себя ответственность за работу другого человека, когда его об этом спрашивают.
Система управления исходным кодом вашей компании должна иметь возможность воспроизвести каждую предыдущую версию кода и должна регистрировать, кто ее проверял. В ПАПКЕ, ГОТОВ К ПОКАЗУ. Если неизбежная встреча пройдет хорошо, они вам не понадобятся, и вы не будете их вызывать. Если они начнут обвинять вас в его беспорядках, вы скажете: «Прежде чем мы продолжим, я думаю, вам нужно кое-что увидеть». а затем откройте папку и покажите им список курящих.
Да, этим вы наживете себе врагов. ОДНАКО, они уже решили сделать ВАС назначенным козлом отпущения в тот момент, когда начали наваливать на вас кучу. Вот почему вы не добровольно это делаете. В ЭТОМ МОМЕНТЕ они нажали на курок, и не ваша вина, что он взорвался им прямо в лицо.

Ответы (5)

Прекратите работать в бункерах.

Чем больше у вас культуры «оставаться на своей половине кодовой базы», ​​тем больше вероятность того, что:

  • код пойдет не так, потому что никто не задает вопросов
  • вам потребуется много времени, чтобы найти и понять код, когда что-то пойдет не так
  • вы не можете объяснить, почему были приняты проектные решения
  • вы в конечном итоге сломаете что-то еще, когда «исправляете» код, который никогда раньше не видели
  • в итоге ты выглядишь так, будто не понимаешь этого.

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

Прямо сейчас вы можете попытаться быть немного более дипломатичным:

Боюсь, я не знаком с этой частью кодовой базы.

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

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

... но это не сработает в следующий раз.

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

  • Делайте обзоры кода.
  • Попробуйте документировать код друг друга, объясняя крайние случаи и т. д.
  • Убедитесь, что весь ваш код протестирован. Запустите покрытие кода для ваших тестов.
  • Разделите задачи так, чтобы один из вас писал тесты, а другой создавал код, соответствующий тестам. Поменяться ролями.
  • Когда появится новая разработка, попросите, чтобы вам назначили задачи, которые заставят вас работать с кодом, который вы раньше не использовали.

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

Мне еще предстоит найти способ привлечь «быстрых и грязных» кодеров к написанию тестов для их кода. Чтобы этот ответ был более полезным, вы можете предложить несколько предложений по этому поводу.
Есть два типа «быстрых и грязных» кодеров, с которыми я сталкиваюсь. Тем, кто неопытен и не знает лучших способов. Такой тип поддается дрессировке. Кроме того, есть опытные «быстрые и грязные» кодеры, которые также не знают лучших способов, но считают свой путь оптимальным. В конце концов, нет времени использовать эту новую заумную штуку под названием дизайн. Таким образом, обучение не имеет никакой ценности, потому что они считают, что должны быть учителями. В любом случае, я так и не понял, как обойти этих людей. 20+ лет и все еще пытаюсь :(

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

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

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

Simple state that for this particular case, there is a useful pattern you've had success with.- Имя для этого обучения.
@JoelEtherton Спасибо ... Я исправил формулировку. По сути, моя точка зрения состоит в том, чтобы не читать лекции и не проводить занятия, как будто он чего-то не знает. Простое заявление «Шаблон А работает здесь» работает, но «Шаблон А — это то, где вы делаете то и это. Преимущества в том, что он хорош в том или ином случае. Вы можете понять, когда использовать... [и т. ". Это значение слова «учить», которое я собирался использовать.
Я могу это выкопать. Я просто хотел отметить, что проверка кода — бесценный инструмент обучения, но суть в том, чтобы непредвзято относиться к тому, что может быть идея получше.
Проверка кода — это не волшебство. Некоторые разработчики очень оборонительны, и проверка кода не изменит этого.

Решить проблему

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

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

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

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

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

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

Как справиться с вашей текущей ситуацией.

  1. Скажите, что этот код не был вашим проектом.
  2. Вы исправили только конкретную ошибку (не весь проект/файл), чтобы предотвратить нестабильность.
  3. Предложите, как можно улучшить процессы в целом.
  • Встретьтесь со своим директором и объясните свое конструктивное несогласие со стилем кодирования вашего руководителя группы. Используйте такт.
  • Приготовьте примерно 3 примера кода, архитектуры или процесса, которые поддерживают вашу точку зрения.
  • В зависимости от характера ситуации и личности руководителя группы, вы можете захотеть пригласить руководителя группы на эту встречу.
  • Объясните свою точку зрения, но не спорьте с директором. Прислушайтесь к его/ее мнению. Будьте готовы завершить встречу менее чем через час.
  • Покиньте собрание. Закончи свой день. Иди домой. Обедать. Идти спать.
  • Во время поездки на работу на следующий рабочий день оцените встречу с директором. Был ли он/она справедливым?
    • Если «да» (даже если он/она не согласен с вашей точкой зрения), то будьте готовы скорректировать свой образ действий (другие люди дали несколько полезных советов).
    • Если «Нет» или вы чувствуете, что не можете сосуществовать с этим тимлидом, то у вас есть два варианта: 1. Спросите у своего директора, можно ли вам перевестись в другой отдел. 2. Начните искать новую работу.

Подробнее о совете «Начать поиск новой работы»:

  • Используйте этот вариант только в крайнем случае.
  • На работе (и в жизни в целом) старайтесь изо всех сил видеть точку зрения другого человека.
  • Но в конечном счете, если вы не можете заставить что-то работать, вам следует начать искать новую работу. Жизнь слишком коротка, а вакансий программистов предостаточно.
Как быть с некомпетентным лидом?
СпросиСетьПолитика конфиденциальности1y, 0v