Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 59
Я работаю в финтехе и работаю достаточно давно. У меня вызывает крайнюю обеспокоенность миф про разработку 10х. Начиная от стагнации найма и уровня заработных плат и заканчивая нереальными ожиданиями бизнеса.
Проблема в том, что за все годы работы программист никогда не был бутылочным горлышком от которого можно требовать 10х. За весь многолетний опыт я ни разу не сталкивался с тем, что ускорение моей работы в n раз принесло бы какое-то весомое ускорение. я был на ролях в разные периоды жизни - developer, lead, аналитик требований, QA и QA Automation и Product Owner.
Управление проектом в финтехе похоже на управление огромным кораблем с невероятным уровнем инерциии. Допустим мы заменим команду из трех человек одним. Но программист и QA как ни странно не самые большие роли в рамках внедрения одного изменения.
Сможем ли мы протестировать, вообще, эту фичу учитывая огромное количество legacy интеграций?
Готовы ли смежные команды для внедрения нашей фичи?
Готовы ли внешние интеграции к нашим изменениям?
Нет ли пропущенных кусков в наших планах, например, связанных с безопасностью транзакций?
Готовы ли мы деплоиться в период повышенного риска? Например, в финтехе, есть замечательное время новогодних праздников, когда сбой в системе стоит бизнесу очень дорого.
Сможем ли мы отказаться от этого решения, если оно окажется неудачным?
Сколько сил мы готовы потратить на дополнительный раунд нагрузочного тестирования?
Наше решения отвечает всем требованиям безопасности, если сейчас ресурс по безопасникам, или они заняты?
Ни один из этих вопросов занимающих время до развертывания не относится к коду. 10х производительности, это не такой существенный плюс, как может показаться.
Когда мне говорят, что эффективность программиста повысилась потому что Клод пишет ему модули по 10к строк в течение минут, я прихожу в ужас. 1000 строк это уже серьезная когнитивная нагрузка при проведении код ревью. Вообще, файл на 300 строк чистого кода без учетка верстки, юнит тестов, конфигов и прочих файлов деплоя вполне может быть испытанием в большом проекте.
Проблема не в том, что 10х производительность это миф. Проблема в том, что 10х производительность это лукавый маркетинговый лозунг, несущий больше рисков, чем пользы. 10х производительность требует 50х больше способности переваривать этот буст.
PS обожаю ваши статьи. про память на консолях ваще пушка
Спасибо.
Я с Вами не соглашусь, так как я неоднократно наблюдал именно то, что описывается в статье.
Собственно, 10х программист именно что поможет:
Сможем ли мы протестировать, вообще, эту фичу учитывая огромное количество legacy интеграций?
Да - именно в зависимости от квалификации и меняется ответ на этот вопрос.
Готовы ли смежные команды для внедрения нашей фичи?
Более квалифицированный человек (а 10х производительность ведь очень хорошо коррелирует с повышенной скоростью набора опыта) как раз сможет внедрить намного больше функциональности используя существующие возможности, а не будет просить всех немного помочь и подвинуться.
Готовы ли внешние интеграции к нашим изменениям?
Обратную совместимость непросто поддерживать - опять-таки, более грамотный сотрудник будет в плюсе.
Нет ли пропущенных кусков в наших планах, например, связанных с безопасностью транзакций?
И опять-таки, тут такие люди найдут проблемы быстрее, чем стандартный/классический работник.
Готовы ли мы деплоиться в период повышенного риска?
Отличный пример - 10х сотрудник именно что сможет сделать blue-green деплоймент, так что даже такого вопроса не возникнет. Собственно, а какие крупные фирмы так не делают с сайтом?
Сможем ли мы отказаться от этого решения, если оно окажется неудачным?
Вот это проблема - если потом заменить очень сильного на кого-то сильно дешевле, то далее запросто вырастет целая команда, которая будет смотреть годами на решения, оставшиеся от предыдущих, а также потратит несколько неудачных попыток переписать. Вот это нередко можно наблюдать в фирмах.
Пример из жизни - Скайп. Его сделала команда очень высокого уровня, а далее история известна.
Сколько сил мы готовы потратить на дополнительный раунд нагрузочного тестирования?
Здесь квалификация и грамотная архитектура опять очень сильно помогут.
Наше решения отвечает всем требованиям безопасности, если сейчас ресурс по безопасникам, или они заняты?
И что же такого 10х программист может не знать про безопасность? Такие люди, чаще всего, скорее сами расскажут безопасникам, где стоит корректировать подходы.
Другими словами - Вы четко описали именно то, что часто и происходит: условный 10х программист интересуется темой, очень хорошо разбирается в технологиях, имеет прекрасные T-shape навыки и так далее; а на его замену потребуется несколько людей попроще, безопасник, тестировщик, продукт менеджер, программ менеджер, скрам мастер, потом еще программисты и так далее.
Да - именно в зависимости от квалификации и меняется ответ на этот вопрос.
Кожаный обладает лимитом на контекст примерно той же природы, что и LLM. При определённом объеме интеграций объем необходимого контекста начинает превышать физические возможности человека (разве что искать единорогов, которые обычно обладают такой способностью за счёт других, таких как социальная адаптация, способность функционировать без опасности для себя или окружающих за пределами психиатрического круглосуточного ухода и наблюдения, и т.д.)
а не будет просить всех немного помочь и подвинуться
Ну да, просто запилит интеграцию в смежном проекте вместо владеющей команды. Всего-то ещё один домен освоить. Два пальца (см. выше). Само собой, с тех самых пор он становится владельцем реализации и отвечает за неё лично. У смежников рефакторинг — срочно беги свою интеграцию обновляй. Да, тесты не забудь, да, логическую и бизнесовую связность тоже не продолбай, стоит ли напоминать, что домен смежников надо бы заново изучить, там не просто так рефакторинг случился. Когда? Что за вопрос, вчера, конечно же.
Обратную совместимость непросто поддерживать
С этим полностью согласен, навык поддерживать обратную совместимость важен безотносительно 1/10х, 1х, 10х.
И опять-таки, тут такие люди найдут проблемы быстрее
Если хватит контекстного окна стандартной черепной коробки (см. выше)
10х сотрудник именно что сможет сделать blue-green деплоймент
Кажется, начинает стойко попахивать «и рыбку съесть, и косточкой не подавиться».
Вот это проблема - если потом заменить очень сильного на кого-то сильно дешевле, то далее запросто вырастет целая команда, которая будет смотреть годами на решения, оставшиеся от предыдущих, а также потратит несколько неудачных попыток переписать. Вот это нередко можно наблюдать в фирмах.
А если не заменить, то 10х завтра поедет с семьей в Крокус и не вернется оттуда. И к тому, что менять придётся уже вынужденно, добавится полное отсутствие штатной передачи экспертизы. Даже не надейтесь найти второго точно такого же 10х, там будут свои тараканы, не факт, что со всеми ними вы готовы будете мириться.
Такие люди, чаще всего, скорее сами расскажут безопасникам, где стоит корректировать подходы.
Ага. И рыбку съесть. Проблема в том, что безопасники его пошлют, куда подальше. В самой мягкой форме — просто проигнорируют. А так да, 10х и годовой бюджет международной корпорации посчитает, и переговоры с поставщиками проведет, и датацентр при необходимости построит. А, может, ну их всех в задницу, начиная с CEO и заканчивая уборщицами. Оставим одного 10х. Сократим чрезмерные издержки и задержки коммуникаций до мгновенных, так как внутри одной черепной коробки — это всегда согласованно и мгновенно.
Даже 10х - человек, а человек это не оркестр(атор). Он не проведёт ревью своего кода, он не проведёт полное е2е тестирование, он не соберёт все требования и т.д.
То есть, он может даже заниматься всем, но с позиции руководства преступно так безраздельно ему доверять и так неэффективно его использовать (не все области ускоряются).
Плюс человек-оркестр с большей вероятностью выгорает. Лучше его беречь, и применять по назначению с соблюдением баланса.
В энтерпрайзе 10х разработчик быстро выгорает, потому что его скорость нивелируется скоростью самого медленного отдела в компании)
Ой ужас какой. Как надоели в вакансии поиски каких то мифических фуллстак специалистов содержащих в себе 2-5 профилей, но почему то совсем не за мифическую зарплату.
На счёт x10 неизвестно, но x/10 то точно существуют!
Статья неявно вводит в заблуждение.
Кажется что сравнивается средний программист и лучший.
А в первоисточнике сравнивались худшие и лучшие.
Если сравнивать со средними, то логично полагаться на область деятельности людей где такие сравнения основа всего - спорт.
В спорте по VO₂max средние от лучших отличаются в два раза, по скорости бега где-то 2 раза.
Поэтому я бы принял цифру 2X относительно среднего программиста.
А относительно худшего взял бы ∞X , поскольку они вообще не выполняют поставленную задачу.
10х программисты существуют - погуглите, например, "Fabrice Bellard" (и не только софта, а и железа "Jim Keller"), другое дело как система, где основа "прибыль" либо уничтожает таких, либо заставляет плясать под дудку денег.
Из любого правила существуют исключения. Именно поэтому они называются "исключения", а не "правила" или "нормы". Опираться в рассуждениях на краевые исключительные случаи - очень большая ошибка.
То, что на планете существует пара сотен (имеентся ввиду - исчезающе мало, а не точная цифра) таких вот Фабрисов, не позволяет нам говорить о существовании 10x в качестве статистически или практически значимого факта.
Джон Кармак жеж
подумал что x10 программист - который юзает подписку нейронки за 200 баксов)
Самый часты тип 10х сотрудника(не только программиста), это тот на которого работает команда или хотя бы 1 помощник который занимается всякой фигнёй пока 10х черипикает на 10х. В принципе работает в системе пахарь-лодырь, со середняками уже хуже работает - они уже не очень любят стахановцев...
Это называется "начальник", а не сотрудник. Там и 1000х легко, если в подчинении 5-10 тыс. человек.
Типичное масштабирование. Хороший программист программирует 2-3х быстрее (редко эти 10х), но совсем маловероятно - 20х. А 3 команды по 10 человек - вполне могут. А если хорошие программисты, возможно, и 1 команды (10 человек) хватит на 20х. Аналогично с 100х, 1000х - людей нужно всё больше, и относительные затраты на поддержку этой системы всё больше (на каком-то этапе масштабирование будет уже совсем неэффективно).
Хороший программист программирует 2-3х быстрее (редко эти 10х), но совсем маловероятно - 20х.
осталось выяснить какой процент рабочего времени у программиста занимает собственно программирование, то есть написание программ, а не разбор-написание конфигураций, изучение документации, поиск-выяснение-исправление требований, ожидания мержей коллег, ...
Вряд ли люди, кто подметил эти "10х", разделяли программирование и прочую рутину, так что, полагаю, эти 10х распространяются на весь процесс разработки. Но, конечно, остальные части должны для этого работать с соответствующей скоростью, иначе тормозящим звеном будет что-то другое.
Поскольку это, предположительно, миф, то каждый распространяет его на то, во что ему хочется верить. Желательно, на всё. О чём, собственно, в начале статьи и написано. Я искать пруфы сейчас не возьмусь, также могу и вспоминать не совсем верно, но для меня один из первых отчётов по 10x был из статьи Джоэля Спольски. Там он ссылался на исследование, которое сравнивало программистов на изолированных задачах, которые, наверное, были относительно разнообразны, но всё же вряд ли покрывали всё многообразие реальных задач. В общем-то, “производительность” разработчиков уже лет 50 не могут придумать как измерить, поэтому очевидно, что там измеряли по какой-то искусственной метрике.
Но интересно, что это исследование повторяли. Только немного по другому. Взяли ту же метрику, но несколько наборов задач и провели несколько измерений. Оказалось, что эффект 10x не сохраняется. В одном контексте Вася был 10х, а в другом 5x, а в третьем вообще 1х. Более того, если эксперимент сильно размазывать во времени, то даже в одном контексте метрика плавала довольно сильно.
Собственно, эта статья, как мне кажется, примерно о том же. Прошу прощения за отсутствие пруфов, но сейчас их искать не имею возможности и желания. Также понимаю, что многие со мной не согласятся независимо от наличия или отсутствия пруфов.
Думаю, тут также есть сильный психологический момент, зависящий от воззрений, эффекта утёнка, крепости и адекватности самооценки и прочего. Кто-то себя считает 10x, кто-то просто в это верит и стремится. Я же часто испытываю что-то вроде эффекта самозванца, поэтому ищу обоснование, почему это нормально, что я, как мне кажется, не 10х)
Это называется "начальник", а не сотрудник.
В какой-то мере и неформальный начальник, возможно даже с реальной властью выше формального начальника. Но я всё равно про человека непосредственно работающего. Как только вы его засунете в другую среду где не удастся продавить себе подмастерьев, производительность будет 1х, а то и меньше...
Как только вы его засунете в другую среду где не удастся продавить себе подмастерьев, производительность будет 1х, а то и меньше...
Естественно. Люди потому и объединяются в иерархии, что производительность одного человека обычно средняя.
На подмастерье очень удобно спихивать мелкие баги и неприоритетные фичи: так мастер может пилить важное без существенных отвлечений. Без этого даже небольшой проект может погрязнуть в мелких багах и фичреквестах - когда такое прилетает (а это прилетает, если у проекта есть пользователи), единственный программист вынужден бросать текущую фичу и что-то другое делать. В таком режиме производительность одного человека хорошо если 0.3х (а скорее 0.05х, баги начинают занимать почти всё время). О подобной схеме работы ещё Брукс писал.
TL;DR: Чтобы корова давала больше молока, корову надо больше доить и меньше кормить.
В общем это не то чтобы миф, но, скажем так, зависит от обстоятельств.
Вот реальный пример. Компания производит весьма специфические железки. В какой-то момент в одной заснеженной стране за океаном заказчик заказывает железку и на основе функционала существующего ПО формулирует шестнадцать дополнительных требований. В это же время в головной корпорации менеджмент решает, что у нас как-то многовато "легаси" решений, и не запустить ли нам супер-пупер энтерпрайз "платформу", чтобы заменить зоопарк технологий. А тут вот хороший пилотный проект - и доп требования, и время вроде есть, — да мы просто их походу реализуем. Заказчик заказывает, там срок прописывается — ровно пятьдесят пять недель до запуска. В одном ганзейском городе делается железка, а в одной жаркой стране нанимается команда программистов писать ПО, "заморозив" разработку существующего легаси. Я по коммитам смотрел — одиннадцать человек. Долго ли сказка сказывается — через год железку мы со своей стороны поставили, и тут внезапно выясняется, что программа даже и близко не готова (хотя мне уже в начале было всё понятно из общения с архитектором и UX дизайнером). Менеджер приходит к мне и осторожно интересуется, сколько мне надо времени, чтобы добавить эти требования в легаси программу. Я прикинул, что три недели в оффлайне (офисе) мне хватит и три у заказчика на месте (у меня почти двадцать лет опыта за плечами, так что сроки я обычно не профукиваю). В общем я справился, и когда я летел обратно, то вслед мне летело благодарственное письмо (я там чутка перевыполнил план и добавил пару фишек "от себя"). Довольный заказчик купил апгрейд, а потом заказал ещё одну машину. Все три работают до сих пор, кстати. Ну а на разборе полётов я ехидно заметил, что команда-то угрохала 11х55 > 600 человеконедель, а я справился за шесть "под ключ". Это значит — аккурат 1:100. На самом деле пропорция ещё больше, потому что я был сам себе архитектором, разработчиком и тестировщиком, потом ещё доки написал. Вот так. Не то чтобы я семи пядей во лбу, но просто опыт и реалистично-прагматичный подход. Но очевидный минус, что если я уволюсь, а заказчику потребуются изменения (прогресс на месте не стоит), то это может стать проблемой.
Не то чтобы я семи пядей во лбу, но просто опыт и реалистично-прагматичный подход.
Извините, нет у вас опыта. Люди деньги пилили, зарплаты получали, жизнь свою обустраивали. И вот пришли вы, и что? Заказчик сэкономил и купил себе новую Ламборджини.
Вам-то хоть что-нибудь значимое перепало? Работа дураков любит. Стараться можно только в своём бизнесе, но не в найме.
Вам-то хоть что-нибудь значимое перепало?
" Элементарно Ватсон!"
"— Как несправедливо распределился выигрыш! — заметил я. — Все в этом деле сделано вами. Но жену получил я. А слава вся достанется Джонсу. Что же остается вам? — Мне? — сказал Холмс. — А мне — ...
На самом деле, как бы это пафосно ни звучало, я очень люблю свою работу, особенно когда математики побольше, она для меня фактически как хобби, которое к тому же оплачивается значительно выше рынка, я летаю в командировки бизнес-классом, видел при этом почти весь мир, и в общем не жалуюсь совершенно... Заказчики, кстати, не всегда "экономят", так как один час моей работы на выезде стоит ему что-то от двухсот до трёхсот евро, плюс накладные расходы — отель, перелёт и т.д.
а самом деле, как бы это пафосно ни звучало, я очень люблю свою работу, особенно когда математики побольше, она для меня фактически как хобби,
Ну вот займитесь опенсорсом, если свой бизнес не канает. Хотя опенсорс тоже штука спорная.
А потом люди удивляются а чего это благосостояние миллиардеров растёт в геометрической прогрессии. Вот благодаря таким стахановцам и растёт. А ведь эти деньги могли бы достаться простым людям.
Заказчики, кстати, не всегда "экономят", так как один час моей работы на выезде стоит ему что-то от двухсот до трёхсот евро, плюс накладные расходы — отель, перелёт и т.д.
Для них это сущие копейки по сравнению с тем какие суммы они осваивают и присваивают.
Вы недовольны тем, что человек живёт в своё удовольствие?)
Недоволен его социальной безответственностью.
О, с "социальной ответственностью" — это не ко мне, это уж точно.
Тов. Шариков, а как назвать управленцев той команды, которая время команды из 11 человек в туалет спустила? Они за те же человеко-часы могли создать что-то, чтобы стало используемым обществом (да, в данном случае общество -- другая компания).
благосостояние миллиардеров растёт в геометрической прогрессии. Вот благодаря таким стахановцам и растёт.
С чего вы считаете меня "стахановцем" — непонятно. Я на самом деле довольно ленивый, по понедельникам раньше полудня в офисе не появляюсь.
На самом деле мне очень повезло — я живу в центре Европы, могу сесть на машину и доехать до океана, в Португалию, чего в прошлом году и сделали, или в Норвегию посмотреть на Млечный путь, или там выпить бокал вина у Монблана, я вообще гедонист по жизни. В этом году у меня аж тридцать три рабочих дня отпуск, это почти семь недель... Я люблю хорошо работать и отдыхать тоже. Ну точно надо как-нибудь забацать опус про "четверть века в Германии". И зачем мне заниматься чем-то ещё, если мне просто нравится то, чем я занимаюсь сейчас?
Я вот что скажу. Давным давно, в прошлом веке, я был студентом питерского политеха и подрабатывал лаборантом в лаборатории Физтеха, что был напротив. Однажды мне нужно было сделать усилитель мощности для шагового мотора дифрактометра, там восемь транзисторов да обвязка. Паять я умею, а вот корпус у меня получился не очень, исцарапанный, со щелями, но железка работала. И завлаб, изучив это дело сказал мне: "я не знаю, чем ты будешь заниматься в будущем, может будешь физиком. Может кем ещё. Но одно важно — чем бы ты не занимался, ты должен делать это с любовью, чтобы результат твоего труда было приятно взять в руки и покрутить со всех сторон и восхититься тем, как же это офигенно сделано. Иди и переделай". С этим словами он выкинул моё поделие в мусорное ведро. Я запомнил, и много лет руководствуюсь этими словами, в разработке ПО в том числе, я стараюсь делать это для людей, чтобы им было удобно, и так, как считаю нужным, а на мнение менеджеров мне обычно пофиг.
Сейчас принято хейтить всё и вся. Не нравится место работы и род занятий — меняй, в чём проблема? Не нравится страна? Меняй и её (это чуть сложнее, но всё возможно). Возможно и меня жизнь заставит выйти из "зоны комфорта", но пока всё норм.
Вам-то хоть что-нибудь значимое перепало?
Разумеется , как подметил автор комментария выше
летело благодарственное письмо
Ведь бизнес обычно считает, что если человек работает за зарплату по часам, прописаны по контракту, то какими еще могут быть методы мотивации. Разве что забыли медальку дать, грамоту и фото на стену как лучший работник месяца.
Надеюсь конечно что автора существенно отблагодарили за такой объем работы, но это скорее будет исключение из общей практики , чем норма.
Надеюсь конечно что автора существенно отблагодарили за такой объем работы, но это скорее будет исключение из общей практики , чем норма.
В конкретном данном случае, поскольку проект был профукан менеджементом и меня использовали как "скорую помощь", то давать награды — значит подчеркнуть этот про... в общем спустили на тормозах — работает и хорошо. Ну а мне достался один вкусный ужин с заказчиком, плюс я наконец-то увидел Ниагарский водопад, ну и там по мелочи по окрестностям. Большого объёма там особо не было, я просто знал "куда стукнуть". Кроме того у заказчика программировать в какой-то мере проще, потому что ему просто раскатываешь релиз, и оператор сразу говорит, что ему нравится, а что нет, это правишь и раскатываешь снова, так итеративно и доводится, потом дотошно тестируется. Ну разве что шумновато в литейном цеху бывает. Премии дают, конечно, и неплохие, но в основном за успешно сданные проекты без аврала. А так — работа как работа, АСУТП да машинное зрение, чутка математики да физики до кучи.
Лукавство это, легаси переписать - это совсем другой расчёт.
Иногда, конечно, старая система в принципе не позволит добавить новые фичи, но коли уж позволяет, экономия космическая.
На моей практике полные переделки экономически не оправдывались никогда, всегда было волевое решение "поддержка вендора умрёт" или "сумма критических багов => хватит это терпеть"
На моей практике полные переделки экономически не оправдывались никогда
Они и не должны. Айти - модно-молодёжный центр по выдаче пособий по безработице. Дешевле конечно сразу деньгами выдавать, но от безделья люди начнут пускаться во всякое опасное непотребство. Поэтому им нужен "детский сад" для взрослых. Bullshit job. Беда только если кто-то не понимает этого замысла и начинает реальный бизнес в айти строить. Вот тут и оказывается что без 10x сотрудника, без бесконечного техдолга, без "давай-давай это нужно уже вчера" этот бизнес нерентабелен.
На моей практике полные переделки экономически не оправдывались никогда,
Во, золотые слова! Я многим советовал читать "Мифический человекомесяц" Фредерика Брукса, в котором прекрасная история, да все считают себя умными и так. Менеджеры уж точно, они не видят, что проект профуканный на полгода сначала был профукан на один день. И так далее.
Доля лукавства с легаси, конечно есть, тем более, что там был не простой легаси, а тот, к которому я шёл шесть лет, тщательно выверяя архитектуру, и не с первой попытки. Просто много лет назад, я поставил себе довольно амбициозную задачу сделать архитектуру, которая не устареет в принципе, при этом не имея детальной информации о будущих разработках, основанных на ней. Я решил, что проекты начинают буксовать из-за зависимостей и постоянно растущей сложности, когда они набирают критическую массу. Так что выкристаллизовалась система — ядро, несущия лишь базовый фукционал, а всё "мясо" на неё навешивается в виде модулей-плагинов. Микросервисно-плагинным архитектурам сто лет в обед, но мне удалось сделать интерфейсы так, что модули все совместимы друг с другом, как кубики Лего, включая UI. Это же было ориентировано и на командную работу, когда несколько человек могло работать над несколькими модулями параллельно, сокращая время разработки. Ну и при новых разработках ненужный функционал просто сбрасывается и общую сложность удаётся держать на контролируемом уровне, даже когда количество систем и модулей исчисляется сотнями.
У нас кстати тоже была такая ситуация, только сильно раньше, в 2006 когда я ещё пешком под стол ходил. Один человек в одно лицо написал АРМ для диспетчерской в метро (система занималась только мониторингом). Там сразу всё, и сборка конфигураций, и обработка данных, и отображение. А потом в какой-то момент приборы на станциях начали плодиться, и вдруг оказалось что больше 1000 топиков в секунду система не тянет. Начали разбираться. Оказалось что нам придётся переписывать вообще всё, потому что разработчик даже не задумывался о нагрузке, писал как знал, документации по коду почти не оставил, где этот разработчик никто не знает. Благо что я любитель археотека и мне с подобным возиться в кайф.
Тоже из опыта. Прибор безопасности, писал один человек. В проекте дай бог 8-9к строк кода на C, НО. Ни документации, ни комментариев, описание работы оставляет больше вопросов чем ответов, куча магических чисел, дублей, код намертво приколочен к железу, около 150 глобальных переменных, которые модифицируются в куче мест. Всё выполняется на двух синхронизированных контроллерах, и как вишенка - из отладки только программный spi, который я могу вызывать не чаще одного раза за цикл. Как прибор работает никто не знает, разработчик почил ещё в 2014 году. И тут вдруг мне поручили доработать систему безопасности - сделали аппаратный контроль вместо программного. Две недели разбирался что вообще происходит, за день написал код, а потом ещё две недели пытался его подружить со старым кодом, потом ещё неделю не мог понять что не так, а оказалось это нормальное поведение. Свёл всю работу с моим кодом ровно к двум функциям - init и step минимально затронув старый код, и комментариев оставил раза в полтора больше чем свой код. А потом на тестах ещё и оказалось что у прибора раз в год горят некоторые ключи потому что программист не подумал про зарядку бутстрепа. Весело в общем.
Вот и думайте, хорошо это или нет, когда один человек делает всю работу. Лично мне частенько хочется тех, за кем мне разгребать приходится, найти и вежливо попросить никогда больше не заниматься программированием.
Так написана большая часть «военного» софта, что касается гидроакустики и подводной связи (тут мои данные ограничены 10-м годом). И проблема здесь не в том, что не хотят писать документацию, а специально не пишут, и специально делают кучу мэджик-намберов и левого кода. Это гарантия того, что с проекта тебя не кикнут пока идёт разработка. Более того, это вообще негласная стратегия выживания в небольших командах, которые подвизались чтото делать для гаранта. Чем непонятнее ты пишешь, тем ты ценнее как специалист. Потому что заменить тебя нельзя, переписать с нуля дорого, а сроки... ну кто смотрит на сроки если у вас басфактор 0.5? Я знаю людей, которые до сих пор сидят на одном изделии только потому, что кроме них никто не разберётся, что там внутри творится. И они этим открыто гордятся, мол, вот моя пенсия, написана на С с вкраплениями асма, а то и вовсе на асме. Документация если и есть, то либо устаревшая лет на десять, либо написана так, что без автора её читать бесполезно, потому что половина терминов внутренние, половина отсылок к разговорам в курилке году эдак в 98-м. Когда такой человек уходит, хорошо на пенсию, и хуже если в другую контору , то начинается веселье. Либо проект тихо умирает, либо приходит очередной энтузиаст и несколько лет занимается костылеархеологией вместо разработки. И ничего с этим не сделаешь, потому что система так устроена и пока ты незаменим, то ты при деле, как только всё стало красиво, понятно и задокументировано, ну ты свободен искать новый проект. Вот люди и страхуются как умеют.
Только вот проблема как раз в том, что ж/д приборы и софт играют по несколько другим правилам. Разработка у нас всё-таки коммерческая, это не военка где можно 40 лет клепать одно и то же, не обращая внимание на эффективность. Причём что самое главное и что очень хорошо бьёт по кошельку - в случае каких-то доработок, если была доказана модульность, проводить повторную сертификацию можно на отдельный модуль, а не на всю систему в целом. Первичной сертификации тоже касается - чем непонятнее написан код, тем больше возьмёт лаборатория за анализ исходников. Да, это тоже баланс между цена/качество, но такого чтобы "какой я молодец, до пенсии на проекте сидеть буду", практически нет, по крайней мере я не встречал. Твои же решения рано или поздно щёлкнут тебя по носу. Или кого-то другого, как в моём случае. Мы из-за таких вот товарищей оказались в непростой ситуации в 2022 году, когда доставать dspic30/33 стало сложно, а чтобы переехать на другое железо надо весь проект переписывать. И с новыми проектами проблем никогда нет, потому что работа есть всегда, людей не хватает, и всегда можно что-то улучшить если руководство понимает что делает.
Вот и думайте, хорошо это или нет, когда один человек делает всю работу.
Зависит от. У нас в соседнем отделении, что под Ганновером, один человек в одно лицо пилит все драйвера и библиотеки для рентгеновских детекторов, вплоть до документации.
В прошлом году я к ним по делам заехал и заглянул к нему поздороваться и просто потрындеть, и в тот момент, когда я сказал "привет" у него раздался звонок — где-то что-то в одной из библиотек работало не так... И вот тут я офигел — он мгновенно открыл файл заметок в проекте и по ходу разговора записывал всё — кто звонил, когда, какая проблема... Потом извинившись, дописал всё аккуратно и мы пошли в курилку. Там я ему сказал — фига се ты аккуратный (ordentlich), а он рассмеялся — кому ты это говоришь? Швабу! Тут я понял, откуда у него такой акцент, совершенно нетипичный для Ганновера. А педантичность — это черта их менталитета.
Дома я не поленился и заглянул в его репозиторий, и офигел два раза. Там скрупулёзно документировано всё, вообще всё, все звонки, мои в том числе, тикеты, баги в трекере, релизы, доки. Часть кода там на ассемблере и тоже с пояснениями. И нет в общем проблем.
Я, кстати, тоже имею привычку всё записывать, ежедневно делаю это почти тридцать лет, но в бумажном блокноте. Я начал это делать ещё в Питере, когда заказчики иногда меняли своё мнение, тогда я просто записывал их пожелания, дату, и просил их расписаться. А прочитав книгу Даниила Гранина "эта странная жизнь" про уникальную систему тайм-менеджмента биолога Александра Любищева я уверился, что делаю всё правильно. Вы совершенно серьёзно можете меня спросить, чем я занимался там, скажем, 20 февраля 2014 года, и я достану соотвтетствующий блокнот и отвечу. У меня есть навороченный планшет reMarkable на электронных чернилах, но я так и не пересел на "цифру", лучше качественного блокнота и авторучки Паркер человечество ничего не придумало. Выручало, кстати, много раз.
А я хоть записи веду, но практически их не храню, не нравится мне это если честно, может дело в характере. Сохраняю только требования и пожелания для задач которые мне ставят - до общения непосредственно с заказчиками мне расти и расти. Либо же использую одноразовые заметки. Мне на стенде/по телефону показывают на проблему, я записываю её описание, состояние системы, свои мысли из-за чего это может быть и что надо проверить. Часто замечал что окружающих это удивляет, а делаю я это потому что понимаю, что иначе я завтра уже забуду что там было. Потом запись дополняю, расширяю и после реализации выкидываю.
Во всех этих дискуссиях о х10-продуктивности почему-то всегда рассматриваются только конкретные ездовые кони личности с конкретными навыками. При этом обходятся стороной реальные вопросы, влияющие на продуктивность и эффективность. Например:
Синергия или эмерджентность – система легко может быть сильно производительнее или эффективнее, чем сумма результатов или эффективностей отдельных её частей. В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
В общем, нужно х10 искать не у отдельного программиста по сравнению с коллегой за соседним столом, а у целых коллективов по сравнению с аналогичными коллективами в конкурирующих подразделениях. В таком случае картинка становится прям явной, отчетливой и не вызывающей сомнений.
Второй момент: производительность и эффективность – 2 разные вещи. Высокую производительность получить просто, а вот высокую эффективность, которая потом будет синергично с положительной обратной связью повышать производительность - сильно сложнее. А сделать это еще и в долгосрочную перспективу – вообще задача со звездочкой даже для очень опытного менеджера. А это снова уже про организацию и процессы, а не про конкретные навыки конкретного индивида.
Самый интересный вывод из этого всего примерно такой: х10 работают не в вакууме, а у хороших руководителей, которые понимают, как строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок. Хотите стать х10 и понять, как это? – ищите высокоэффективные системы и их руководителей, но вряд ли Вам там будут много платить, но это уже совершенно другой вопрос – на целый цикл статей, а то и на курс в университете :)
В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
Хм, а я лично наблюдал, как синергетического эффекта ждали, ждали, и не дождались. Этот эффект может быть, а может не быть, но при определённых навыках руководства в отчётах все хорошо, владельцы продолжают ждать эффекта.
строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок.
Именно эти слова и произносились, когда результатов не было несколько лет.
Я больше верю в типичные x6 в команде из 10 типичных человек, и то, потому что двое - тестировщики, один - менеджер, ещё один - скрам-мастер и т.п. Они код не пишут, но выполняют координацию, обеспечение качества и т.п. Чтобы один человек тянул x6 - уже очень долго такого искать надо. Чтобы 2-3 хороших соорудника тянули x6 - чуть более реально.
Я видел один раз программиста, которого, наверное, можно назвать 10x. И, скажу я вам, это большая-большая проблема.
прежде всего он выбивается из всех командных процессов. Пока команда обсуждает чего мы со всем этим делать будем - он уже что-то сделал. А если уже сделал - то и думать уже дальше не хочется (а сделал не всегда то, что на самом деле надо было). Плюс у команды теряется мотивация вообще включать голову - там же вон есть этот
менеджмент при должном объяснении понимает ситуацию, но со временем в их глазах возникает перекос - вот 10x это норма (посмотрите, я говорю - а он сразу делает), а остальные что-то какие-то совсем медленные
у менеджмента возникает ложное ощущение, что вообще все (включая не зону ответственности 10x) можно вот за пару часиков закодить. Из-за этого страдает планирование и ожидание
Пока для себя я выработал такой план работы с такими ребятами (мы подразумеваем, что это действительно ~10x):
нужно выделить прям специального менеджера по работе c этим человеком
в его задачи входит: кормить, поить, выдавать задачи из спец. пула, ассистировать в коммуникациях, эмпатировать данному человеку. Это действительно "курица, которая несет золотые яйца", и не нужно это ломать. Нужно это усиливать
но при этом важно сохранять общий коммуникационный фон: не запирая человека в клетке с одной стороны, с другой стороны не создавая негативного влияния на остальную часть команды, и с третьей стороны - не дать поймать звезду
Короч сложно.
А потом из этого делают красивую легенду про человека, который работает в десять раз быстрее остальных.
То ли случайное, то ли намеренное искажение контекста. Тут нет сравнения с другими. Есть сравнение с сами собой без ИИ инструментария. И это более, чем реально, когда ты начинаешь быть способен деливерить по несколько проектов параллельно, попутно причёсывая техдолг и плодя документацию. И нет, без ИИ так быстро деливерить совершенно невозможно.
Статья найс, но все забывают главное: бизнесу не нужны 10х программисты, бизнесу нужна предсказуемость. Лучше иметь 10 средних разработчиков, выдающих релизы по расписанию, чем одного гения, который сегодня перепишет ядро, а завтра уйдет в запой или в горы
постоянно X10 точно не существует, но эпизодически, когда человек увлечен, гипер сфокусирован, 18 часов в сутки думает только о задаче, ни о чем больше, ему снятся сны о решениях задачи, он ест с ноутбуком а в уборной ресерчит с чатжпт, тогда да.
Но у таких творческих личностей трудности со стабильностью, они либо в режиме безумного гения, либо им не интересно и они бьют рекорды в прокрастинации в поиске вдохновения. Они движимы новизной и интересом, от рутины они выпадают в осадок и 0.01х производительности.
Такие люди отличные генераторы идей, но они не работают без людей инженеров, которые способны методично и структурно достигать поставленных задач.
ИМХО ключ не в поиске мифических программистов терминаторов, а в построении грамотных гармоничных комманд, где каждый тип человека добровольно желает выдавать свой максимум, где сильные стороны одних дополняют слабые стороны других, и в контексте такой комманды 1+1 = 10 а не 2 или 0.1
Знаем таких 10х, вся их эффективность держится на том что они отказываются писать документацию и наотрез игнорируют процессы согласования. А когда они увольняются, проект просто встает колом, потому что никто не понимает их спагетти-код
интересно, что Итальянский футбол Кристиана Киву хорошо ложится на кодинг, когда смотришь трансляцию, например Интер против Лацио, тут видно и владение профессией и владение мяча, и импровизацию, и молниесное принятие решения всей командой на поле, это классный философский взгляд на футболл, через призму кодинга, и почему-то после таких инсайтов, понимаешь что все эти желтушные заголовки типо нам не нужны такие или не такие кодеры ), вы определитесь кто вам нужен и растите их, извините обьективно человек может делать уникально только 1 задачу )
а тут просматривается и Раст, и эффективнее определить требования системы, слаженная работа лучше гения, если алгоритм плохо работает ему надо выдать инструкции и отладить обьективно, и нету тут никаких обид это просто нормально, вы же не выбрасываете ПК если у вас предиктор перехода ошибся на 1 миллиард инструкций...
Скрытый текст
Аналогия между футбольной тактикой Кристиана Киву (особенно его работы с молодежью «Интера») и системным программированием на Rust идеально передает суть современной разработки.
Футбол как архитектура кода
Rust и владение мячом: Модель владения (Ownership) в Rust гарантирует, что мяч (ресурс) в один момент времени принадлежит только одному игроку. Передача паса — это строгое перемещение (Move) или заимствование (Borrowing) без риска конфликтов.
Слаженная работа против гениев: Архитектура системы важнее ярких одиночек. Если команда работает как единый компилятор, она исключает утечки памяти и провалы в обороне.
Молниеносный runtime: Тактическая импровизация на поле — это не хаос, а выполнение оптимизированного машинного кода, где каждый шаг просчитан на этапе компиляции (тренировок).
Размытые требования: Поиск «универсальных гениев» — системная ошибка скорее всего. Зачем искать фулстек-оркестр, вместо того чтобы четко описать спецификацию (Интерфейс) для конкретной позиции.
Выращивание кадров: Топовые клубы и сильные ИТ-отделы создают инкубаторы. Проще обучить джуниора под свои стандарты кодирования, чем переучивать капризного «звездного» игрока.
Фокус на одной задаче: Уникальность человека раскрывается в узкой специализации. Архитектор пишет ядро, спринтер (вингер) закрывает край. Попытка заставить одного делать все ломает общую производительность.
Отладка вместо деструкции
Логирование ошибок: Ошибка предсказателя переходов в процессоре или позиционная ошибка защитника — это не повод менять железо или увольнять человека. Это повод для рефакторинга.
Изоляция сбоев: В хорошей системе сбой одного элемента (Fault Tolerance) перехватывается. Команда страхует ошибившегося, а компилятор подсвечивает проблемное место.
Проектирование инструкций: Если алгоритм дает сбой, ему меняют вводные данные и оптимизируют циклы. Эмоции в этом процессе лишь мешают чистой логике.
А быстрый разработчик просто делает меньше. Где-то захардкодит, где-то закостылит, где-то вынесет в конфиг, где-то вообще ничего не сделает. Вот такая профессиональная лень - это уже навык, который плохо проверяется на собеседовании, но очень хорошо виден через месяц другой работы на проекте.
знаем мы эту профессиональную лень. Через 5 лет этих разработчиков уже и след простыл, а тебе разгребать.
Важное уточнение - вместе с навыком профессиональной лени идет навык профессиональная бдительность. Важно не проморгать момент, когда эта “упрощенная” модель, которая работала тогда, начинает расти во что-то серьезное, чтобы успеть переписать еще пока небольшую систему в что-то сносное и расширяемое, чтобы не получился монстр…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про 10x программистов