Критерии оценки эффективности программиста

[valchkou]

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

У нас нет QA почти, все тестируется программистами и соответственно автоматизируется по макс, юнит тесты, автотесты.
Все что прог сморжил в основной бранч уже через день в продакшн!
У нас почти нет консалтеров, потому что консалтеры не отвечают за производимый ими код. А это важно в нашем продукте.
Весь менеджмент у нас технический, вырос из программистов, начиная от CEO, CTO заканчивая такими как я.
Именно поэтому, друзья, я и спросил вашего авторитетного мнения.
Я сам такой же программист ка и вы и прошел все стадии, начиная от никто в ташкенте и москве и до менеджера тут.
Я прекрасно осознаю что такое локи или баги или поинты. Я не мба выпускник и продолжаю сам контибутить и в гитхаб и в стаковерфло.
Не стесняйтесь своих детских комплексов, выскажите все что вы хотите тут и сейчас.
И возможно, уже скоро, не без моей помощи, это может превратиться в мейнстрим

[Komissar]

начиная от никто в ташкенте и москве и до менеджера тут.

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

[Херовимчик]

Автор, как программист, вы должны быть знакомы с Explore & Exploit алгоритмом. Это идеальное решение в вашей текущей ситуации свежеиспеченного менеджера. Ну и забудьте свои мечты о совмещении менеджерские и программирования, вы можете делать (хорошо) только одно. И как правило менеджерская часть вытесняет все остальное

[xrundel]

По каким метрикам или критериям вы бы хотели чтобы работодатель/руководитель оценивал вашу эффективность как специалиста?
Интересуют именно объективные оценки, которые можно предъявить лицом.

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

Оценивать нужно комплексно - начиная от LOC и заканчивая интуицией. Нет никакой универсальной формулы - всё зависит от проекта, от компании, от ваших полномочий, от команды. Бывает что оценивать не нужно совсем - скажем брeинсторминг, R&D. Бывает что LOC самое оно - особенно когда проект активно пишется с нуля. Бывает когда оценить нужно вообще написанную документацию а не сам код.


После работы с сотнями пограммистов у меня появился набор правил которые работают и набор правил которые не работают. Например, я точно знаю что LOC это неплохой дополнительный индикатор работы. Точно знаю что не нельзя работать с оффиса 3 дня и дома 2 дня. Точно знаю что хорошие пограмисты проявляют себя в первые 2 недели - дольше не имеет смысла принюхиватся. И т.д.

Со временем у вас появится свой набор многократно проверенных правил - мой лист для вас не подойдет.

[xrundel]

начиная от никто в ташкенте и москве и до менеджера тут.

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

Это так. Но на 10 талантливых пограмистов будет 1 талантливый менеджер который способен направить работу этих пограмистов в продуктивную сторону. Так что хорошие пограмисты это золото - но хороший менеджер это бриллиант.

[xrundel]

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

Ну конечно. Какой смысл писать код если у вас есть умение поиска и организации людей которые умеют писать код лучше вас.

[xrundel]

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

Лол. Это невозможно. Невозможно просить программиста оценить бизнес составляющую его труда - откуда он это знает? Задача оценки это и есть задача бизнеса. Например

A: "Цена ошибки огромная. Задача - сделать фичу что бы подключить большого клиента так что бы ничего не сломалось". Т.е. качественно, надёжно, дорого

B "Есть интересная гипотеза. Задача - как можно скорее проверить фичу - или она кому-то нужна вообще". Т.е. быстро и дешево

C: "Есть план разработки где фича должна быть запущена до Х. Потому что начинается маркетинг, потому что скоординирована работа многих людей" . Т.е. главное что бы было прогнозируемо.

Эти 3 разные задачи требуют 3-х разных методик оценок и конечно трансфер этого знания в команду.

[Komissar]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

[valchkou]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

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

[Komissar]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

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

директор это тот же манагер. Только управляет не IC, а другими манагерами. Вместо 2х проблем (начальство и подчиненные) тебе придется иметь дело с 3мя: начальство, подчиненные и подчиненные подчиненных.

Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

[BronenosezPotemkin]

Самое хорошее, что менеджер может сделать - это поменьше парить мозги всякими оценками эффективности. Считать строчки кода, серьёзно? У вас там, наверное, не программисты в подчинении, а секретари-машинистки.

[Херовимчик]

Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

+1
У менеджера первого звена ТС на равне с Sr IC, а местами даже меньше

[blanko27]

Теоритически, любая метрика качества бизнес процесса, после того как люди начинают ее оптимизировать, перестает работать (Goodhart's law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. Corollary: all metrics of scientific evaluation are bound to be abused). Поэтому выбирайте те, которые больше нравятся вам, это, в принципе, все равно.

[valchkou]

директор это тот же манагер. Только управляет не IC, а другими манагерами. Вместо 2х проблем (начальство и подчиненные) тебе придется иметь дело с 3мя: начальство, подчиненные и подчиненные подчиненных.
Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

какая разница сколько каких проблем, как будто у инженера их меньше. Главное тут ограничить их по времени, с 9 до 5.
это всего лишь вопрос оптимизации самого ограниченного ресурса. Как получить больше за единицу отработанного времени.
Ну а тем более, у нас менеджер это фактически тоже программист, поэтому кодить на уровне средненького сериора я еще не скоро разучусь.
Не получится водить руками, вернусь к плану Б или В.

[valchkou]

Теоритически, любая метрика качества бизнес процесса, после того как люди начинают ее оптимизировать, перестает работать (Goodhart's law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. Corollary: all metrics of scientific evaluation are bound to be abused). Поэтому выбирайте те, которые больше нравятся вам, это, в принципе, все равно.

был у меня один интересный момент, пришел ко мне постград, даю ему фактически первый таск закодить.
нужно перегнать данные из одного формата в другой, c кучей всяких if/else/case/catch. Я расписал входные/выходные параметры.
Вот приходит PR на ревью. Боюсь даже смотреть по опыту прошлых выпускников.
Гляжу в его код, а там .... красота! Все понятно, четко и структурно и тесты покрыты полностью.
Как оценить работу? Понятно что не по локам, и не по сложности. А приятно посмотреть и ревью я ему дал отличный.

Или вот другая история, выполнил человек работу, новая фитча, чтобы сконфигурировать и сохранить настройку.
Короче чел как то справился, все закодил, все работает, все счастливы, даже я.
Через неделю, обсуждаем план тестирования. Ну значит я ему говорю вот надо такие то варианты настроек проверить.
В ответ он меня убил своим вопросом - а как эти настройки сделать?
То есть чел потратил месяц, читал дизайн спеку, писал код, исправлял, деплоил, но так и не понят чего он делает то вообще.
Он даже не догнал что делает тулзу для вот этой вот самой настройки. И как тут оценить?

оба случая описывают мое субъективное восприятие, на основе которого и делаю оценку.
Я понимаю что первый чел мне нужен в команде и то что на рынке он underpriced.
Моя цель его удержать убедив руководство поднять ему бабос значительно. Во тут бы не помешали какие то доп показатели, которые бы выгодно отличали его от других спецов из других команд. Бюджет то не резиновый