Обзор производительности инженера-программиста — это парадокс

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

Значения, стоящие за вниманием и видимостью, во многом определяют направление деятельности организации.

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

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

"Инженерия"

Чем работа по разработке программного обеспечения отличается от других?

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

Белые пятна в обзорах производительности

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

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

• Поддерживайте общую кодовую базу. Пишите/изменяйте код на основе огромного количества кода, написанного другими, и не нарушайте их.

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

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

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

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

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

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

Мы ожидаем, что квалифицированный инженер будет независимым и эффективным, что обеспечит доверие и полномочия по принятию решений, но также лишит стандартов и дисциплины всю команду и общую кодовую базу.

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

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

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

Долг

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

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

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

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

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

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

Взломщики KPI/OKR

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

• Если KPI/OKR сосредоточены только на выпуске фичи в этом сезоне, у инженеров нет причин заботиться о побочном эффекте для других и потенциальной проблеме некорректной реализации в будущем.

• Если в KPI/OKR нет ни слова об эффективности всей команды, инженерам незачем разбираться с наследством или автоматизировать какие-то процессы, это ведь не вознаграждение.

Вышеупомянутый факт является идеальным очагом, который питает хакеров KPI / OKR, которые отлично работают на обзоре, но на самом деле являются отрицательным капиталом команды (также известным как инженер 0,1x).

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

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

Переизбыток вакансий по программному обеспечению

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

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

Смена работы в более быстром темпе

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

Общество все больше способствует успешной карьере

На мой взгляд, первые два пункта изначально продиктованы этим.

При поиске в браузере слова «инженер-программист» вместо обсуждения навыков и знаний выдает множество переводов, собеседований и повышений.

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

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

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

Направления

Не решения, а некоторые направления, которые стоит попробовать.

Конкретно учитывать последствия для всей системы и долгосрочные последствия

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

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

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

Это хорошее время, чтобы общесистемное влияние и долгосрочные эффекты стали независимыми показателями, а не дополнительным примечанием при разработке функций. В конце концов, никто не хочет, чтобы их собственная программная система больше никогда не росла.

Раскрытие рисков

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

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

• Немасштабируемый дизайн не может обслуживать на 20% больше пользователей, чем текущий объем, ожидается, что переломный момент будет достигнут в следующем квартале.

• Хрупкая реализация может привести к фатальным ошибкам, если пользователь работает слишком быстро, что может привести к тому, что 5% пользователей удалят наше приложение.

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

Раскрытие информации о рисках не так уж и недоступно, многие широко распространенные инженерные методы имеют аналогичные эффекты, такие как...

Проверка кода

Искусственная версия «раннего выявления и лечения». Коммиты можно просматривать и оспаривать даже без видимых ошибок (если не интегрирован конвейер CI).

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

Написание тестов

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

Все, что делают для вас тестовые случаи, — это позволяет всем стать свидетелями предсказуемой катастрофы и не желать воплотить ее в жизнь вручную.

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

Хотя разоблачение недостатков в работе других иногда заставляет их чувствовать себя некомфортно, в конечном итоге команде приходится столкнуться с музыкой. Это займет время.

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

Эпилог

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

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

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

Также опубликовано здесь:https://softengineer.ghost.io/paradoxes-of-perf-review/