×

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

Всем привет! Меня зовут Владимир Кочетков. Хочу поделиться своими мыслями об эффективности программиста и ее оптимизации. Коротко о себе: работаю тимлидом в компании 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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




45 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую за статтю :)

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

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

Юрий, здравствуйте!

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

Не совсем понимаю как указанная Вами формулы «ресурсы-время-качество» относится к теме максимизации эффективности. Думаю всем очевидно, что время, это также ресурс. Исходя из этого эффективность = результат (качество) / ресурсы (в том числе время). Максимизация эффективности может быть выражена в простой схеме: зафиксировав требуемый уровень качества, ищем варианты минимизации расхода ресурсов, или наоборот зафиксировав ресурсы (бюджет и время), ищем варианты максимизации качества. Кроме такой простой схемы можно еще представить вариант при котором каждый из параметров не фиксируется жестко, а описывается приемлемым диапазоном.

Т.е. чувак, который уволился с одесской галеры и приполз веслать на самую занюханную шлюпку Николаева в которой рабовладелец чуть что угрожает поломать тебе руки и «начистить ****» будет учить остальных эффективности? БРАВО!

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

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

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

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

Вы по поинтересуйтесь у николаевских гребцов проекта carID про товарища Книжника, много интересного узнаете... Да, мне сложно считать себя обиженным, я никогда не работал на CAMOIT или Onyx Enterprises ну или как там их щас звать, а, Nexteum... Я уже молчу как вышеупомянутый товарищ вставил весь офис на бабло с помощью СБУ...

Уважаемый Виктор, исходя из ваших слов Вы не сотрудничали с компаниями упомянутыми выше. Исходя из того что пишите фантазии о СБУ — Вы не в кусе каких либо событий.
В связи с чем вопрос: представители нашей компании Вам где то дорогу перешли и вы теперь сердитесь, из одного города вроде, мож в детстве что))?

О, видимо у моих друзей богатая фантазия ) ладно, я просто оставлю это тут: news.pn/ru/public/91559

Как то что написано в статье пересекается с чем что я «вышеупомянутый товарищ вставил весь офис на бабло с помощью СБУ» в статье рассказывается о том что милиция с прокуратурой проводили обыск, искали незаконный софт, не нашли, после чего дело закрыли.
При чем тут СБУ/вставил?
Виктор, вы фантазер.
Жалко что ваши фантазии выплескиваются в статье которую вы за свою жизнь не напишите.

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

Так у Вас есть что сказать, или Вы просто решили вылить гноя туда о чем не имеете представления? Или есть факты за которые Вы готовы ответить? Если бы представители компании были не отвечали за слова, а IT компания «кидала» — она бы не выжила.
Рядом много других.
Я повторяю: вы болтун, «распятого мальчика» не существует.
На вашем месте я бы извинился. За то что распространяю вранье.

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

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

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

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

А еще, Александр, если вы сочли мой комментарий стоящим регистрации на DOU (если это конечно вы, а не очередной тролль) и ответа на него — значит не все так чисто как Вам хочется

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

ех, я думав, буде стаття про Sex & Drugs & Rock & Roll :)

Перший варіант такий і був, а потім подумав — навіщо писати про очевидні та загальновідомі речі?

Эти компоненты входят в блок «Концентрация»

Вроде все правильно написано, а вызывает какой-то внутренний протест.
А потом я понял — вопрос здесь в неправильных бизнес-практиках.
Все три случая из жизни исключаются простыми организационными методами:
1. Тщательным тестированием и документированием неочевидных мест.
Любое конфигурирование, билд и добавление-удаление функционала сохраняется в виде краткой HowTo с указанием в каком окружении делалось.
Опять же убеждаемся, что работает это не только на единственной девелоперской машине.
2. Тщательное прописывание ТЗ, а также роадмеп проекта на видном месте очень хорошо избавляют от лишних телодвижений.
3. Краткий глоссарий предметной области, также непротиворечивое ТЗ избавит от перегрузки излишней информацией.

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

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

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

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

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

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

У всех нас разный жизненный опыт, разные ассоциативные ряды. На основании моего опыта — не вижу как указанные рекомендации могут приводить к необходимости магической материализации Senior разработчиков или острой необходимости их хантить, а не выращивать.
Возможно у Вас другой опыт или я о чем то важном не знаю. Если это так — расскажите. С удовольствием прочитаю.

Когда будет видно что с простыми задачами все хорошо — можно плавно повышать сложность.

С такой постановкой обучения я согласна.

Концентрація не може бути складовою ефективності. Тому що можна сконцентруватися на досягненні цілі, яка не потрібна бізнесу. А це означає банально нанесення прямих збитків. Концентрація може бути мультиплікатором, але цей мультиплікатор може бути як для позитивних речей, так й для негативних. Приклад з життя. Ми 4 місяця пилили фічу, яку, як нам розповідали клієнти, всім потрібна. Результат — нею ніхто не скористався протягом року. Ефективність роботи — мінусова.

