Spiiin's blog

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

• No silver bullet, все очевидные ускорения уже найдены, часто упираемся в сложность предметной области. Абстракции дают возможность сжимать код, но если он на каком-то этапе становится несжимаемым дальше из-за уникальности, то выигрыша не будет.
• Можно быть эффективным не только в кодинге. Есть еще, например, менторинг, координация, управление. По мере развития проекта, код становится в каком-то смысле деталью реализации, вторичной по отношению к продукту.
• Даже в программировании, есть не связанные скиллы. Кто-то лучше ориентируется в больших кодовых базах и сторонних библиотеках, кто-то находит и исправляет баги, создаёт прототипы, проектирует архитектуру и так далее. “Производительность” можно считать отдельно от скиллов, но сложно отследить, откуда именно она берётся.
• “10x” имеет нехорошие вайбы стартапов и привлекает эффективных менеджеров, которые хотят посчитать производительность так, чтобы уволить не достигающих KPI и нанимать только “от 10x” программистов.

Но, если убрать 10x, можно и порассуждать про различие эффективности при одинаковых скиллах.

Кейсы, которые я видел#

Когда люди работали сильно быстрее, чем “в среднем по больнице”:

Инженеры, сросшиеся с проектом. Знают весь код наизусть, из-за чего могут почти не глядя сказать, в каком месте нужно подкрутить, чтобы система восстановилась, и готовые ковыряться в ней всё рабочее и свободное время.
Альтернативный мейнстримному подход к разработке, ускоренные итерации после внесения изменения, выбор правильных инструментов (языки, методологии). Практически невозможно применить в командах, которые привыкли к мейнстриму. Часто противоречит общепринятым практикам. Например, “Все делают как редакторы как Unity”. Плюсы — общая терминология, похожий UI, отличия могут в деталях, хоть и серьёзные, но основа - одна. Минусы — в этой основе зашито многое, в том числе конфигурация команд, а иногда и рабочие процессы. Пример минуса — “серая зона” между программерами и тех/гейм-дизайнерами. “то как фича работает в движке, и то, как геймдизайнеры думают что она работает - две большие разницы.
Уникальные специализированные знания, позволяющие быстро (или в принципе) сделать то, что не могут другие. Это не касается эффективности при равенстве скиллов.

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

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

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

Во втором, когда был выбран более прогрессивный способ работы, сложно отделить производительность отдельного человека, можно оценить только расходы на создание всего продукта другим составом команды (условно, нужно не 10 программистов и 1 дизайнер, а 10 дизайнеров и 1 программист) и шагами процесса (нужно меньше времени на edit-compile-run-debug или меньше циклов profile-optimization) и возможно, его уникальные фичи, которые были бы невозможны с другими подходами.

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

• миф - “10х про правильный фокус на задачах”. Выловить только важное для проекта. Во-первых, кто-то должен делать и “неважное”,”выравнивать поле, по которому должны пробегать гипотетические “спринтеры”. Такие люди ценнее, хотя они и не попадут в 10х. Причем “неважных” задач оказывает раз в 10-20 больше.
• возможно, полезна способность быстро учиться. Это сложный навык — просмотр большого кол-ва инфы требует много времени. Даже просто чтобы перевести “неизвестное неизвестное” в “неизвестное известое”, требуется год-два. Кроме общих знаний — “слой надстройки” к технологиям внутри компании.

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

Формула производительности#

Производительность = Скилл x Приложенные усилия x Распреление сил

Скилл - знания, опыт. Достаточно тривиально в оценке.
Усилия - умение менеджить время, фокусироваться на правильных задачах в правильном порядке. Частично задача выбора фокуса может быть делегирована менеджерам и лидам.
Распределение сил - выбор способа как решать задачу. Искать готовые решения vs делать своё. Допустимо ли решить конкретную задачу небрежно, прототипировать ли решение vs изучить state-of-art приёмы, необходимо ли сейчас разобраться в архитектуре системы, изучить устройство функций или использовать их как чёрный ящик. хардкодить решение vs выносить способы настройки в скрипты/конфиги. Если выразить кратко, то это умение не делать over-engeneering и under-engeneering.

Если проводить аналогию с казино:
Скилл — это количество твоих фишек для игры
Усилия — это выбор, во что будешь играть
Распределение сил — это стратегия, по которой будешь играть

Вот это умение распределять силы и является наиболее отличающимся параметром, но и трудно измеримым (через собеседования или достижения в резюме).

Количество ресурсов на задачу всегда ограничено, а различных способов решения всегда несколько, отличаюшихся по различным измерениям качества (“способы решения” включают как способы писать код, так и выбор инструментов и методологии). Выбор различных подходов очень сильно влияет на результат, так что способность ориентироваться в этом многомерном пространстве способов проектирования серьёзно отличает производительность программистов.

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