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

Всем привет! Меня зовут Владимир Кочетков. Хочу поделиться своими мыслями об эффективности программиста и ее оптимизации. Коротко о себе: работаю тимлидом в компании Nexteum, ранее в течение 7 лет руководил студией web-дизайна в Одессе, а также работал в краудфандинговом стартапе.

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

Результат работы программиста

«Дебажу Мыслю — значит существую», — говорил Рене Декарт. Но запомнился он не только этим, а еще и созданием прямоугольной системы координат. Давайте представим организацию, в которой вы работаете, в виде точки в многомерном пространстве. Оси координат этого пространства — это показатели деятельности компании, например: прибыль, оборот, расходы, доля рынка и т. д. Помимо текущих координат, организация имеет цель — новую точку в пространстве, к которой она стремится. Не всегда путь из текущей точки к целевой — это прямая линия.

Например, что важнее:

1. Оптимизировать код и сократить расходы на сервера и ускорить работу системы или внедрить новый функционал?
2. Выпустить обновление быстро, но не идеально работающее, или потратить больше времени на разработку и максимизировать качество?
3. Полностью переписать большой легаси-участок проекта или докинуть еще «гибких решений» и «пока» поработает?

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

Индустриальная эпоха оставила нам в наследство подход, при котором результат работы сотрудника пробуют выразить в числах за единицу времени. Например, в строках кода, багах, возвратах с code review, выполненных задачах, соблюдении сроков. Учитывая, что индустриальная эпоха сменилась информационной, то полагаю, если и стоит опираться на такие показатели, то в сложном проекте имеет смысл фиксировать только очень существенные отклонения (+/- порядок). Такое отклонение, в принципе, очевидно для руководителя отдела даже и без статистики.

Ресурсы работы программиста

Ресурсы в данном случае — это рабочее время всех участников процесса и стоимость этого времени. Чтобы понять момент, когда эти потраченные ресурсы уже можно подсчитать, нужно чтобы задача достигла статуса «Задача Безупречно Сделана» — то есть соответствует всем требованиям всех участников разработки.

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

Составляющие эффективности

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

1. Концентрация.
2. Балансирование.
3. Коммуникации.

Концентрация

Суть: невозможно знать все обо всем. Для максимизации эффективности нужно выбрать свою зону работы и по возможности отказаться от всего лишнего.

Каждая задача имеет контекст технологий, предметной области и особенностей проекта. Опыт работы увеличивает эффективность не глобально, а только в области, близкой к задаче. Если на каком-то участке нет активности, то происходит эффект «ледяной горки», то есть обратный процесс — когда эффективность будет снижаться. Интересно, что соотношение эффективности программистов разного уровня может достигать 1 к 100, и не так уж много профессий имеют такое соотношение.

Предположим (это только пример):

• зарплата Junior — $500;
• зарплата Senior — $5000.

Проект большой и сложный по всем направлениям — технологии, предметная область, особенности проекта. Junior потратил много времени на вникание и выполнил задачу за 80 часов. В итоге расходы организации — $250. Senior потратил 1 час (сделал примерно в 100 раз быстрее), расходы компании — $30.

Вывод: стоимость Senior в 10 раз выше, чем Junior, но его эффективность для компании может быть в 10 раз больше. Также, Senior выполняет множество полезных задач для компании, без которых развитие сложного проекта рискует остановиться.

Чтобы оптимизировать работу Junior-а, имеет смысл концентрировать его работу на максимально узком участке и на простых задачах.

Пример из жизни

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

Около года назад я плавно передал этот участок кода новому сотруднику уровня Junior. Он освоился на нем за пару месяцев и продолжает поддерживать до сих пор. Если его попросить запустить перегенерацию данных для целей тестирования в dev-окружении, через 5 минут запуск будет выполнен. Когда мне самому потребовалось выполнить эту операцию — на нее ушло около часа. Причина простая: я давно не делал этого и пришлось вспоминать, что там и как, и еще смотреть, что изменилось со времен, когда я работал над этим участком.

