Comments 77
На поверку оказывается, что "медленное" программирование не "медленее" быстрого, а вот затрат на него надо в разы меньше. Что технических, что эмоциональных.
Впрочем, пусть расцветают сто цветов, пусть соперничают сто школ (с). В идеальном мире должны быть и спринтеры и марафонцы. В конце концов людям с разным темпераментом и в разное время оказывается комфортнее в разных концепциях.
В своей итерации бизнес тоже можно разделить на "медленный" и нет. И в принципе всё сводится к философии и мировоззрению: живешь ли в согласии с собой и своим ритмом или выпрыгиваешь из штанов, чтобы угодить KPI... и стоит напомнить что все эти показатели - это коэффициенты в отвлеченных единицах, а даже не в попугаях.
> В своей итерации бизнес тоже можно разделить на "медленный" и нет. И в принципе всё сводится к философии и мировоззрению:
если про бизнес, то необходимо учитывать environment, типа зайцы в лесу бегают быстро не потому что у них такая философия, а потому что волк имеется + законы дарвина,
так и с бизнесом - если конкуренция острая, на философию + мировоззрение время обычно не хватает, конечно если экономика не рыночная, или конкуренция временно отсутствует (такое бывает) можно и на философию время найти, и на многое другое тоже,
ps
если хотите медленного, вдумчивого программирования, выбирайте области hi tech подальше от "конвейерной " разработки sw, например при разработке новой os обычно не торопятся
Да я вроде не жаловался. Скорее о том, что "медленно/быстро" можно на что угодно натянуть, как и написано в начале статьи. Но к концу блок, что виноват бизнес. И мой тезис о том, что бизнес тоже не последняя инстанция.
У меня ассоциация с психологическим вопросом "Зачем?", где на какой-то итерации всё упирается "А вот хочу так!"
понимаю, упирается, но возможно для большинства деловых людей в тезис "выжить бы еще год-другой", хотя одно другого не исключает :)
"кто виноват" вообще обширная тема, для начала желательно определиться с вопросом согласно ли общество платить за комфорт и hi tech стрессом связанным с конкуренцией, вероятно простого ответа нет
у меня нет таких вопросов в повестке. Уже как-то расставил в систему, которая меня устраивает. В основном вижу, что вы рассматриваете систему в статике, в разрезе перекосов в какую-то сторону. В динамике особых проблем не наблюдаю, потому что когда-то узнал про законы диалектики. Переход количества в качество отлично объясняет вложения в хайтек, нет?
Про "виноват" тоже особо не напрягаюсь. Потому что переношу психологию личности на организации и на общество. Я в полном восторге от треугольника Карпмана, хотя его больше склоняют для липких манипуляций. В контексте темы "виноватые" активно участвуют и получают нехилые бонусы в общей системе. Вообще, если роль денег понизить, то всё вокруг богаче связями становится.
> Переход количества в качество отлично объясняет вложения в хайтек, нет?
каким образом?
прямым. Сначала издержки значительные, но вложения аккумулируются, на каком-то шаге издержки падают до минимума, а качество остается и масштабируется. Дороги с твердым покрытием, пар, жд, самолеты, бесплатный вай-фай в метро.
> Дороги с твердым покрытием, пар, жд, самолеты, бесплатный вай-фай в метро.
дороги, мосты, аэропорты, и пр. обычно называют инфраструктурой, в которую конечно надо вкладывать, что делали начиная с времен римской империи построив стратегические дороги, виадуки и т.д., о чем догадались без диалектики
Самые "быстрые" проекты, которыми я занимался в своей рабочей карьере (а их уже было овердохрена), в которых все с горящими жопами писали код, работали в выходные, оставались после работы что-бы писать код.. все они без исключения оказались пустышками. Бизнес тупо выбросил деньги, люди бесполезно потратили свое время и здоровье на все это, ни один из таких проектов не взлетел.
А это значит, что если кодер не владелец бизнеса и не в доле, то это не его проект. Подчинённые совершенно необдуманно разменивают ресурсы своих собственных жизней на осуществление чужих желаний. Бизнес хотел на скорую руку проверить код и все работали с горящими жопами, но проверка не удалась, за попытку спасибо, возвращайтесь в понедельник.
У меня были проекты, когда это даже под интересы бизнеса не подтянешь. Крупная бюрократическая машина, в недрах которой рождаются выбросы инферно в виде новых "прорывных" проектов, на которых сначала по полгода-год нихрена не происходит, а потом перед тем как надо отчитываться руководству о "прорыве", нанимаются люди и им ставится задача за месяц написать то, что по хорошему надо было год вдумчиво разрабатывать. По итогу успешный менеджер сваливает на повышение, прогнувшись перед руководством, провал проекта сваливают на тупых разработчиков и мелочь типа тимлидов, после чего все незамедлительно приступают к другому столь же прорывному проекту. Не шучу, практически дословное описание одного из проектов в котором лично имел неудовольствие поучаствовать. Сейчас бы я сразу свалил с такого, тогда еще был молодым и наивным..
мой племянник 27 лет ха-ха-ха (фронтендер) недавно сказал, что устал от бесконечной гонки технологий и хочет уйти в бэк-енд на яву, где вроде поспокойней
На поверку оказывается, что "медленное" программирование не "медленее" быстрого, а вот затрат на него надо в разы меньше. Что технических, что эмоциональных.
Впрочем, пусть расцветают сто цветов, пусть соперничают сто школ (с). В идеальном мире должны быть и спринтеры и марафонцы. В конце концов людям с разным темпераментом и в разное время оказывается комфортнее в разных концепциях.
Интересная статья. Спасибо. Медленная работа приходит также с опытом. Когда начинаешь замечать, что ты за свой, условный час выдаёшь похожее количество результата, как твои коллеги за неделю. Ты можешь смотреть вперед и делать за раз правильные шаги, не заниматься пржиранием времени в бесконечных встречах, работать безошибочно, иметь в головемного паттернов для решения любых задач, в личных библиотеках иметь наработки, которые мгновенно можно использовать итд.
Чем хуже написан код, тем больше работы он провоцирует своим существованием.
По факту можно работать медленнее и мудрее и успевать гораздо больше
Золотые слова!
На самом деле вы описываете обычное поведение профессионального инженера. Все типичные истерики бизнеса и менеджмента о том, что фича нужна вчера и поэтому нам нужно наговношлепать что-то как-то и без тестов - это дешевый балаган для новичков. Профессионала наняли за большие деньги ровно затем, чтобы код был чистый, быстрый, надежный и протестированный. Если по мнению профессионала это занимает столько-то времени, то на этом разговор о времени в общем-то и заканчивается.
Проблема: хорошо работать невыгодно. И руководство считает работу по заявкам Jira. Мне пишут, что мало делаю (DevOps). Видимо надо тяп-ляп, потом новые заявки и новые исправления. Зато по статистике все Ок.
Когда-то уже давно я работал в одной, которая уже тогда была г..ном, компании, так вот там так и было - разработчики, которые писали быстро и без ошибок, оценивались как те, кто мало работает, т.к. якобы маленькие временные затраты и наоборот, те кто писали долго, в своем долгом коде допускали кучу ошибок, на которые потом получали кучу риквестов на исправление - те получали более высокие премии, т.к. по трудозатратам выходило, что они больше работают - вот такой бред. Я прям видел, как некоторые особенно хитропопые кодеры прям с наслаждением слушали мои к ним претензии, что они опять в очередной раз нагадили в уже в прошлый раз исправленном месте и довольно улыбались, предвкушая как они будут меееедленннно исправлять свои же ошибки, с постоянными перекурами и чаепитиями и потом за это получать деньги. А меня наоборот бесил этот подход, что это как гиря на ногах, когда ты хочешь сделать задачу и взять новую, но за это ты получишь меньше тех, кто мусолит одно и то же годами. Еще запомнился один момент, совещание, идет обсуждение будущего запуска приложения и необходимого для этого перерыва в работе заказчика, так вот коллега заявляет, что ему надо 16 часов на конвертацию данных, а я прекрасно зная, что он использует костыльный конвертер, который в свое время я тоже дорабатывал, он мне как раз не понравился, я от него отказался и написал все на PLSQL, используя фичи Оракла, чтобы максимально быстро загрузить данные в БД я мог этот объем данных, а там речь шла про данные всего 2000 клиентов, залить меньше, чем за минуту на то, что этому коллеге понадобилось 16 часов, так вот я озвучиваю эту информацию, что коллеге стоит взять мой уже готовый и много раз использованный конвертер, который решит его проблему и загрузит все за минуту, но для этого коллеге придется наконец-то познать PLSQL, т.к. мы работаем с Ораклом и это его обязянность, на что от манагеров, что присутствовали на совещании я услышал, что дескать не может быть, чтобы то, что работает 16 часов можно было сделать за минуту и самое убойное, что то что работает всего лишь минуту - это фигня какая-то, а вот то что работает 16 часов - это крутая вещь, которая пашет целых 16 часов и это в софтверной компании происходило)). И до сих пор, я уже сменил несколько компаний, но везде одно и то же, что пахать то ты можешь больше и быстрее других, быть умнее и производительнее других, знать больше и лучше других, принимать благодаря этому оптимальные архитектурные решения и делать изящные и мегапроизводительные вещи, но получать ты будешь столько же, а то и меньше самого медленного и специально имитирующего работу коллеги, т.к. для манагеров трудной задачей считается та, которую долго делали и наоборот, то что сделали быстро - это значит было легко и платить там не за что. А еще проблема в том, что манагерами и тимлидами над разработчиками становятся не лучшие из лучших разработчики, а худшие из худших, которым как раз вся эта тема малоинтересна, а им интересно свою попу примастить на чужой шее и получать деньги за чужие достижения.
Последние полтора года так и работают над своим проектом. Единственное, на что нужно обращать внимание - это ритм, медленно - не значит мало. По результатам работы - даже тот же объем проделанной работы оказался выше, чем обычно, только это заметно не через неделю, а через год.
Какие плюсы получил: поскольку работаю один, то приходится все автоматизировать и обвязывать кучей различных тестов, чтобы не тратить время на выискивание проблем. Каждый шаг приходится продумывать, чтобы не ошибиться и потом не переделывать
Минусы вдумчивого подхода: это продумывание необходимости использования того или иного тренда. Многие вещи упрощаются, даже при продумывании дальнейшего роста продукта - все равно стараешься сделать проще и понятнее, пропало много модных слов Spark, Kafka, Java 25 версии и Rust лучше всех и т.д. - используются только то, что действительно необходимо. Много трачу времени на продумывание схем данных и т.п.
По результатам было две DDoS атаки, два раза падала сеть, но я очень рад, что система выдержала рост запросов и вела себя достойно. Были шероховатости, но для меня результат - что не упала, с учетом что всего один домашний сервер (десктоп мини-пк).
В сухом остатке: я в таком ритме чувствую себя комфортно, даже не сбиваюсь с планов. Ожидаю в сентябре выйти в публичный доступ.
Все так. Я тоже в какой-то момент решил поэкспериментировать и написать более-менее работающий продукт без внешних зависимостей (реакта там, сборок, вот этого всего). Кайфовое заняте
ChatGPT скоро сможет заменить разработчиков. Достаточно будет лишь правильно поставить задание, и решение — раз и готово! Безо всяких сроков и затрат — полная противоположность медленному программированию.
аха, как показывает мой опыт правильно поставить задачу оказывается едва ли не сложней чем написать сам код. Зачастую у нас приходится интуитивно писать код, по ходу разбираясь как скрестить хотелки заказчика с тем что есть.
Я трехмерщик и стараюсь не использовать в своих проектах чужие модели. В итоге у меня огромные локации километрового размера занимают десятки мегабайт в памяти (т.к. всё что можно оптимизировано), зато какая-нибудь сторонняя модель ёлки может весить двести мегабайт.
И меня очень удивило, что далеко не всем заказчикам нужен фотореализм, есть много людей кому нравится когда выглядит по-компьютерному, эскизно.
бизнес нацелен на быстрое получение прибыли и опережение конкурентов;
То есть, проще говоря, коммерция убивает технологию в пользу сроков
увеличение трудозатрат снижает прибыль и конкурентоспособность решения;
измерение конкурентоспособностью качества работает в среднем на ухудшение качества. Потому что при определенном соотношении цена\качество цена играет первичную роль, есть достаточно небольшое поле, где качество перебьет цену.
игра не стоит свеч — идеальный сферический продукт в вакууме, на разработку которого потрачен год, устаревает через месяц после выпуска;
концептуально продуманный продукт не устаревает, как правило. Как, например, может устареть продуманная на хорошем концептуальном уровне программа для распознавания печатного текста из изображения? Никак. К ней можно прикручивать словарики и алгоритмы проверки и установки, но определять, где буковки, а где фигня - это никогда не устареет, разве что в электронку переведется весь текст в мире. Для софта основной фактор концептуального устаревания - развитие "железа". Например, гипертерминал устарел для массового использования, так как появились массовые дешевые и быстрые железные решения связи между девайсами мимо кабеля. Но таких продуктов меньшинство, и грамотно продуманное ядро использоваться может годами, и там не требуется ничего трогать, особенно если там легко модульно накручивать новый функционал.
все хотят знать, когда получат прибыль — бесконечные проекты с невозможностью прогнозирования сроков и результатов никому не нужны;
вообще-то социально значимая задача должна решаться до момента РЕШЕНИЯ задачи, и столько. сколько требуется для РЕШЕНИЯ ЗАДАЧИ, а получение прибыли вообще к решению задач не относится никак. Если прибыль никто не получит, но социальная проблема будет решена, получается, решать ничего не надо? Вот по такому принципу и не решается огромное количество проблем.
шедевры никому не нужны, рекорды продаж — у однодневных поделок.
ориентация на рекорды продаж - путь к технологической деградации. Вместо вдумчивого переписывания и структурирования ранее написанных программ миллионы программистов занимаются прикручиванием пустопорожних свистоперделок побыстрей в продакшн, чтобы опередить конкурентов. Результат немного предсказуем.
Вообще, имхо, технологии в IT развиваются в основном не благодаря рыночной гонке за прибылью, а вопреки. Коммерсанты наклепают в продакшн, а потом люди годами сидят и правят баги. Буквально вчера наткнулся на микрософтовскую ошибку - на мелкософтовском форумчике висит уведомление, что они-де знают об этом, но решений не дали (прошло 9 месяцев), патчем не закрыли, обратной связи нет, какой-то испаноязычный парниша дал скрипт на PowerShell, как принудительно закрыть кривой процесс, но и это решение работает через раз. А "десятка" уже несколько лет с этой ошибкой живет, уже 11-ю версию выпустили, потом будет еще, но дописывать не будут. Потому что им затратно - прибыль берут себе, а затраты раскладывают на пользователя,на исправление ошибок кладут болт.
Вообще, в последние годы все стали бредить disruptive technologies, никому уже не нужно медленно выгрызать долю рынка качеством, все хотят перевернуть стол.
И не решаете её лично вы с единомышленниками за бесплатно потому, что… Почему?
Вот и другие потому же не решают.
- Вообще-то каждый гражданин так или иначе несет на своих плечах огромное коичество общесоцйальных функций, не приносящих прибыль. Банально - не сорить в транспорте, это тоже социальная функция, выполняемая бесплатно. Показать коллеге, как пользоваться кофе-машиной - тоже социальная функция, выполняемая бесплатно. Уступить место старушке - тоже социальная функция, выполняемая бесплатно. Корпорации кричат об ответственности бизнесмена, типа,, ответственность у него огромная, потому-де такие огромные деньги совершенно бездарные личности типа Сечина кладут в карман, а как вопрос встает о том, что что-то сделать бесплатно, эта "социальная ответственность", уже оплаченная им прибылью, тут же испаряется, и вы здесь выступаете бесплатно (!) глашатаем безответственности бизнеса :) То. что вы несете - это либеральный экстремизм, не побоюсь этого слова, редуцировать в ноль все, не приносящее прибыль. Вы онимаете, что если уничтожить бесплатную медицину, не приносящую прибыль, то по сравнению с последующими эпидемиясми коронавирус покажется легким насморком?
Вы слышали что-то о Bell Labs или хотя бы о всяких Microsoft Research
-по-моему, это должно выливаться в качество конечного продукта, а качество продукта как было, так и есть, "как всегда" :) . А вообще, все, что делают корпорации для развития научной базы производственных процессов, очень и очень, особенно с точки зрения фундаментальной науки, прверхностно. А если не поверхностно, то это почти всегда внешний заказ, как правило военный или государственный - см. та же Bells Lab) Я как-то беседовал с аспирантами химтеха, почему они не идут в лаборатории химтеховских корпораций, а сидят на кафедре, то там все очень просто - корпорации очень утилитарно подходят к разработке и научному поиску и вообще не тратятся на перспективные с научной точки зрения идеи, но не выливающиеся в продакшн, и в ближайшие пару лет, в прибыль. С этой точки зрения военные куда как перспективней - там могут тему вынашивать по десятку лет, и это не зависит ни от настроения собственников бизнеса, ни от положения компании на рынке. Сокращения кадров больней всего ударили по тем подразделениям корпораций, которые работали "на будущее" и занимались нерентаельными исследованиями (тут следует добавить "ваш КО").
Модель будет давать все больше ошибок по сравнению с топовыми.
-с чего бы, если модель продумана? Хорошо математически просчитанная модель вряд ли может быть улучшена. Решение математической задачи может иметь бесконечные результаты, но не может иметь бесконечного количества методов. В 90-х один мой друг писал программки для всяких коммерсов, по мелочи - типа, цветомузыку написать, обсчет датчиков движения (модно было тогда и дорого) и прочая ерунда. Так вот, в принципе, он писал и переписывал разным заказчикам несколько вариантов нескольких программ. В итоге он, например, добился, что у него визуализация звука на экран обрабатывалась в 5 строчек, решение было математически изящным и оптимальным. Он порядка трех лет эти пять строчек вообще не трогал, потому что их было достаточно, потом пошел работать куда-то в Москву и перестал программки писать. Так вот в 2009 году я был у брата на свадьбе - в кафешке мигала та самая цветомузыка, которую друг писал еще в 94-м.
Не понимаю. Живу в стране с околоотсутствующей бесплатной медициной, плачу за платную страховку и не понимаю.
Влезу тут сбоку, но США прям неплохо так разогнались по смертности во времена расцвета ковидной эпидемии. Не могу сказать ничего про Россию, тут данным верить нельзя, но взять ту же Канаду - там картинка значительно лучше была.
Беглый гуглеж говорит, что в США погибло около 1 млн человек. В Канаде - около 60 тысяч.
Как будто бы цифры говорят сами за себя.
Ну даже если отнормировать и умножить канадскин показания на 10, то один фиг ситуация в 2 раза лучше. Таки лишние сотни тысяч жизней - не очень лишние.
Что касаемо ожирения, мне не попадалась на глаза информация о влиянии ожирения на тяжесть ковида. Тут ниче не могу сказать, но и на веру принять его влияние тоже не получается.
Наверное, неплохо бы ещё заглянуть в статистику по смертям от всяких онкологий в США и Канаде. Есть у меня подозрение, что бесплатная Канадская медицина спасает ещё одну кучу жизней.
Кстати, что это вообще значит — работать быстро?
Первые наставления по этому, казалось бы, очевидному вопросу я получил от инструктора парашютного спорта Виноградова, выпускавшего меня много лет назад в первый прыжок с самолёта.
Сейчас парашютистов-перворазников вывозят на больших транспортных самолётах, покидать которые в воздухе довольно просто: парашютист подходит к открытой двери или люку, делает шаг наружу — и все! Для этого надо, конечно, преодолеть некое внутреннее психологическое сопротивление: много миллионов лет назад наш обезьяноподобный предок, свалившись с какой-нибудь скалы, положил начало формированию во всем роде человеческом прочного инстинкта, так сказать, уважения к высоте.
Но никаких специальных навыков, никакого особого умения для того, чтобы покинуть самолёт через дверь, не требуется. Другое дело — У-2, с которого когда-то прыгали мы. На нем парашютисту приходилось, преодолевая сопротивление встречного потока воздуха (все-таки сто километров в час), встать со своего места, а затем, перехватываясь руками за стойка центроплана, вылезти на крыло и устроиться одной ногой на его задней кромке, а другой — на подножке, укреплённой снизу фюзеляжа. Ко всем этим операциям надо было приспособиться.
Виноградов учил нас этому, держа секундомер в руках. Увидев, с какими отвратительно суетливыми, конвульсивными движениями, принимая последовательно самые нелепые позы, какие только можно себе представить, мы выполняем эту операцию, он поморщился и изрёк:
— Вы понимаете, что значит — быстро вылезти из кабины на крыло? Это значит: делать медленные движения, без перерывов между ними…
Впоследствии я оценил всю универсальность этого рецепта, пригодного далеко не для одного лишь парашютизма. Мне кажется, трудно дать лучшую формулировку различия между быстротой и суетливостью.
М.Л. Галлай, "Испытано в небе"
Именно так работают в Японии. Одну работу могут делать вечно доводя до совершенства. Но многие думают, что они просто делают вид, что стараются)).
Работал в Японии программистом и могу подтвердить, что часто они именно делают вид. Имитация деятельности до тех пор, пока не уйдёт начальник, бесконечные совещания потому что никто не желает взять на себя ответственность за провал и многое другое - всё правда. Старательных - единицы, и да, именно на них всё и держится.
Количество деятельности, что в быстрой разработке и что в медленной, одинаково, кмк.
Просто в быстрой разработка идет в "ширину", когда как в медленной разработке в "глубину". Менеджменту также сложно объяснить резонность такого подхода, ибо им сложно без технической базы смотреть и сравнивать эффективность. Их особо не волнует как и что там работает и как нагружается система, лишь бы эффективно все продавалось.
Могу конечно ошибаться, но считаю, что медленный подход лучше для той части разработки, которая не попадается на глаза, например - серверная часть. Менеджменту там в принципе сложно что то показывать из бэкенда, для них это нечто неизмеримое. Тогда как тот же самый фронтенд проще дебажить и тестировать ввиду бОльшего количества отзывов, как минимум, потому что это "на виду".
Остановись, мгновенье… не остановится, слишком многие с этого кормятся. Между реальными разработчиками и реальным бизнесом давно уже сформировался мощный слой «специалистов» с невнятными обязанностями, громкими должностями и огромаднейшим самомнением.
Думаете, сгущаю? Набольший начальник городской услышал, что без цифровизации нынче никуда. На второй странице букваря для менедженеров, чуть ниже знаменитого «Требуй невозможного, получишь желаемое», есть еще одна «мысля»: «нельзя управлять тем, что не измерено». Вот и меряется уже третий год «уровень цифровизации муниципальных предприятий». Родили список из ста с лишним показателей. К каждому показателю долго обсуждали веса. Сурьезное ведь дело, с кондачка негоже решать. Курсируют во всех направлениях анкеты, заполняются показатели. Опять же, все знают, что показатели должны только расти год от года, это же первая заповедь. Потому, меняют методику, заполняют анкеты заново, добиваются того, что нужная цифирь начинает выглядеть прилично. А уж какой простор для «онолитиков», графики с точками, кружочками, треугольничками и квадратиками… Большая наука!!! Вот и год прошел… Подключились «быстрые» разработчики, дашборды, мобильное приложение. Все - как у взрослых, спринты, ревью, бэклог…
Это еще хорошо, что у нас так и не завелся департамент методологии с отделом методологии. Несколько месяцев назад тут статеечка была про то, как большой туз из этого методологического цирка спас проект, который без знания прежними руководителями методологии был обречен. Сначала были по головам пересчитаны все исполнители проекта, цифра была не ах, то есть без размаха, потому у руководства были вытребованы дополнительно десять голов разработчиков. Ну, понятно, чем ближе к сдаче, тем начальство податливее, посему были истребованы дополнительные нехилые деньги, грех не воспользоваться. Справились. Частично, остальное в рабочем порядке.
Что показательно, детки не очень большого начальства, если в АйТи взять, у нас пристроены все на позиции как раз не программистские. А что, анализ рынков, наблюдение за конкурентами, аналитические отчеты, раздача ценных указаний, почту разобрал - хорошо поработал.
Давно уже скачал «Тиранию показателей» Мюллера, втюкиваю ее всем, кому можно. Ничего не меняется…
Есть возражения по терминологии. Перфекционизм имеет несколько значений. И в вашем применении скорее психология, психиатрия - это уже про неврозы и психозы со следствием в виде перфекционизма, но не причиной. А замечу, что перфекционизм также присутствует в философии, и там это не расстройство, а стремление улучшать там, где видишь потенциал и есть идеи. Позитивчик в общем.
Далее также выбираете очень узкое значение слов. Бизнес - это не только спекуляция. А большая часть общественной жизни с кучей всего и вся. Ну и код также - это не только текст, но и инженерная мысль. У нее есть жизненный цикл как у всего, но это не просто набор символов точно.
+1 к карме за правду :)
А что такое реальный проект?
Очень наивно полагать, что всё IT - это галеры, стартапы и бешеная гонка только за быстрой прибылью.
Представьте, что нет nginx, postgres, linux, да и ЯП самих (их вообще пишут больные ублюдки оторванные от реальности). Много ваш бизнес денег заработает?
А вот и нет. В других сферах народ тоже заморачивается с перфекционизмом и это нормально.
Например, в книжке "дао Тойота" рассказывается, как много внимания японцы уделяли процессу улучшения производства и как в итоге смогли дешёво и гибко производить очень надёжные автомобили.
Или, например, в мастерской можно красиво разложить инструменты по шкафчикам/полкам. И никто не говорит "да это розовые страдания, лучше в одну кучу всё свалить"
Можно при обслуживании автомобиля ставить оригинальные запчасти, а можно чинить как попало и чем дешевле с применением изоленты. В итоге лет через десять первый автомобиль будет как новенький, а второй превратится в разваливающееся ведро с болтами, которое проще выкинуть.
Можно сесть играть в факторио и построить лапшу из конвейеров. Добавление каждой новой лапшинки на первый взгляд проще, чем "красивая" организация, но через какое-то время макаронную фабрику станет проще снести и заново построить, чем расширять. Спидраннеры, как ни странно, почему-то строят довольно красивые фабрики.
Аналогично в дата-центрах почему-то всякие провода и т.п. стараются красиво проложить, а не как попало. Наверно, от безделья.
И не надо к этой красоте стремится. Код должен работать и выполнять свою функцию - приносить результат.
Красота и перфекционизм - это способ упрощения и борьбы со сложностью. Чем сложнее система, тем больше внимания надо им уделять. Иначе станет только хуже.
через какое-то время макаронную фабрику станет проще снести и заново построить, чем расширять. Спидраннеры, как ни странно, почему-то строят довольно красивые фабрики.
На определенном этапе развития стартовый билд станет проще снести или бросить, чем использовать, независимо от того, насколько хорошо он спроектирован. Когда стартовая база произвела достаточно материалов для новой базы на более совершенных технологиях — абсолютно неважно, превратилась ли она в нерасширяемое спагетти полностью или только наполовину.
Нет никакой необходимости держать сложность максимально возможно низкой все время игры. Если вы в состоянии справляться с высоким уровнем сложности и балансировать ресурсы в уме — вы построите эффективное на данном этапе спагетти, если нет — придется уменьшать сложность и делать красиво, жертвуя скоростью. И уж спидраннеры умеют справляться со сложностью просто замечательно.
В типичном спидране после запуска ракеты база вполне вероятно будет просто нефункциональной, и ни о какой легкости расширения речь, разумеется, уже не идет.
Спидраннеров не смотрел, но полностью согласен, что по итогу, скорее всего, придётся всё старье сносить, неважно, как красиво это могло быть в самом начале. Либо это всё займёт много места, что приведёт к необходимости защищать большие территории
Но при этом я все равно везде, где берусь, стараюсь сделать как можно идеальнее (бывало, разбирал почти собранные ТВ, если казалось, что забыл какой-нибудь винт или защёлку под рассеиватель поставить, снимал заново ШРУС, когда показалось, что не защелкнулся стопор и т.д.). С другой стороны, я также собирал всякие платы 3д монтажом (всякие самоделки), поскольку это всё равно только для проверки. По итогу я бы сказал, что it depends. В качестве временной меры сойдёт любая лапша и любая изолента, кто-то гонял с бутылкой бензина, когда крякнул бензонасос по дороге (карбюраторное авто), я лепил провода к фарам, когда одному человеку нужно было срочно уезжать, а была почти ночь
Никого, кроме программистов не интересует красота кода.
Верно. Но программист-то вы! Если кого-то не интересует красота вашего кода - это его дело; возможно, для вас она составляет элемент самоуважения - т.е. скорее психического здоровья, а не расстройства.
Для программиста скорее путь "сделать все под бизнес, сию секунду" ведет к уменьшению самоуважения себя как профессионала и к расстройствам.
При хорошем умении говорить, очень даже легко можно продать бизнесу идею, что качество кода напрямую влияет на успехи бизнеса, как и качество архитектуры.
Все эти параметры влияют на прибыль бизнеса, а ещё они влияют на стабильность, ну грубо говоря, всегда есть вероятность, что команда разработчиков разбежится просто, если у нее будет низкая мораль, а их мораль активно падает, если разработчиков заставляют перерабатывать и вообще не дают времени исправить проблемы. А нижняя мораль повышает вероятность наступления полярного лиса, который просто обрушит весь бизнес нафиг, или принесёт большие убытки.
Стремление к совершенству, т.е. перфекционизм, является одним из психических расстройств.
Если вам не нравится восхищаться тем, что выходит из под ваших рук - ваше дело. А мне доставляет удовольствие как результат, так и процесс. И не только в программировании, но и при приготовлении пищи, работы в огороде, создавании и распайки плат, постройки всяких строений как в доме, так и вне итд. Помню даже когда как 21-летрий переехал в Германию и первое, что делал - мыл машины в автосалоне, то мыл их припевая песнями. У психиатров вроде не числюсь на учёте :)
Можно работать ради денег, а можно получать удовольствие и при том за это получать деньги.
Если вы хотите совершенства - нужно выбрать другую сферу, типа архитектуры или строительства, искусства или музыки.
Боюсь, что от сферы это не зависит. В архитектуре и строительстве абсолютно то же самое - заплатка на заплатке и костылем погоняет. А в последнее время еще контроль со стороны госорганов постоянно под мораторием.
С искусством и музыкой изнутри не сталкивался, но не думаю, что там какие-то другие цели у бизнеса.
"Эффективный манагемент" нонче предпочитает загнать техдолг к потолку, а затем перейти к новым инвесторам, к сожалению.
Люди хотят, чтобы их наконец оставили в покое и дали пожить в своё удовольствие.
Статья в целом интересная, но вот это предложение очень сильно смутило. А кто должен оставить людей в покое? Кто заставляет бегать между кучей городов, делать гору фотографий, есть фастфуд на бегу, пролистывать клипы или быстро что-то рисовать? Очень часто оказывается, что этих злодеев в реальности не существует, а человек почему-то думает, что так нужно делать, или кто-то его заставляет.
Даже в том же злом коммерческом ИТ я редко видел, чтобы кого-то реально заставляли работать очень быстро или перерабатывать. Часто ситуации выглядели так:
- Сколько времени нужно на то, чтобы сделать Х?
- Две недели, ну или неделя, но тогда все плохо будет сделано
- А что значит плохо? К чем это приведёт в будущем?
- Ну, это, техдолг, сложно писать будет дальше, ээмммаээээмммм, плохо будет, короче говоря
- А конкретно что будет плохо, давайте обсудим и поймем
- Аааа, ээээ, пофиг, через неделю будет готово
А через полчаса этот разработчик жалуется коллеге, что его заставляют говнокодить.
Очень часто оказывается, что нет никакого влияния злых людей или общества, а есть странные установки, возникшие по какой-то причине. И в этом есть определённая проблема «медленной» деятельности: человек может начать стремиться к получению удовольствия и счастливой жизни не через понимание проблем и их причин, а через противостояние каким-то, часто несуществующим, внешним воздействиям. И это может привести к гораздо большим проблемам в будущем.
К медленному программированию прилагается медленная зарплата.
Какой прекрасный материал! Вот именно поэтому я и ушёл из классического коммерческого IT, оставив себе один любимый проект, который делаю так, столько и тогда, как сколько и когда я хочу. И вот тут вернулся кайф.
А когда вернулся кайф, все вокруг почему-то начали меня слушать. Видимо потому, что чувствуют этот кайфовый вайп, и хотят также. Так меня нашли три новых проекта, в которых я не делаю почти ничего, кроме размышления о том, как правильно их сделать. И самое удивительное, как оказалось, люди ценят этот навык и готовы брать в бизнес просто за это.
В мире "эффективок", всех тянут в эффективность... От этого слова уже тошнит, когда менеджеры или инфоцыгане начинают произносить.
Но молодежь рада быть эффективной и быстрее влиться в работу, что идет в разрез с теми, кому за 30 (((
Но приходится держать планку... Иначе окажешься на обочине "эффективной" магистрали (((
игра не стоит свеч — идеальный сферический продукт в вакууме, на разработку которого потрачен год, устаревает через месяц после выпуска;
Это какое-то когнитивное искажение, есть, конечно, категория мусорного софта - всякие там программы однодневки с кликбейтными названиями, чье главное предназначение это привлечь внимание пользователя, быть установленными на компьютер (телефон), показать ему пару-тройку проплаченных рекламок и быть навсегда удаленными. Но далеко не все программы сейчас такие, к счастью.
Горячо одобряю и рекомендую!
Я именно поэтому и пишу все на ассемблере. Пока получается прекрасно!
Зачастую, чтобы написать быстро, нужно писать медленно. Быстрое клёпанье может замедлить разработку в целом на дистанции.
Законы природы не обмануть. Для ремесленного формошлёпства вполне годятся потогонные схемы, особенно, если гребцы молодые и мускулистые. Их можно бить кнутом, выдавать повышенное содержание и литры кофейной жижи. Для всего чуть более серьёзного нужны вдохновения (хотя бы у одного элемента из всей системы в один момент времени), озарения, превентивные меры защиты от выгорания (которое является вполне себе перегрузкой с выходом в органическую депрессию). Поэтому автора поддерживаю -- медленному программированию было место 30 лет назад, будет место и через 30 лет (но это уже будет другое программирование других систем, скорее всего биологических, скорее всего будут заново переосмыслены воспитательные методики)
В бизнес это можно продвинуть, если там есть культура качества и забота о репутации. Но в первую очередь их заботит быстрая прибыль. Вы можете вставить пример про медленную прибыль в статью и он не будет выглядеть так радужно. Как упомянуты типы проектов, где может быть реализовано медленное программирование, там как раз отсутствует быстрая прибыль и вообще какая-либо возможно.
Тогда в чём ценность написанного? Как методичку по переходу на медленное программирование бизнесу не скинуть.
Остановись, мгновенье. Медленное программирование — тренд для уставших разработчиков