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

[Vladimir Kr.]

Я хочу чтобы мои программисты не выполняли тупо ТЗ а понимали для чего это будет сделано, видели систему более шире. Вся эта фигня баги, шмаги, ревью и т.д. в идеале должны отсутствовать.

вот-вот

Даешь еще больше митингов, чтобы программисты прониклись и широтой, и глубиной, и всей важностью, и проекта, и личностей на этих митингах заседающих!

Риторический вопрос: вот программистам оно это надо вся понимать, поверх того, что требуется по ТЗ?

[katit]

Риторический вопрос: вот программистам оно это надо вся понимать, поверх того, что требуется по ТЗ?

Смотря каким программистам. Вот вы себя хотите считать хорошим специалистом или заменимым винтиком?
Чтобы дать ТЗ "винтику" и при этом продумать все от А до Я требуется программист который напишет псевдо-код. Который после этого тот "винтик" перепишет с багами. Так мы про кого говорим?

Я понимаю что митинги это спать скучно. Что "дайте мнe ТЗ и от..сь" от меня. Но вот такой подход к делу - это $0 ценность сотрудника. Ну может если копать от забора и до обеда. Но если мы про интеллектуальный труд? То не, такие не надо.

[PrettyVacant]

Я понимаю что митинги это спать скучно. Что "дайте мнe ТЗ и от..сь" от меня. Но вот такой подход к делу - это $0 ценность сотрудника. Ну может если копать от забора и до обеда. Но если мы про интеллектуальный труд? То не, такие не надо.

Не в обиду, но тут вы косплеите то ли Черномырдина, то ли товарища Бывалова из "Карнавальной ночи".

[vdfs]

Да ладно вам, это крайности - псевдокод - может в рот положить и разжевать ещё? Понятно описанная задача в JIRA, с учетом что программист владеет доменными знаниями и примерно понимает, как система работает, занимает полэкрана и пишется за несколько минут со знанием дела.

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

Митинги с количеством человек больше 4-6 - пустая трата времени для большинства участников. Посмотрите, кто говорит, а кто нет. Такого не бывает, что вся толпа принимает участие. А потом помножьте просранное время тех, кто весь митинг молчал, на их часовой рейт. Вот вам и будет "$0 ценность сотрудника". А их устроили бы meeting minutes или та самая задача в JIRA. Но нет, надо сидеть и слушать, как другая команда обсуждает ненужные вам потроха их системы.

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

[alex_127]

Эффективный сотрудник - это когда жалко если уходит. Неэффективный - соответственно не жалко.

[nyekimov]

Эффективный сотрудник - это когда жалко если уходит. Неэффективный - соответственно не жалко.

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

Но все так сожалели.

Хотя может разве что само руководство не очень сожалело, потому что по его рассказам мне, на новом месте пообещали лишь бонус на 10% больше, хотя у нас бонус тоже есть, но ему не давали. Видимо жалко тоже имеет меру. На ту зп, за которую он работал, его жалко было терять. И тут же жалко было отсыпать больше денег из-за известной эффективности.

[katit]

А есть ещё третий вид - когда выпиваешь от радости что ушел

[uncle_Pasha]

Я хочу чтобы мои программисты не выполняли тупо ТЗ а понимали для чего это будет сделано, видели систему более шире.

В этом и заключается разница между кодером и инженеров (назовите его софтваре инженер).
Допустим, вы избавились от кодеров, и у вас только софтваре инженеры, все замечательные.
Как вы будете оценивать их эффективность?

[katit]

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

Вобщем нет формулы. Все мы человеки, кому-то нравимся а кому-то нет. Так что если вы босс то сами и решайте по своему разумению кто чего стоит

[valchkou]

Эффективный сотрудник - это когда жалко если уходит. Неэффективный - соответственно не жалко.

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

Но все так сожалели.

Хотя может разве что само руководство не очень сожалело, потому что по его рассказам мне, на новом месте пообещали лишь бонус на 10% больше, хотя у нас бонус тоже есть, но ему не давали. Видимо жалко тоже имеет меру. На ту зп, за которую он работал, его жалко было терять. И тут же жалко было отсыпать больше денег из-за известной эффективности.

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

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

[valchkou]

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

Вобщем нет формулы. Все мы человеки, кому-то нравимся а кому-то нет. Так что если вы босс то сами и решайте по своему разумению кто чего стоит

это так, но с другой стороны ревью которые я пишу как менеджер, видит мой подчиненный.
Это не анонимный, сайлент ревью. Вот значит я пишу что сотрудник не сделал то или это.
Ну И? как говорит валерий карпин, и почему ты мне сразу не сказал что от меня ожидается А и Б?
Это не честно. Если метрики кривые то об этом нужно было говорить сразу, чтобы не было сюрпризов на момент оценки.
Чел целый год работал.
Но совсем дургая история, когда ты говоришь, объясняешь, но как об стенку и тогда на ревью можно смело как есть высказать что продвижения не было.
Короче это я к чему, времена меняются товарищи. Просто так сказать что все плохо нельзя. Нужны факты, не субъективное восприятие а именно факты.
Вот спеца захайрили, это вам не россия, испытательного срока нет. Сам факт офера уже означает что meets expectations.
прятать метрики в рукаве будет все сложнее, поверьте моим словам.