Балансирование — нужно больше bitcoin золота!

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

Поговорим о следующих вещах:

• золотая середина;
• золотое сечение;
• золотой молоток.

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

A___________B______________________C

AB / BC = BC / AC

A___________B1___(25%)__B2__________C

Собственно, балансирование — это движение между точками В1 и В2 (в зависимости от ситуации).

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

Пример из жизни

Задача: есть список веб-адресов в текстовом файле. Нужно проверить каждый на предмет того, выдает ли ошибку при обращении (код 500 ответа сервера). Периодически эту проверку перезапускать с новым исходным файлом.

Когда я делал эту задачу пару лет назад, потратил на нее 8 часов. Почему так много? Потому что начал преждевременное планирование развития проекта и думал в следующих направлениях:

1. Источник данных. Сейчас это один файл. А дальше может быть несколько файлов, а еще база или несколько баз. Следовательно нужно собрать данные из предполагаемых в будущем источников данных в один массив.
2. Валидация. Сейчас это проверка на один вид ошибок. Завтра попросят еще несколько проверок. Например, для разных источников данных разный массив валидаторов. Флешбек на первый пункт про источники... а еще может быть привязка валидации не к источнику данных, а к конкретным адресам по каким-то правилам.
3. Результат. Сейчас нужно просто список урлов с ошибками. Например, в виде файла. А завтра попросят еще отчет на почту и еще что-то в базу сохранить. Таким образом и тут получаем массивы форматтеров результатов работы, которые также можно привязать к источникам данных.

На реализацию, как уже говорил, ушло часов 8. А знаете что реально запросил бизнес? Ничего.

Инструментом пользовались пару месяцев без каких-либо изменений. Потом необходимость в нем отпала. Если рассмотреть крайности в вариантах реализации этой задачи, то получим ультрабыстрый вариант из семи строк и 15 минут на реализацию и мегакрутой вариант с множеством «функций на будущее»:

• Возможность запуска из разных интерфейсов (консоль/веб/крон).
• Предварительная валидация корректности указанных в источниках данных адресов.
• Многопоточная обработка, реализованная через очередь заданий в Gearman.
• Схема привязки валидации может быть очень гибкой и реализованной через систему правил с наследованием от более общего контекста на частные случаи.
• А еще связку валидатора и источников данных можно редактировать из админ интерфейса с разграничением прав доступа и логированием действий администраторов.
• Ну и, конечно, все нужно покрыть всеми видами автотестов, вынести каждую мелочь в отдельный репозиторий для повторного использования в микросервисах и написать многостраничную документацию.

И вот — 15 минут реализации превратились в пару недель или месяцев.

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

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

1. Я сделал X.
2. Теперь, для того, чтобы сделать Y.
3. Мне нужно всего лишь...

По логике дальше должна следовать буква Z, но если X и Y — это буквы не английского алфавита, то продолжение может быть другим. Ожидания тут могут не сойтись с реальностью по следующим причинам:

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

Коммуникации

Суть: живое общение лучше тысячи книг.

Можем ли мы сами судить о качестве технических решений, которые принимаем? Острая нехватка времени и необходимость компромисса между качеством и скоростью, когда разработчик сам понимает, чем пожертвовали и ради чего — это одна ситуация. Но есть еще другой аспект — назовем его так: «Мы не знаем того, что не знаем». Идея в том, что программист может сам не осознавать свою некомпетентность в каком-то узком техническом вопросе. У него есть решение задачи, и оно как-то работает. Но можно ли быть уверенным что это оптимальное решение?

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

Пример из жизни

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

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

Финал

Друзья, возможно, кто-то из вас ожидал найти в этой публикации рекомендации либо алгоритм в стиле «сделай вот это и вот это, и будет всем счастье». Но, по-моему, такие советы обычно банальны и не имеют реальной практической ценности. Проекты и компании разные. Люди, рынок, цели, приоритеты — все у всех разное.

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

Images by Florent Hauchard