Comments 57
Статья интересная, но на мой взгляд автор все-таки уходит в другую крайность от тяп ляп и в продакт. Вспоминается эпизод в «автостопом по галактике», про разбившийся корабль менеджеров и рекламных агентов, где они бесконечно планировали и проводили совещания вместо того чтобы просто нарубить дров и собрать еду. Перепланирование, так же плохо как и попытка все решить наскоком.
Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
UFO just landed and posted this here
Мой стиль программирования предполагает абсолютно разную длительность работы над проектами самой разной сложности. Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных. По сути, все это можно сравнить с конструированием лесов вокруг строящегося здания. Постепенно картина вырисовывается. Немного позже, я возвращаюсь к работе, расставляю все точки над «i» и наношу последние штрихи.
Планирование != проектирование. Одно дело провести планнинг на целый день и потом в первый же час разработки найти деталь, которая ломает все планы, и совсем другое дело попробовать несколько подходов, увидеть достоинства и недостатки, «переспать с идеей» и наконец выбрать оптимальный путь.
Мне кажется, речь в статье идёт не о планировании, речь идёт о "жадном" решении задач. Буквально на днях услышал такой метод распределения задач на спринт: все оценивают, сколько времени у них займёт выполнение задачи, и тот, кто дал минимальную оценку, берётся её выполнять.
Бред.
Если разработчик знает, что он может быстро выполнить задачу, то либо он выполнял её сотню раз (что уже подразумевает, что он плохой разработчик), либо что он просто не вложил в обдумывание задачи достаточно времени. Прикрутить костыль всегда быстрее, чем продумать серьёзные изменения в модуле. Написать пару дополнительных тестов всегда быстрее, чем пересмотреть назначние компонента. Но решение локальных задач далеко не всегда означает глобальное улучшение продукта.
О, какая тема.
Можно написать статью «О медленном планировании». Где описать тех, кто быстро спланировал цель, не рассмотрел риски и ограничения — быстро получил некачественный код, решающий задачу.
Или написать статью «О медленном проектировании». В ней рассказать о тех, кто спроектировал архитектуру, но не спроектировал интерфейс, сделав его неудобным. Или наоборот — удобный интерфейс при слабой архитектуре. Быстрое прототипирование, обернулось быстрым прототипированием прототипов.
Можно написать статью «О медленном планировании». Где описать тех, кто быстро спланировал цель, не рассмотрел риски и ограничения — быстро получил некачественный код, решающий задачу.
Или написать статью «О медленном проектировании». В ней рассказать о тех, кто спроектировал архитектуру, но не спроектировал интерфейс, сделав его неудобным. Или наоборот — удобный интерфейс при слабой архитектуре. Быстрое прототипирование, обернулось быстрым прототипированием прототипов.
Как-то ожидал увидеть success-story медленной разработки, но увидел только утверждение «медленно — хорошо. точка.»
И, судя по всему, автор забывает, что бизнесу нужен не качественный продукт, а продукт с максимальным показателем отношения качества к цене разработки и в каких-то рамках по цене, качеству и срокам. Т.е. плохой продукт реально может быть более выгоден бизнесу, чем хороший.
И, судя по всему, автор забывает, что бизнесу нужен не качественный продукт, а продукт с максимальным показателем отношения качества к цене разработки и в каких-то рамках по цене, качеству и срокам. Т.е. плохой продукт реально может быть более выгоден бизнесу, чем хороший.
Иногда, сделав изначально слишком хороший продукт даже за тоже время/деньги, есть риск в бизнесе проиграть. Идеальный продукт не глючит и его не нужно дорабатывать, следовательно заказчику нет смысла платить за сопровождение и доработки, следовательно можно потерять изрядную сумму от этого заказчика (правда получив некий плюс к репутации).
Идеальный продукт можно сделать в идеальном мире. В реальном же мире можно сделать продукт в два раза дороже и в два раза медленнее, который (если повезет) глючит немного меньше. Пока конкуренты сделали одну версию, протестировали ее на рынке и поняли, что этот подход не работает и надо все фичи выкинуть и сделать с нуля по-другому.
Не идеальный продукт, я имел в виду немного другое. Например, делал я как-то я во фрилансе некоторый парсер данных в один интернет магазин, сделал по-правильному, чтобы парсер висел, постоянно проверял обновление и допарсивал новые данные, а оказалось что заказчик вообще-то рассчитывал на одновременный перенос данных, а за доработку парсера, чтобы он мог обновлять данные, хотел заплатить ещё примерно столько же позже. В результате, я получил некий абстрактный плюс в «репутацию», но потерял в деньгах.
В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
Сорри, невнимательно прочитал ваш комментарий. Теперь понял, о чем вы.
Это не тот случай, вы просто недопоняли требования. Я, кстати, в подобной ситуации не стал бы такого делать, потому что стараюсь вести себя как lazy quantifier в регэксах — нужно делать то, что оговорено, а любую неясность уточнять. В конце концов, и клиент, и я, оба хотим заработать больше денег, потратив меньше времени.
Если «медленный» подход позволяет достичь большей надёжности, имеет смысл применять его в критичных к этому задачах.
Доработка продукта — не обязательно исправление багов, сопровождение включает в себя также фичи и улучшения, не связанные с конкретно реализацией: изменился процесс, законодательство, стало больше серверов и так далее.
Доработка продукта — не обязательно исправление багов, сопровождение включает в себя также фичи и улучшения, не связанные с конкретно реализацией: изменился процесс, законодательство, стало больше серверов и так далее.
Но совсем куча г-на — это тоже плохо. Нужен баланс. Техдолг никто не отменял.
Я вот, честно, не знаю как в остальных отраслях, да и программированием мою занятость назвать нельзя, но я часто вижу и натыкаюсь на проекты, где меня просят писать как можно более поддерживаемый, продуманный код, который можно реюзать еще много раз. Притом все понимают, что это затратно по времени. И даже платят мне (спустя месяцы продакшена) еще + 10-20% от стоимости изначального проекта (учитывая что оплата была почасвоая), если бекендерам всё понравилось. Я пишу на html/jade + less/sass. Это редкость, разве, для других?
Всего должно быть в меру. Некоторое время назад, я очень дорожил «чистотой» своего кода, что сводилось к довольно высоким затратам на проект (и более того, те, кто сейчас продолжают мою работу, идут по тому же пути). Сейчас, несколько пересмотрев свои взгляды, могу сказать, что если мы говорим о работе, то я выдаю результат ASAP, порой действительно не вдаваясь в глубокое проектирование. Однако когда я прихожу домой и открываю свои проекты, я скрупулёзен и педантичен в каждой строчке своего кода. Просто стоит разделять программирование «для себя» и «процесс разработки продукта, приносящего деньги» для заказчика. Это не значит, что в коде для клиента всё должно быть тяп-ляп, просто избавьте себя от рефакторинг-ононизма до момента релиза продукта, это сэкономит вам кучу времени, заказчику — затраты, а компании принесет деньги.
И это ОЧЕНЬ грустно.
Настоятельно рекомендую к прочтению книгу Г.Форда «Моя жизнь».
5 лет подготовки к производству трактора и потом 20+ лет производства без единого изменения.
Таких тракторов (и таких людей) сейчас уже не делают.
Настоятельно рекомендую к прочтению книгу Г.Форда «Моя жизнь».
5 лет подготовки к производству трактора и потом 20+ лет производства без единого изменения.
Таких тракторов (и таких людей) сейчас уже не делают.
Мне кажется автор ничего не забывает. Ведь «плохой продукт» также требуется спроектировать и умышленно пойти на потерю качества ради скорости создания продукта. Т.к. если плохой продукт будет получаться сам-собой, только потому что я херачу по 100 строк в минуту, то кроме плохого продукта в довесок я получу еще и непонимание как он работает и совсем в нем запутаюсь. Я лично использую медленное программирование при создании плохих продуктов и в свободное время (если есть) всегда стараюсь спроектировать действительно хорошее решение на черный день. И когда мне говорят «всё офигенно, но база не выдерживает нагрузку», я говорю, что ничего удивительного, выделите время и я это исправлю.
плохой продукт реально может быть более выгоден бизнесу, чем хорошийОбычно лишь в краткосрочной перспективе. Если плохой продукт затем приходится сопровождать, то низкое качество исходного продукта может легко вылиться в то, что называется maintenance nightmare, и стоимость такого сопровождения может перекрыть изначальную экономию.
:) Теперь у меня появилась теоретическая база, чтобы объяснять команде, почему я так медленно работаю.
Мдаа, без success story действительно выглядит как-то не очень убедительно все это. То что автору некомфортно работать в таком ритме еще не значит, что все остальные работают плохо.
Автор столкнулся с командой говнобыстрокодеров, которые фигачили всё в мастер, не используя ветки? Сочувствую.
Принцип каждый может изменить что угодно и никто ни за что не отвечает тоже странноват — это просто уничтожение ответственности. Хотя бы за куски / компоненты д.б. личная ответственность. Но только для тех, у кого имеются наружные признаки мужчины конечно.
Принцип каждый может изменить что угодно и никто ни за что не отвечает тоже странноват — это просто уничтожение ответственности. Хотя бы за куски / компоненты д.б. личная ответственность. Но только для тех, у кого имеются наружные признаки мужчины конечно.
я ровестник автора, мне его позиция очень близка, спасибо за статью
UFO just landed and posted this here
Да, сталкивался с ситуациями когда куча народа неделю и больше обсуждает и планирует функционал (причем каждый тянет в свою сторону), который за пару дней силами одного разработчика можно сделать, отладить, выкинуть, пару раз переписать и выдать уже готовый и отлаженный продукт, учитывающих косяки, которые никаким планированием не поймать. ИМХО, чрезмерное планирование, такое же зло, как и быдлокодирование без всякого плана.
Все зависит от сложности системы. Одни прототипы можно легко выбрасывать и переписывать, другие — нет. Недавно столкнулся с ситуацией, когда прототип умудрялись тянуть на костылях и велосипедах больше года, и процентов 90 функциональности было реализовано, но в конце оказалось, что получившаяся архитектура в принципе неспособна потянуть оставшиеся 10%. Ничего не подозревающий заказчик, наблюдая за прогрессом, ждал результат очень скоро. Система формировалась на глазах… Было очень непросто объяснить ему, что на 10% потребуется еще 100% времени. А вот если бы эти разработчики (индусы, кстати, хз, совпадение ли) хоть недельку в самом начале провели с секатором в размышлениях — кто знает… Прототипы могут затягивать — с ними все время кажется, что цель приближается… Отчасти это вопрос удачи — выдержат ли костыли в фундаменте полную функциональность или все рухнет в самом конце.
Это вы про Билли?
UFO just landed and posted this here
быстрое программирование ещё ничего. а вот оголтелое — уже проблема!
> Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных
Мне стало страшно. Временные переменные хороши, когда у тебя нет даже намека на план решения задачи. Но позже уже вступает в дело опыт и выучка — за что профи и платят, собственно. А если каждый раз начинать с хаков, то, видно, задачи все время совсем необычные, и опыт не помогает?
Мне стало страшно. Временные переменные хороши, когда у тебя нет даже намека на план решения задачи. Но позже уже вступает в дело опыт и выучка — за что профи и платят, собственно. А если каждый раз начинать с хаков, то, видно, задачи все время совсем необычные, и опыт не помогает?
Хаки нужны, чтобы проверить теорию. Система контроля версий позволяет удалять их бесследно. Иногда придумываешь несколько вариантов развития архитектуры, причем друг с другом несовместимые и на качественную реализацию каждого нужен, скажем, месяц. А система уже до того немаленькая, что любые попытки продумать последствия в голове взрывают мозг. При этом каким-то местом ощущаешь, что правильный вариант только один. В этом случае лично мне проще начать делать один из вариантов «напролом» — без инкапсуляции, с глобальными переменными, если так быстрее и т.п. Обычно уже в этот же день натыкаешься на на какую-то концептуальную проблему, типа «класс двигателя внутреннего сгорания для корректной работы требует ссылку на таблицу с днями рождения водителей» (пример надуман). Сразу понимаешь — идея плоха изначально, трат времени не достойна, откатываемся…
Да, как для случая со сверхсложными проектами, это, возможно, и вариант. Но стадия проектирования для того и есть, чтобы не приходилось бежать впереди паровоза, строча как из пулемета хаки и быстрый кривые кусочки кода, служащие для проверки идеи. Наоборот, когда сели, продумали, что класс ДВС будет состоять из того и того, а вся машина собрана так и так, нужно потрудиться (впрочем — от сложности проекта зависит), чтобы ДВС не работал без таблицы с д.р. А если так и получится, что будет понятно, почему, и понятно же, стоит костыли творить, или так оно и быть должно (вопреки нутряной логике простого, не знакомого с темой, человека).
В программировании, как и во многих других видах деятельности, бывает нужна и быстрая тупая, и вдумчивая работа. Не стоит пренебрегать ни той, ни другой, хотя, конечно, у каждого есть свои предпочтения. Мне тоже больше по душе «медленное программирование».
PS. Не пойму, за что так не любят частицу «ни».
PS. Не пойму, за что так не любят частицу «ни».
На мой взгляд, от поспешности в разработке в итоге проигрывают практически все, если это конечно не работа над типовым сайтом-визиткой, а что-то более сложное.
Я не вижу примеров быстрой разработки «на выброс» среди производителей-лидеров, какую бы область я не посмотрел.
Самые классные и запоминающиеся игры делают всякие близзарды, валве, бетесды и т.д. И каждую свою игру они разрабатывают по много нет и не спешат с выпуском.
Тоже самое с хорошими фильмами. Лучше гладиатора я до сих пор ничего особо не видел, и фильмы практически перестал смотреть, потому что почти все они делаются в наши дни на выброс, а не с целью передать обществу что-то полезное.
Я к тому, что спешка с выпуском продукта оказывается выгодной в короткосрочном плане, но в долгосрочном плане она практически всегда не выгодна вообще никому. Если продукт не особенно хорош, то через какое-то время про него просто забывают. С другой стороны, я до сих пор не могу поставить рядом с хл1 и хл2 какую-либо современную игру по уровню сюжета, продуманности мира… Всё, что было выпущено другими разработчиками за все эти годы — какая-то далекая от реальности фантастика, в которую очень трудно поверить.
Хотя, в плане приложений-сервисов тут всё намного проще и удобнее для разработчиков: всегда можно выпустить мини-проект и проверить его, а потом уже доработать остальные фичи. Но это всё равно не должно являться актом спешки. Мини-проект тоже хорошо бы сделать сразу качественным, чтобы не переписывать потом этот код, а просто дальше развить в более сложное приложение.
Я не вижу примеров быстрой разработки «на выброс» среди производителей-лидеров, какую бы область я не посмотрел.
Самые классные и запоминающиеся игры делают всякие близзарды, валве, бетесды и т.д. И каждую свою игру они разрабатывают по много нет и не спешат с выпуском.
Тоже самое с хорошими фильмами. Лучше гладиатора я до сих пор ничего особо не видел, и фильмы практически перестал смотреть, потому что почти все они делаются в наши дни на выброс, а не с целью передать обществу что-то полезное.
Я к тому, что спешка с выпуском продукта оказывается выгодной в короткосрочном плане, но в долгосрочном плане она практически всегда не выгодна вообще никому. Если продукт не особенно хорош, то через какое-то время про него просто забывают. С другой стороны, я до сих пор не могу поставить рядом с хл1 и хл2 какую-либо современную игру по уровню сюжета, продуманности мира… Всё, что было выпущено другими разработчиками за все эти годы — какая-то далекая от реальности фантастика, в которую очень трудно поверить.
Хотя, в плане приложений-сервисов тут всё намного проще и удобнее для разработчиков: всегда можно выпустить мини-проект и проверить его, а потом уже доработать остальные фичи. Но это всё равно не должно являться актом спешки. Мини-проект тоже хорошо бы сделать сразу качественным, чтобы не переписывать потом этот код, а просто дальше развить в более сложное приложение.
Я, конечно, понимаю, что сейчас на меня налетят люди, говорящие «исключение только подчеркивает правило» (фу, не понимал никогда этого), но. Альфа майнкрафта была написана за неделю, если что. Вы этого, возможно, не видите, но постоянно появляются много очень крутых инди игрушек, которые делаются по нормальным Lean методологиям (т.е. фигак-фигак и в продакшен раз в месяц, а дальше смотреть на фидбек игроков).
Представляю себе производителя какого-либо оборудования (например, роутеров), работающего по такому принципу и каждый месяц размещающего на своем сайте новую прошивку, а лучше схему доработки предыдущих версий плат.
Хотя что представлять, ТАКИЕ производители уже есть ))
Или производителя автомобилей.
Просто в данном случае, как никогда, верно высказывание «Истина всегда конкретна».
Хотя что представлять, ТАКИЕ производители уже есть ))
Или производителя автомобилей.
Просто в данном случае, как никогда, верно высказывание «Истина всегда конкретна».
Не стоит путать, кстати, выход на совершенно несуществующий рынок (например, особый жанр игрушки) и выход на сформированный и всем понятный рынок, скажем, роутеров. Если вы хотите сделать супер крутую сетевую железку, аналогов которой пока что нету вообще, то делать ее два года только чтобы проверить она вообще нужна кому-нибудь или нет вы не будете. Вы сделаете ее на соплях побыструхе — корпус в виде коробки от обуви, 5 ардуин там, договоритесь с парочкой датацентров заинтересованных, будете ее пилить вместе с владельцами датацентров, выпуская прошивки раз в месяц и фикся баги.
Ну вы бы ещё добавили сюда, в эту же кучу, производителей самолётов, производителей космических аппаратов, производителей сложного медицинского оборудования, производителей военного оборудования.
Я для себя проекты тоже делаю по методике «херак-херак и в продакшн». Потому что они не отпрвятся в космос. И от вдумчивого кропления над каждой закорючкой лучше не станут.
Я для себя проекты тоже делаю по методике «херак-херак и в продакшн». Потому что они не отпрвятся в космос. И от вдумчивого кропления над каждой закорючкой лучше не станут.
Дело в том, что существует два (как минимум) типа задач, решаемых программами:
* с высокой стоимостью ошибки (медицина, полеты, прочее управление реальными физическими объектами)
* с высокой стоимостью простоя (большая часть современных стартапов и веба)
Соответственно и эффективность этих двух подходов здесь будет разная.
* с высокой стоимостью ошибки (медицина, полеты, прочее управление реальными физическими объектами)
* с высокой стоимостью простоя (большая часть современных стартапов и веба)
Соответственно и эффективность этих двух подходов здесь будет разная.
И опять же мы приходим к тому, что тот или иной подход зависит от поставленной задачи.
Игрушка, сайт-визитка, ОС для телефона — всё это можно делать быстро и допускать ошибки, это даже интересно и занятно не только для разработчиков, но и для пользователей. А вот программному обеспечению медицинского робота или прошивке контроллера системы противопожарной безопасности, написанным по методологиям «фигак-фигак и в продакшен» я бы доверять не стал ни в коем случае.
Игрушка, сайт-визитка, ОС для телефона — всё это можно делать быстро и допускать ошибки, это даже интересно и занятно не только для разработчиков, но и для пользователей. А вот программному обеспечению медицинского робота или прошивке контроллера системы противопожарной безопасности, написанным по методологиям «фигак-фигак и в продакшен» я бы доверять не стал ни в коем случае.
То, что вы описали, я сказал в последнем своём абзаце.
>>>Нельзя просто так выкинуть из работы процесс проектирования.
Да для многих плевое дело — у многих в мозгу на рефлексивном уровне лежит 3-5 каркасных заготовок для создания «скелета» программы, которые накатываются на любой новый проект пусть это будет и со стороны смотреться как котеджик собраный из жб панелей для небоскребов или высотка построенная из тротуарного кирпича. Но то такое — гораздо хуже что такие люди практически всегда очень болезненно относятся к тому что видят решения отличающиеся от их собственных, у них очень часто встречается претензия к коду которая сводится к тому тезису «Я бы написал не так».
Да для многих плевое дело — у многих в мозгу на рефлексивном уровне лежит 3-5 каркасных заготовок для создания «скелета» программы, которые накатываются на любой новый проект пусть это будет и со стороны смотреться как котеджик собраный из жб панелей для небоскребов или высотка построенная из тротуарного кирпича. Но то такое — гораздо хуже что такие люди практически всегда очень болезненно относятся к тому что видят решения отличающиеся от их собственных, у них очень часто встречается претензия к коду которая сводится к тому тезису «Я бы написал не так».
UFO just landed and posted this here
В нынешнее время принято кодить бездумно и считать программу написанной (а себя программистом), как только избавишься от синтаксических ошибок, и пройдут тесты. Уже не модно учить матан и дискретку, когда можно за пять дней научиться на рельсах фигачить интернет-магазин для локального гастронома. У людей совершенно нет понимания, что такое программирование в принципе. Нет ответственности за проделанную работу. Если бабушка скажет «мой внучок — программист», то это принимается на аксиому. А популяризацией юниттестов мы создаем уверенность в том, что если программа примерно справилась с парой входных данных, то она уже готова. А что, если такой подход распространить в другие сферы нашей жизни? Давайте не будем учить правила дорожного движения и внимательно смотреть на знаки — давайте просто будем сто раз проезжать по одной и той же улице, пока однажды не прибудем в конец без кишек на колесах. Мержим это в продакшн, а прослойку между креслом и рулем нарекаем программистом. Кстати, водительские права еще хотя бы аннулировать можно, а вот для того, чтоб заставить написать в своем резюме «этот проект был не просто сделан, а сделан через жопу, и без меня он бы работал быстрей и не глючил» механизма нет. Дада, продолжайте писать много кода, вписывать в резюме много парадигм, технологий, языков программирования — все равно мало кто поймет, программист вы все таки или нет.
А что, интернет-магазин для локального гастронома должен лично Линус Торвальдс писать? Вы сами-то пойдёте фигачить интернет-магазины локальных гастрономов?
В нынешнее время даже не понимают о чем статья… Прочитал несколько первых комментариев, поплевался. И полез вниз писать свой, прочитал Ваш коммент, и обрадовался… Не перевелись люди, которые понимают, что главное не скорось… Смотришь на современные программы и только вздыхаешь с выходом каждой новой версии… Пошло набивание версий, а исправление и оптимизация кода разработчикам неведомо.
Согласен, что можно и быстро написать код, но за счет того, что нем будет куча недочетов и учитывая это придется еще не раз переписать его, порой, с нуля… Все равно получается медленное программирование, если не оставить, наплевав на все, код как есть…
Согласен, что можно и быстро написать код, но за счет того, что нем будет куча недочетов и учитывая это придется еще не раз переписать его, порой, с нуля… Все равно получается медленное программирование, если не оставить, наплевав на все, код как есть…
Часто приходится вычислять интегралы на листочке по работе?
Напомнило пост: habrahabr.ru/post/153225/ и одну притчу о двух программистах (дословно не знаю, не нашел):
Жили два программиста, один написал быстренько программу и выпустил на рынок. А другой долго и упорно писал качественную прогу.
В итоге через год первый получил фидбеки на свою первую прогу — поправил её, заработал кучу бабла, нанял других прогеров и они переписали её без ошибок и всё круто.
А второй выпустил через год свой продукт, но он уже никому не нужен был, потому что все пользовались прогой первого программиста.
Жили два программиста, один написал быстренько программу и выпустил на рынок. А другой долго и упорно писал качественную прогу.
В итоге через год первый получил фидбеки на свою первую прогу — поправил её, заработал кучу бабла, нанял других прогеров и они переписали её без ошибок и всё круто.
А второй выпустил через год свой продукт, но он уже никому не нужен был, потому что все пользовались прогой первого программиста.
В итоге через год первый получил фидбеки на свою первую прогу — поправил её, заработал кучу бабла, нанял других прогеров и они переписали её без ошибок и всё круто.Это в идеале, а на самом деле никто ничего править и доводить до идеала не будет, причина — «просто потеряют время и дадут фору конкуренту, а тот просто обгонит разработчиков».
Просто первый был бизнесмен, а второй — программист.
Потому у них были разные цели (хотя из пересказа это неочевидно).
Первый всего лишь заработал кучу денег, второй — получил огромное удовольствие от работы.
Вам, видимо, важнее деньги :)
Потому у них были разные цели (хотя из пересказа это неочевидно).
Первый всего лишь заработал кучу денег, второй — получил огромное удовольствие от работы.
Вам, видимо, важнее деньги :)
UFO just landed and posted this here
Sign up to leave a comment.
О медленном программировании