Как оценивать эффективность разработчика

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

Главная хуйня, которую все делают — смотрят на скорость. Написал сто строк кода? Молодец! А то, что эти сто строк потом полгода всю команду ебут, потому что там багов как говна за баней — это уже не считается. Полный пиздец.

На что реально надо смотреть:

1. Качество кода, а не просто код.

   • Сколько говна вылезло? Баги в прод или на тесте, которые на этого человека повесили. Если после его пул-реквестов все тестировщики начинают материться сквозь слёзы — это знак.
   • Что говорят автоматы? SonarQube там всякий. Если он там вечно красный, а технический долг растёт как долг по кредиту — пидарас шерстяной, а не разработчик.
   • Как он код-ревью проходит? Если его каждый раз отправляют на доработку с десятью комментами «нахуя так?» — понятно всё. А если сам другим умные вещи пишет — ценный кадр.

2. Не гони лошадей, считай повозки.

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

3. Командная игра, а не соло-ебля.

   • Он других учит или только сам учится? Если новичок к нему подошёл, а он не послал нахуй, а объяснил — уже плюс.
   • Улучшает ли он вокруг себя что-то? Предложил скрипт, который всем жизнь облегчил, или завел шаблон для пул-реквестов — золотой человек.
   • Работает с легаси? Если лезет в код, который писался, когда Майнкрафт только вышел, и не ломает его — терпения ноль ебать, герой.

Вот смотри, как это в коде выглядит:

// Плохо: написал быстро, но все обосрутся.
public decimal CalculateDiscount(Order order)
{
    return order.TotalAmount * 0.1m; // А если order — null? И что за магическое 0.1? Пиздец.
}

// Хорошо: подумал на один шаг вперёд.
public decimal CalculateDiscount(Order order)
{
    if (order == null) throw new ArgumentNullException(nameof(order)); // Защита от дурака.
    const decimal discountPercentage = 0.1m; // Понятно named constant.
    return order.TotalAmount * discountPercentage;
}
// И ещё тесты на это написал, гад.

Итоговые правила, чтобы не быть мудаком:

• Забей на хуй на строки кода и коммиты. Их можно наебать, как угодно.
• Смотри на контекст. Человек мог весь спринт ковыряться в одном, но важном, дерьме. Это ценнее.
• Спроси коллег. Что тимлид говорит? Что тестеры думают? Мнение со стороны — оно как, ебать, рентген.
• Оценка — для роста, а не для ярлыка. Цель — понять, где человеку помочь, а не просто сказать «ты говно» или «ты молодец». Чтобы он дальше рос, а не в ус не дул.

Короче, оценивай так, как будто с этим человеком тебе потом ещё год работать. Хули тебе токсичный гений, который всех заебёт?