👳♂️ Индусский подход в оценке программиста, все так плохо?
Сразу два дисклеймера. 1. Да, все так плохо. 2. Такое название подход получил, поскольку аутсорсером из индии платили за количество написанных строк. В результате такой код становился излишне много сложный и непонятный.
Я как-то писал о проблемах, которые возникают почти во всех больших компаниях, во время проведения
регулярных ревью.
Если коротко, то проблема в том, что оценивает сотрудников человек который ничего не знает о сотруднике, лично не знаком, личный вклад быстро оценить не получается. А нужно, поскольку людей на ревью много, и погружаться в ситуацию каждого разработчика долго и лень.
Логичным решением придумать какие-то исчисляемые показатели. Чтобы свести всех сотрудников в одну табличку отсортировать по грейду, и выбрать самых лучших, и самых худших.
👩💻 Программисты пишут код, давайте оценивать их по его количеству.
На первый взгляд логично, если ты много кода написал, то хорошо поработал, мало - плохо.
Лучший код – ненаписанный код.
⌨️ Хорошо, а давайте мерить код не строчками, а коммитами. Все коммиты будем объединять в один перед релизом. В итоге один коммит - одна фича.
Уже лучше, но только если фича А идентична фиче Б? А я за 10 лет не видел одинаковых фичей. В итоге если разработчик закрыл только одну фичу то результат ревью будет плохой. Даже если эта фича принесла компании денег. Не справедливо получается. И к тому же не мотивирует браться за сложные задачи.
Но может быть еще хуже. Например, компания очень активно растет, и старший разработчик пол года занимался собеседованиями. А потом онбордил новичков. Отвечал на бесконечное количество вопросов. Решал проблемы с доступами. Планировал и нарезал задачи. А вот код не писал - не было времени. Он тоже не пройдет ревью?