С какими людьми не хотел бы работать

О типах коллег, с которыми работа становится сложной

Сразу хочу подчеркнуть — я не делю людей на «хороших» и «плохих». За 10+ лет в разработке я работал с сотнями коллег, и абсолютное большинство были профессионалами, с которыми даже в случае разногласий находился общий язык. Однако некоторые типы поведения и установки действительно создают токсичную среду, тормозят процессы и снижают качество продукта. Речь не о личной неприязни, а о паттернах, которые вредят команде и проекту.

1. Люди с установкой «Not My Problem» (NMP)

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

// Пример из жизни: разработчик видит проблему в API, которое использует его фронтенд
// Плохой подход (NMP):
function fetchUserData() {
  // API возвращает данные в неконсистентном формате, ломая UI
  // Но разработчик просто обрабатывает ошибку, не сообщая бэкендерам
  return fetch('/api/user')
    .catch(err => console.error('API сломался')) // И всё
}

// Хороший подход:
async function fetchUserData() {
  try {
    const response = await fetch('/api/user');
    const data = await response.json();
    if (!data || !data.id) {
      // 1. Логируем проблему для отладки
      // 2. Создаём тикет в Jira/Bэкенд
      // 3. Временно адаптируем фронт, но помечаем как костыль
      reportDataInconsistencyToBackend(data, 'User API');
      return fallbackUserData(data);
    }
    return normalizeUserData(data);
  } catch (err) {
    reportErrorToMonitoring(err, 'fetchUserData');
    throw err;
  }
}

Почему это проблема: Продукт — это живой организм. Проблема в одном месте рано или поздно аукнется в другом. Культура «все мы отвечаем за продукт» критически важна для качества.

2. «Hero Developers» — те, кто создаёт культуру героизма

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

• Они создают «bus factor» = 1 — если такой человек заболеет или уволится, проект встанет, потому что только он знает, как работает «его» часть системы.
• Они не документируют, не пишут тесты, не передают знания, потому что «нет времени» и «я сам быстрее».
• Они неявно устанавливают нездоровую планку для всей команды, создавая давление: «Раз Ваня работает ночами, почему мы все так не делаем?»

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

3. Коллеги, отвергающие конструктивную критику кода

Речь не о холиварах («React vs Vue»), а о фундаментальных вещах: читаемости, архитектуре, безопасности. Когда на code review приходят комментарии вида «это можно сделать проще» или «тут потенциальная утечка памяти», а в ответ — агрессия или игнорирование («и так работает»).

// Проблемный паттерн: защита своего кода как личной территории
// Критикуемый код:
const processItems = (items: any[]) => {
  let r = [];
  for (let i = 0; i < items.length; i++) {
    if (items[i] && items[i].status === 'active') {
      r.push({ ...items[i], processed: true });
    }
  }
  return r;
}

// Конструктивный комментарий на ревью:
// "Предлагаю использовать `filter` и `map` для лучшей читаемости.
// Также тип `any` стоит уточнить."
// Плохая реакция: "Мой код рабочий, не трогай. Ты придираешься."
// Хорошая реакция: "Согласен, так действительно яснее. Исправлю."

Code review — не экзамен, а коллективное улучшение кодовой базы. Его цель — найти лучший путь, а не унизить автора.

4. Те, кто саботирует процессы команды

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

5. Люди с хроническим негативом и позицией жертвы

«Наш менеджмент идиотский», «задача нереальная», «техдолг нас похоронит», «все вокруг делают всё не так». Постоянный пессимизм, не подкреплённый попытками что-то изменить, — это вирус. Он убивает мотивацию, инновации и желание брать на себя ответственность. Сложные задачи и проблемы есть везде. Ценность коллеги — в том, как он с ними работает: ищет решения, предлагает альтернативы, помогает другим, а не в том, как мастерски их описывает.

Важный итог: речь о поведении, а не о людях

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

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

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