Балансування можна розглядати, але знову ж таки, програміст думає як програміст. Бізнес-мислення в нього зазвичай відсутнє як клас, що й було продемонстроване в статті. Це означає, що він буде балансувати на тому рівні, який доступний йому: балансування витрат бюджету. Через ці обмеження, балансування може бути взагалі не ефективним, бо треба робити бізнес-балансування, а не на рівні виконання задачі.

Комунікації теж слабко впливають на ефективність в певних випадках. Тому що є як мінімум три варіанти побудови бізнес-моделі: 1. Ви робите те, що хочуть замовники. 2. Ви робите те, що хочете ви та нав’язуєте своїм замовникам ваше бачення. 3. Ви міксуєте два підходи. Для кожної бізнес-моделі комунікації несуть різну ефективність. В першому випадку ви мусите слухати, в другому можна цього не робити. Вам немає сенсу комунікувати у варіанті номер 2, бо ви й так знаходитеся попереду ринку та комунікувати мусять з вами, а не ви.

Я зазвичай провожу іншу оцінку ефективності: самостійність (скільки ресурсів треба витрачати на обслуговування процесу виробництва), перфекціонізм (тут зав’язана купа різних наслідків), аналіз (чи може людина витягти додаткову інформацію з тієї, що в неї вже є)

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

Олександр, Ваш коментар є найбільшим та торгаеться всіх ключових елементів статті. Це дуже приемно. Давайте розглянемо запропоновані Вами аргументи детально.

Концентрація.
Можливо вийшло деяке непорозуміння або термінологічна плутанина, бо приколад який Ви наводите майже ніяк не пов’язаний із поняттям "концентрація«у тому значенні яке я показував у статті. Давайте ще раз — у кожній задачі ми маємо контекст технологій, предметної області на особливостей проекту.

Я періодично бачу резюме розробників які у розділі навичок через кому перелічують всі слова які чули, можли сподіваючись взяти кількістю. Встановити python та за допомогою tensorflow порахувати векторну відстань між словами у моделі Word2Vec можна за 2-3 години (я це знаю бо робив сам не маючи попередньо жодного досвіді у роботі із вказаними технологіями). Деякі спеціалісти на основі такого досвіду можуть додати декілька слів до резюме. Я наводжу цей приклад, тому що хочу показати що є концентрація відштовхуючись від супротивного — розпорошення. Одна людина фізіологічно не може одночасно бути експертом у великій кількості технологій. У науковій сфері тільки на ранніх стадіях розвитку обсяг інформації був настільки малим, що одна людина могла досягати високих результатів у різних видах наук. При експоненціальному збільшенні обсягів інформації це стало практично неможливо. «Універсальна людина» — дуже рідке явище. У світі програмування та технологій — теж саме. Теж саме як і суспільний розподіл праці що сторіччями допомагає людству розвиватися.
Під концентрацією я мав на увазі, банальну думку про те, що кожен має займатися своєю справою. У моєму розумінні робота у режимі Full Stack має сенс лише на MVP етапі розвитку. На даному єтапі ресурсів трохи меньше ніж немає, тому робимо як можемо. Якщо над одним проектом працюють більше 100 розробників немає жодного сенсу всім ним торкатися всіх участків від фронтенду до docker-контейнерів. Для того щоб «на колінках», щось швидко зробити для розваги або власного міні проекту багато розуму не потрібно, але коли йдеться про багатомільйонний бізнес — знання мають бути зовсім іншого рівня. Саме про таку концентрацію я кажу.
Стосовно предметної області та особливостей проекту — все по суті так само як із технологіями — чим складніше проект, тим більшої концентрації він вимагає.

Балансування.
Програмісти дуже різні. Немає такого единого поняття «я думає програміст». При достатньомі рівні взаєморозуміння та відкритості у спілкуванні, середньостатистичний програміст, на мою думку, без особливих складностей може провести економічне обґрунтування своїх технічних рішень.

Коммункації.
Так само як і з концентрацією, мені напевно не вдалось донести основну думку. Основна думка тут про комунікації між програмістами, а не між клієнтами та програмістами. Якщо казати про ваш приклад — то на мою думку, для того щоб нав’язати замовникам своє бажання як раз потрібно бути просто гуру комунікацій, PR та маркетингу.

Під концентрацією я мав на увазі, банальну думку про те, що кожен має займатися своєю справою

Ну дик називайте речі своїми іменами. ;) Це не концентрація, а вузька спеціалізація.

