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

В сообществе разработчиков программного обеспечения бродит неуловимый, но весьма достойный зверь: программист с 10-кратным увеличением.

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

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

Давайте сначала посмотрим на «количественную» часть: 10x, 100x, 1Gx…

Производительность: механистический взгляд

В какой-то момент, где-то в начале прошлого века, родилась концепция производительности.

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

Prod = Aw / Tw

Согласно этому простому определению, разработчик в 100 раз будет выполнять в 100 раз больше работы (AW * 100) или ту же работу в 100 раз меньше (Tw / 100).

Для проекта, который требует от «нормального» (а он вообще существует?) Программиста: 100 единиц работы за 100 единиц времени, наша SuperStar будет либо производить эти 100 единиц работы за 1 единицу времени, либо наоборот.

Вот проблема, с которой я столкнулся: «единица работы» и «единица времени» программиста никогда не являются постоянными по моему опыту.

Вы спросите, откуда я могу прийти к такой уверенности?

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

Органическое дисциплинированное упражнение для ума: попадание в зону

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

Пока я не дойду до этой сложной и скользкой «Зоны», где я с комфортом сижу в своем наиболее продуктивном апексе, я трачу свое время на подготовку к этому:
• Убедитесь, что мой контроль версий обновлен
• Думаете об именах - переменных, классах, функциях, интерфейсах… так много имен!
• Разделение труда между моими компонентами и связь между ними - интерфейс? общий объект? обратный звонок? RPC? очередь сообщений? HTTP? голуби? дымовые сигналы… подайте мне знак !?
• Информационное обеспечение - локальное, как свойство класса, частное, общедоступное, статическое,… выбор, выбор, всегда выбор
• Зависимости моей библиотеки, информационная зависимость
• Анализ моих параметров, обработка ошибок, возможные инъекции
• Мой поток непрерывной интеграции, шлюзы доставки, интеграционные тесты, системные тесты, у вас есть надо проверить Бруно!

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

Хорошо, возможно, это не всегда сумерки и единороги, в основном много кода.

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

Легенда гласит, что J.K. Для написания романов о Гарри Поттере Роулинг нужна была шумная кофейня, наполненная социальными взаимодействиями [интернет-легенда гласит, что в конце концов ей пришлось использовать маскировку, чтобы ее не узнали, чтобы написать последние…]. Также хорошо известно, что Альберт Эйнштейн - когда вы цитируете людей, давайте добиваться величайшего, не так ли? - не мог быть действительно эффективным, если не прерывал долгие периоды работы игрой на скрипке.

Мне? Я за отсутствие социального взаимодействия, тишину, музыку без пения и чай. Ага, я немного аутист.

Вот почему я твердо верю, что каждый отдельный работник умственного труда (включая программистов) имеет набор изменяющихся, сложных, зависящих от среды и рутинных действий, необходимых для достижения максимальной производительности. Если человек меньше спал прошлой ночью, съел слишком много рогаликов или был вынужден проводить в пробке на 20 минут больше обычного, пиковая продуктивность может никогда или частично не быть достигнута в этот день.

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

Многие исследования, книги и публикации подтверждают мое предвзятое мнение [1] [2] [3] [4] [5] о том, что для работника умственного труда «объем работы» и «количество времени» просто нелинейны и большую часть времени квазихаотический.

Следовательно:

Prod = rand (AW) / rand (Tw)

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

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

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

Как можно было это предсказать / смоделировать?

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

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

И, конечно же, вы хотели бы, чтобы все ваши сотрудники в идеале достигли максимальной производительности ОДНОВРЕМЕННО.

Удачи с этим!

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