[katit]

Могу посочувствовать. Я ревью делаю с глазу на глаз и никто ничего не видит. В офферах везде испытательный срок стоит. Но я пока могу так делать.

Вот как в метрику записать что работает как другие и при этом не выносит моск? Не шумит и не воняет например?
А это все бесценные вещи.

[valchkou]

Могу посочувствовать. Я ревью делаю с глазу на глаз и никто ничего не видит. В офферах везде испытательный срок стоит. Но я пока могу так делать.

Вот как в метрику записать что работает как другие и при этом не выносит моск? Не шумит и не воняет например?
А это все бесценные вещи.

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

[nyekimov]

Эффективный сотрудник - это когда жалко если уходит. Неэффективный - соответственно не жалко.

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

Но все так сожалели.

Хотя может разве что само руководство не очень сожалело, потому что по его рассказам мне, на новом месте пообещали лишь бонус на 10% больше, хотя у нас бонус тоже есть, но ему не давали. Видимо жалко тоже имеет меру. На ту зп, за которую он работал, его жалко было терять. И тут же жалко было отсыпать больше денег из-за известной эффективности.

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

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

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

Насчёт того, что предложил новый работадатель, то и есть рыночная цена, не совсем согласен. Я видел уже пару случаев, когда человек умеет хорошо или сносно болтать на интервью, а работает крайне не эффективно для зарплаты, которую дают. Собственно не из-за этого ли мы все заговорили об эффективности? Тебе ещё не приходилось никого увольнять? Хотя если фирма не большая и процесс отбора в своих руках, то шанс нарваться на совсем никакого чела крайне мал. Но я на каждой компании встречал минимум одного никакого чела, от которого потом были рады избавиться. Чем крупнее компания, тем количество таких выше. Pip-ы в фаанг со всем их замудренным интервью тоже тому пример.

Хотя тут как, с таким количеством компаний как в сша, можно избрать другую тактику и вне зависимости от метрик эффективности компаний менять работу каждые 2 года. Вполне можно себе выбивать каждый раз на 5-10 тыс больше. Если не больше. Я даже статью такую видел на фб от какого то портала, мол те, кто нынче не меняет работу раз в 2 года, те теряют много денег. Хотя все это тож спорно. Если бы ты сам скакал без цели, то так и не дорос бы до менеджера первого звена.

[nyekimov]

Кстати. Про вторую часть. Метрики оценки эффективности по результатам труда за отчетный период и на интервью не могут быть совсем одними и теми же. Это как в беге, бегать на короткой дистанции и бегать марафон - это две разные техники и вполне может быть два разных бегуна. Хотя я не спортсмен, не знаю. Нужно ли бегуну коротких дистанций тренировать технику марафона за одно, как по мне, это совершенно ни к месту.

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

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

Но лично встречал ни одного литкодера, который на короткой дистанции бегает олимпийски, натренировал руку. А как даёшь ему обычный Тикет, где надо сесть с кофе, вникнуть в детали, все риквайраменты, заметить недостающие детали, задать вопросы по ним и все чотко с тестами закодить. Так бегуну на короткие дистанции сразу становится не интересно. Я даже знаю такого; кто потом годик в Гугл поработал и попал на пип, я даже не удивился. Но видимо в фаанг такие исключения и их техника отбора по их подсчетам эффективна.

Но когда таким вот страдают не фаанг, я конечно фигею от части. Что бы они не говорили. Мое идеальное интервью наверное вот кстати было прийти на потенциальное место работы и провести с ними два тестовых дня. Макс три. Причём так, чтобы бросить можно было в любой момент, если видишь, что не твоё; то просто встаёшь и уходишь. Но понимаю, что такое очень сложно осуществимо.

[Сабина]

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

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

Кмк требования очень разные, в зависимости от title, а немного даже и от компании.
Я например вот эту книжку листала именно по той же самой причине. Задумалась над требованиям нормального менеджера - https://staffeng.com/book

[Falcon]

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

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

Кмк требования очень разные, в зависимости от title, а немного даже и от компании.
Я например вот эту книжку листала именно по той же самой причине. Задумалась над требованиям нормального менеджера - https://staffeng.com/book

Правильно. В этой книжке острова похожие на Гавайи, находятся на широте Cypress Pt. Я бы тоже задумался. И маршрут какой-то неправдоподобный.

[lxf]

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

Зато там ценятся "разгребатели".

[Сабина]

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

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

Эффективность программ, которые вы пишете и ревью вас, как работника, это не совсем параллельные вещи. Но первое наверное немаловажно.

