Сразу два дисклеймера.  1. Да, все так плохо. 2. Такое название подход получил, поскольку аутсорсером из индии платили за количество написанных строк. В результате такой код становился излишне много сложный и непонятный.

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

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

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

👩‍💻 Программисты пишут код, давайте оценивать их по его количеству.

На первый взгляд логично, если ты много кода написал, то хорошо поработал, мало - плохо.

Лучший код – ненаписанный код.

⌨️ Хорошо, а давайте мерить код не строчками, а коммитами. Все коммиты будем объединять в один перед релизом. В итоге один коммит - одна фича.

Уже лучше, но только если фича А идентична фиче Б? А я за 10 лет не видел одинаковых фичей. В итоге если разработчик закрыл только одну фичу то результат ревью будет плохой. Даже если эта фича принесла компании денег. Не справедливо получается. И к тому же не мотивирует браться за сложные задачи.

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

💡 Хотя, возможно, руководство, которое его оценивает знакомо с ним, знакомо с его миссией, а значит для него сделают исключение.

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

🧒 А что рядовые сотрудники?

Им тоже хочется пройти ревью, поэтому они помимо рабочих задач думают еще и над тем, как обмануть систему. Сделать побольше коммитов. Написать больше строк кода. Сходить на большее число встреч. Завести больше тикетов, чтобы их # доблестно потом решить.

♾️ И что же теперь не оценивать?

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

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

А как в твоей компании оценивают разработчиков и менеджеров?