Вузька спеціалізація зазвичай має другу сторону медалі. Вузький спеціаліст вузький у всьому. Його мозок заточений на певні патерни поведінки та він не сильно бажає щось змінювати. Це значить, що тактично він буде ефективним, а стратегічно — вже програвати більш «широким» колегам. Приклад — людина, яка все життя писала на MVC з великими проблемами переходить на той самий реактивний підхід. Вона буде писати MVC, тільки в синтаксисі реактивного підходу.

При достатньомі рівні взаєморозуміння та відкритості у спілкуванні, середньостатистичний програміст, на мою думку, без особливих складностей може провести економічне обґрунтування своїх технічних рішень.

Я на ДОУ спілкуюся доволі давно. Рівень економічної освіти наближається до нуля. Як ви думаєте, яку оцінку дасть людина, яка не може відрізнити витрати від інвестицій?

Так само як і з концентрацією, мені напевно не вдалось донести основну думку.

Можливо, це не ваша сильна сторона ;)

Основна думка тут про комунікації між програмістами, а не між клієнтами та програмістами.

Комунікація сама по собі може як підвищувати ефективність, так й знижувати її. Наприклад, постійна комунікація з людьми, які не мають спільної думки, призведе до того, що програмісти будуть постійно в стані фрустрації.

Якщо казати про ваш приклад — то на мою думку, для того щоб нав’язати замовникам своє бажання як раз потрібно бути просто гуру комунікацій, PR та маркетингу.

Не треба суперздібностей. Треба розуміти дві речі: не всі проекти мають замовника зі сторони; та необхідно, щоб ви були корисними для бізнесу замовника, а не черговим рядком в витратній частині бюджету.

не сильно бажає щось змінювати

Можливо йому і не потрібно — просто для іншої роботи треба знайти іншого спеціаліста вузького профілю.

Як ви думаєте, яку оцінку дасть людина, яка не може відрізнити витрати від інвестицій?

Під економічним обґрунтування своїх технічних рішень, мав на увазі розрахунки наближені до побутових. Приклад приходить на думку такий — якщо можливо за пару годин оптимізувати 1% коду, що прискорить роботу системи у десятки разів та дасть змогу відмовитись від великої кількості додаткових дорогих серверів, то треба оптимізувати. Та навпаки — якщо очевидних проблем із кодом немає і є альтернатива між багатотижневим марафоном із профайлінгом, що за прогнозом дать приріст на кілька відсотків та можливо збільшить складність коду і варіантом ресайзнути віртуалку для збільшення ресурсів, що можно зробити швидко та доступно по ціні, то вибір теж очевидний

Наприклад, постійна комунікація з людьми, які не мають спільної думки

Постійно — мабуть ніхто не витримає, але для різноманітності думаю це теж корисно.

треба знайти іншого спеціаліста вузького профілю.

Це неефективна витрата ресурсів. Спеціалістів ви не знайдете за 3 секунди, а якщо й знайдете, то переплатите за нього. А потім що з ним робити? Виганяти?

Під економічним обґрунтування своїх технічних рішень, мав на увазі розрахунки наближені до побутових.

Побутовий рівень дає похибку побутового рівня. З такою похибкою далеко не доїдеш.

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

ну, я все понимаю, конечно, просто пример. но все же это уж через час)) слишком уж большое преувеличение. Джун делает две недели то, что синьйор сделает за час :)

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

Я тоже думаю это сильное преувеличение. Более того — на большом легаси-проекте увидев кусок незнакомой костыльной функциональности (что составляет большую часть рабочих тасок ибо на изучение такого проекта уходят годы) и синьор, и джун будут офигевать в примерно одинаковой степени и времени у синьора уйдет не намного меньше, чем у джуна. Тут бенефит от синьора скорее в том, что он потом напишет код более качественно — то есть с меньшей веростностью сломает проект в еще десяти местах.
При этом, среднестатистический джун просидевший год на таком проекте vs новоприбывший среднестатистический синьор — врядли от синьора в первые несколько месяцев будет больше пользы.

В статье указано «эффективности программистов разного уровня может достигать 1 к 100». Это не значит, что на каждой задаче будет так, но и однозначно речь не идет про про «случайно найденную кнопку».
Также имел в виду (но к сожалению явно не указал это в статье) что Junior только пришел в проект, а Senior уже работает там пару лет.
Если говорить в целом, то пример похож на старый анекдот про «знать где ударить». Для больших проектов доля шутки тут может стремится к абсолютному нулю.

спасибо, интересные мысли и познавательные примеры из жизни

Спасибо, хоть кто-то, что то позитивное сказал :-)

Только лохи работают в openspace EPAM, матёрые волки ставят кушетку прямо на ЖД и успевают с написанием кода, щипать кошельки у прохожих. Вот что напоминает мне эта картинка.

Идея была в том что вокруг (внезапно) есть люди :-) Живые люди. С которыми можно поговорить в живую, а не через мессенджер, который не умеет передавать эмоции. На картинке программист не работает. Он общается с миром.

Підписатись на коментарі