Что касается программы, я как раз недавно релизнула проект где мне впервые за больше чем два года на текущем месте удалось сделать «по уму» как я хочу. А не «давай давай быстрее» как обычно просят. При этом потратила два месяца, существенно меньше чем скажем наш принципал тратит на похожий функционал.
Если вкратце, то вот что там эффективно с моей точки зрения. Придётся немного в детали того что приложение делает углубиться потому что без этого непонятно про эффективность.

Это real time streaming архив поискового индекса. Нужно сделать так чтобы из него можно было извлекать всякие insights для бизнеса, для наших технических задач и проч. До этого мы просто генерировали индекс и толкали в Solr. Архив существовал только для daily batch job, не для real time процесса. При этом мы архивировали только core часть индекса, а не окончательный индекс, у окончательного индекса динамическая модель, поля не fixed. Поэтому у него и schema то не было конкретной . Что то вроде {headers, list<Attributes>}. Ещё важный момент, мы не только updates, мы ещё deletes генерируем, на основе gazillions of business rules и отследить это можно только по логам в Кибане, муторно, без деталей.
Меня тут это убивало с первого дня, любой troubleshooting превращается в наследование, море впустую потраченного времён . Да, объемы данных тоже важны, мы генерируем 1ТВ индекса за неделю.

То что построила:
1) real time streaming app. Can work in batch mode too. One can switch between the two with a single config change, использовала Spark Streaming + Kafka integration
2) Data contract is enforced. Это очевидно, иначе как потом insights извлекать. Данные сбрасываются в GCS ( hourly buckets), поверху построила Hive and BigQuery tables, первая для интеграции с существующими ETL процессами, вторая для того чтобы бизнес и датасатанисты могли быстро анализировать. Я и сама уже нашла миллион применений, например выявила неиспользуемые больше поля индекса.
3) весь deployment в клауде ( GCP), запускается приложение через workflow templates. Одна команда создаёт Dataproc cluster, запускает Spark submit и подчищает потом кластер когда задача выполнена. Мы сейчас запускаем в batch mode, каждые 15 минут.
4) ну и как обычно alerts , metrics. Последнее в spark streaming практически out of the box, там query listeners - onProgress etc
Вот такие мои критерии . Посмотрим на ревью в следующем году во что выльется .

[valchkou]

Если вкратце, то вот что там эффективно с моей точки зрения.

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

Но эту метрику невозможно ни подтвердить ни опровергнуть, потому что ваш принципал конкретно этот проект не делал.
Другое дело было бы если он это делал и провалил, либо сделал криво. И тут вы, и за 2 мес и все красиво.

Все остальное это просто вода, описание проекта, да возможно хорошего, сложного, интесерного проекта.

[Сабина]

Если вкратце, то вот что там эффективно с моей точки зрения.

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

Но эту метрику невозможно ни подтвердить ни опровергнуть, потому что ваш принципал конкретно этот проект не делал.
Другое дело было бы если он это делал и провалил, либо сделал криво. И тут вы, и за 2 мес и все красиво.

Все остальное это просто вода, описание проекта, да возможно хорошего, сложного, интесерного проекта.

Отнюдь. Там описании метрик, которые любой менеджер сможет оприходовать - решение кучи наболевших бизнес задач, решение технических проблем, в дополнении low maintenance - efficient cloud deployment, one config switch between batch и real time. Это не считая желания следить за latest abs testers, умения поменять это в работе, освоить с нуля, решить бизнес задачи, эффективно использовав правильный open source

[valchkou]

Отнюдь. Там описании метрик, которые любой менеджер сможет оприходовать - решение кучи наболевших бизнес задач, решение технических проблем, в дополнении low maintenance - efficient cloud deployment, one config switch between batch и real time

метрики это то что можно измерить.
efficient cloud deployment - проект новый и эту часть он не упрощает. Так как его не было вообще, то наоборот это дополнительный deployment.
one config switch between batch и real time - а раньше вообще не надо было париться, то есть система была проще
решение кучи наболевших бизнес задач, решение технических проблем - это уже что то но слишком абстрактно.
технические проблемы были есть и будут и их решение ничего не меняет, если только не показать конкретный P&L для бизнеса.

Ну к примеру, как то был у меня проект, перевел я бизнесс процесс с оракла на кассандру за 4 мес.
В итоге расход на БД снизился со 150к до 18к в год и это только на железки и лицензии.

Но был еще один плюс - zero-down-time о котором давно просили клиенты. Только вот измерить эту часть невозможно.
Клиенты возможно стали немного счастливей, но скорее всего они даже ничего заметили, потому что с точки зрения бизнеса ничего не изменилось,
просто в какой то момент перестали приходить емайлы о planned maintainance.

[Сабина]

Ну так и это измерим ! Недавно только в продакшен деплоила.
А менеджер который не понимает как правильный open source сокращает development cycle и экономит силы и нервы команды на maintenance - это неправильный менеджер

[8K]

У меня однажды был забавный менеджер (он себя архитектором называл). Часть продакшен кода лежала в его личном гитхабе.

Куда мир катится.

[Сабина]

Нашла один критерий . Для тех кто в теме.
Отгадайте какой из них лучше ?