Comments 148
Год 1965, Генрих Альтшуллер: «Идеальная машина — это машина, функции которой выполняются, а размеры и масса стремятся к нулю.»
Одержать сто побед в ста битвах — это не вершина воинского искусства. Повергнуть врага без сражения — вот вершина.
Сунь Цзы, «Искусство войны», приблизительно 380—325 годы до н. э.
Ждать на берегу реки, что ли?
Стояние на реке Угре, например, почти(а может и не почти) эталонная победа почти(попытки переправы отбивали в малых стычках) без фактического сражения основных сил. Причём победа там прям стратегического значения вышла.
Красивый эпизод, аж зачитался. Однако, вики пишет что тактическим достижением является в т.ч. «удавшаяся попытка Ивана III избежать военного столкновения, в котором не было ни военной, ни политической необходимости — Орда была сильно ослаблена, её дни как государства были сочтены.»
Мало кто, однако, слышал полную версию: пока большие армии стояли на Угре, строили друг другу рожи и показывали
небольшой (сравнительно) русский отряд устроил рейд на Крым и сжёг к чертям дома тех самых хановых стояльцев.
По возвращению их
Не ждать, а использовать иные способы
Недеяние — это не лень и бездействие, это направление событий в нужную сторону минимальным вмешательством, т.е. как можно большее их приближение к естественному ходу событий.
Цель развития любого механизма — мгновенный профит абсолютно без затрат.
Читал "Искусство войны". Оказывается, переводов этой книги довольно много, и каждый немного по-разному формулирует мысли автора. Даже если и правильно переведено, то всё равно для понимания многого приходится смотреть дополнительные комментарии и разъяснения. К слову, в той книге, что я читал, эти разъяснения были примерно того же объёма, как и сам текст книги...
Так о чём это я хотел сказать - а, "Повергнуть врага без сражения" - я читал "Избежать битвы". Но суть конечно остаётся одна, сделать так, чтобы "сражения" не было вовсе, и достичь цели.
Интересно, что такие идеальные "машины" иногда возможны: Бесконечно выгодная программа
Автор немного заработал на программе, у которой размер 0 байт.
спрашивали меня, чтобы узнать, как и зачем я скрываю размер программы (DIR ведь выдавал, что в ней 0 байт). Когда я рассказывал им, что программа действительно занимает 0 байт, некоторые начинали возмущаться: «Как вы смеете брать 5 фунтов ни за что?!» Я отвечал, что они неправы: ведь они же получили полезную вещь взамен.
Да, причём её даже не надо копировать — достаточно узнать как она работает, чтобы сделать самому :D
Если ссылка на манифест против эджайл под рукой - присоедините, пожалуйста.
Что касается полей- согласен — тут прямо заболевание какое-то у людей, потом через год спрашиваешь — ну и какого хера мы эти поля заполняли- где они используются?
Итерации — можно и день и месяц, в зависимости от того, над чем вы работаете. Если груминг, демо, ретроспектива и прочие ритуалы занимают больше времени чем сама работа — что-то у вас идет не так.
Команда должна максимизировать количество законченных историй — если все не успевают, надо что-то отставить в сторону - а освободившегося человека направить на завершение более приоритетных задач. 2 готовых истории гораздо полезнее 4х «почти» законченных. Разумеется, на ретроспективе произошедшее надо анализировать и в следующей итерации делать что-то по-другому. И «оркестрация» всего этого между продукт-, проджект- и прочими менеджерами и командой — прямая обязанность скрам-мастера.
Стендап никогда и не был отчетом. Я тоже не сторонник стендапов в 9 — тупо потому что все будут опаздывать. Но часто складывается ситуация что в 10 не может менеджер, в 11 не может тимлид, а в 12 у 3 человек английский. А синхронизироватся нужно, это же всем понятно. И если получается только в 9-00 то так тому и быть, это работа а не кружок филателистов. Другой вопрос, что если всем удобнее — можно и в 10 вечера эти стендапы несчастные проводить.
Что касается итераций- в среднем реально 2 недели проще и накладные расходы меньше(1 ретроспектива раз в две недели) и не забывается что было сделано(можно вспомнить и рассказать что хорошо сделано, а что было не так). Так же обычно за 2 недели обычной командой в 10+- человек выкатывается количество изменений которое можно безболезненно зарелизить(хотя тут конечно сова на глобусе, но общий смысл такой).
Сколько я не видел попыток изобрести свой размер спринта- все обычно заканчивалось или невероятным количеством накладных расходов(читай митингов) — если спринт слишком короткий, или постоянными внеплановыми релизами- потому что спринт месяц, а фичи нужны быстрее чем через месяц.
Что касается 2 законченных историй которые лучше 4 незаконченных — так это же не скрам мастер или заказчик бил себя в грудь пяткой и кричал что сделает их. Это не про скрам, не про аджайл или не про коммунизм — это про неспособность людей реально оценивать свои силы. И к сожалению отсутствие должного контроля за этим со стороны менеджмента, если хотите наказания виновных- не обязательно расстрелом, но можно особо упоротым не разрешать брать больше одной задачи на спринт.
На ретроспективе прежде всего должен обсуждаться фактор каждой задачи/каждого участника — почему и насколько время ее выполнения не совпало с оценкой. И если условный Вася все вроде бы сделал вовремя, но его вздрючили на код-ревью, а потом интеграция его кода заняла два дня — то его персональный фактор будет 2.0, и задача команды — напомнить Васе на планировании следующего спринта чтобы он свои оценки на этот фактор помножил. И на следующей ретроспективе фактор Васи должен стать ближе к 1.0 — иначе вы что-то делаете совсем не так.
А когда команда научится реально оценивать свою производительность — можно переходить и к оптимизации.
Так зачем вы называете это скрамом?
Что ЭТО?
Отношения между людьми внезапно тоже оказываются важны. И да все работают по какому-то процессу. Моя ремарка была про то что менеджер вполне себе может быть и членом команды если он чтото делает для всех, и скрам мастером может быть если у него задач других нет, а члены команды недостаточно опытны.
до 10% рабочего времени.
1. Каждый день — дейли. 1 час из 8. 12% рабочего времени
2. Ретро раз в неделю. До 2 часов из 8. 5% рабочего времени.
3. Груминг и взятия задач в спринт. До 2 часов из 8. 5% рабочего времени.
Были еще другие встречи, но я на них не ходил. 22% рабочего времени уходило на встречи :)
Теперь вспоминаем, что человек может быть полезен примерно 50% времени, из которых 22% он уже «отбыл» на ритуалах. Остается 28% рабочего времени :)
Итог: смотри п.1 из статьи.
Дейли в 1 час — это жестко
К сожалению, видел и больше… На начальной стадии проекта всё хорошо, приходят PM и разработчики, 5-10 минут и все свободны.
В середине проекта добавляются тестировщики, начинается обсуждение багов прямо на дейли, митинг растягивается на 30-40 минут.
Для починки багов набирают контракторов. Ход проекта начинает контролировать менеджер более высокого уровня.
В итоге на дейли 15 человек, каждый занимает 5-10 минут времени…
То есть баги пишут атжальщики из основной команды а чинить нанимают контрактников? Гротеск.
«Переехать» туда можно было по принципу наличия свободного места. В «пещере» нельзя разговаривать, а находящимся снаружи — звать и отвлекать находящихся внутри. Общение только по IM/e-mail.
Длительность нахождения в пещере вроде как не лимитировалась — во всяком случае меня никто ни о чем не спрашивал.
Кстати, в офисе была и противоположная крайность — несколько хитровыдуманных велосипедов (3-4 колесных), на которых можно было медленно ездить по коридорам. Очень помогало когда упираешься во что-то и начинаешь тупить — пару кругов и как рукой снимает.
Дейли, с точки зрения, рядового разраба — вещи, обычно, бесполезная. Ходишь там, рассказываешь что-то, время тратишь. В реальности же это довольно эффективный инструмент по предотвращению отправления срока задач в космос, причем, по нескольким причинам:
1) человек делает не то, что нужно
2) человек застрял, пытается разобраться сам, но капает не туда и не спрашивает
3) задача оказалась сильно сложнее, поэтому ее вообще можно отложить
Если речь идет не о ведущих разработчиках, а о рядовых копателях, то ситуации 1 и 2 стреляют очень часто. Руководитель зачастую не может (да ему и не нужно) постоянно всех мониторить, потому что и других дел хватает. Так что дейли помогает разрулить такие вопросы. Но час, конечно, много, мы всегда укладывались в 15-30 минут (команды до 10 человек), в деталях проблемы/вопросы решали уже отдельно.
Ретро. Это полезная штука, чтобы все понимали, что было сделано на 1-2-n недель. Без них часто бывает, что коллеги даже не знают, что там напилил их сосед.
Груминг и взятия задач. Опять же, у некоторых людей может быть особое виденье задач, какие-то тайные знания, почему нужно делать так или вообще лучше не делать. Так же, кто-то может захотеть взять именно эту задачу, потому что ему интересно или есть какие-то идеи. 30 минут такой встречи могут сократить дни разработки.
Тратить 100% времени чисто на разработку можно только в компаниях, где ты работаешь один, держишь все в голове, и тебе ни с кем не надо что-то согласовывать. Как только компания становится большой, сразу тратится приличная доля времени на синхронизацию — это абсолютно нормальный процесс.
Ретро вообще не об этом — для понимания что сделано есть демо. Ретро служит для анализа работы команды по двум направлениям — а. что мешало/пошло не так и как это исправить б. насколько оценки разошлись с реальностью (неважно по каким причинам). Одна из целей скрам — научиться точно оценивать сроки выполнения тех или иных задач, причем не до «на моем компьютере работает» — а до релиза в продакшен. Если вы оценили что-то в 3 дня, а заняло оно 5 — то нужно научиться умножать первоначальную оценку на 1.7.
Это получится 12% + 1% + 1%, поскольку недельные надо делить на пять.
На самом деле дейли в нормальных местах это 10-15 минут.
А прикладную математику-то за что?
За оторванность от суровой реальности, очевидно :)
нужно разводить математику и код. математик делает модель. программист ее преобразует в код. для того, чтобы алгоритмизировать математическую модель саму математику знать необязательно.
имхо, каждый должен заниматься своим делом. я работал с прикладными математиками-программистами. основная проблема: отсутствие понимания, как код ляжет на железо. причем к работоспособности кода вопросов не было, вопросы были по эффективности. поэтому для нагруженных систем и систем, критичных к ресурсам математику и кодирование лучше развести.
И один раз среднее значение считали через квадратные корни
Для несведущих — а в чем тут подводный камень?
Что не отменяет того, что нужен программист который умеет писать программы, а не математику. Я собственно занимаюсь именно таким (про математику, не беспилотники), и у меня кровь из глаз идёт когда я вижу код набабаханный математиками (при этом он ещё иногда и работает не правильно).
Очевидно, что туда идут не потому, что математиком хотят стать.
Просто в классификации и госзаказе ПМ — больше.
Возможно дело не в «трудности», а в «желании» осилить.
Математик иинженерпрограммист принимают участие в психологическом эксперименте.
Их посадили в с одной стороны комнаты, с другой стороны в комнату зашла обнажённая женщина и встала напротив них. Испытуемых предупредили, что каждые 10 минут, когда они слышат сигнал — они могут пересечь половину расстояния, оставшегося до женщины.
Они слышат первый сигнал, инженер проходит половину
расстояния, а математик, со скучающим видом остаётся сидеть. Когда и
после второго сигнала математик не шевельнулся, инженер
поинтересовался, почему он не идёт.
— Это от того, что я знаю, что никогда не достигну женщину.
Инженер достал калькулятор, что-то минуту считал, а затем сказал:
— Через 1 час 10 минут плюс-минус 20 минут расстояние будет подходящим для
любого практического применения!
ЖЦ проектов так и быть, вода, можно выучить просто почитав пару статей на тему.
Архитектура информационных систем? Математикам все эти сложные многозвенные клиент-серверные архитектуры обычно не нужны, и обычно не читают.
Архитектура вычислительных систем?
Сети? Топологии, протоколы, уровни модели OSI, реализации стандартных протоколов?
Практики и подходы к программированию? Математики очень часто пишут лапшу из большой процедуры (ака процедурный подход) и плохо умеют в ООП. Могут уметь зато в функциональщину, но не все.
Уровень со звездочкой: собственные компиляторы?
В дополнение: методологии тестирования, юзабилити, методологии разработки ПО, организация производства (экономика предприятия в приложении к разработке ПО), что-то по интеллектуальной собственности. Этого нет у математиков.
Трудно ли это всё осилить — вопрос отдельный. Если есть список тем — осилить возможно, книжек сейчас масса. Если нет — то могут быть нюансы, например, математик может не подозревать, что меню программы из 25 пунктов одним списком, или 10 диаграмм и 50 кнопок в одном окне — не очень хорошо, тогда как программисту когда-то в одной из дисциплин (или даже не в одной) об этом говорили.
Нужно ли это — иногда нужно.
Проектирование баз данных?
В изложении «для математиков» — это тоненькая брошюрка, благо всякую там теорию множеств они знают, а реляционная алгебра особого разжевывания не требует.
Архитектура вычислительных систем?
Тем, кто занимается численными методами, ее знать надо, остальным — по желанию (да и многие программисты, скажем уж честно, ничего в этом не понимают).
Сети? Топологии, протоколы, уровни модели OSI, реализации стандартных протоколов?
Местами — это чистая математика, всякие там случайные процессы и все такое.
Практики и подходы к программированию?
Осваиваются при необходимости, равно как и " методологии тестирования, юзабилити, методологии разработки ПО, организация производства (экономика предприятия в приложении к разработке ПО), что-то по интеллектуальной собственности" из комментария ниже.
Уровень со звездочкой: собственные компиляторы?
Тут математики больше, чем где-то еще (вот хоть недавний пример с оптимизацией, построенной на теории рекуррентных цепей — habr.com/ru/post/550900 ).
В изложении «для математиков» — это тоненькая брошюрка, благо всякую там теорию множеств они знают, а реляционная алгебра особого разжевывания не требует.
там не только про SQL, но еще и нормальные формы, и ключи (PK/FK), и индексы. Много всякого. Так-то да — теорию множеств, все дела. Некоторые даже в школе проходили! Не мешает им потом дичь вместо баз данных делать.
Местами — это чистая математика, всякие там случайные процессы и все такое.
А кроме математики там еще предметная область. Прикладная, так скажем :) Пакеты, заголовки, запросы-ответы, вот это всё. Спроси у математика, как устанавливается соединение, а потом послушай ответ. Какие запросы идут к серверу. Какие вообще бывают варианты :)
> Спроси у математика, как устанавливается соединение, а потом послушай ответ.
Ну я пока до пьяных бесед с зеркалом не дорос, могу завтра у коллег поспрашивать — два математика и три физика (1 физфак, 2 физтех) в наличии. Уверен, расскажут много интересного.
?
Этого не было. Ради интереса, а как выглядит программа по этим предметам.
Архитектура вычислительных систем?
А чем это отличается от предыдущего? Или это в смысле всяких машин Тьюринга? Если последнее, то было.
Одно про сложные информационные системы, как они устроены, как работают взаимосвязи между их частями. Где тонкие клиенты, где толстые клиенты. Сервера приложений, сервера баз данных. Двухзвенные, трехзвенные архитектуры. Другие варианты. Вынос и распредление ответственности между функциональными частями информационной системы.
Второе про компьютеры — как устроены, процессоры, шины, ассемблеры (и программирование на ассемблере) и все такое.
ПМ как уже сказали разная. Например Исследованные Операций очень близка к программированию, а функциональный анализ далек.
Из опыта открытия программистами без математики:
— Упрощение условий if на порядки, знания дискретной математики в этих случаях помогают
— Полно непонимание сложности алгоритма что такое P(n) или O(n) для них Chinese kanji
— Слово предикат (функция возвращающая булево значение) что-то странное из SQL
— Оптимизация алгоритмов, не для них. Написать 10-к вложенных циклов это просто так.
— Перед написанием кода сделать план или продумать архитектуру это только для математиков.
Изучение математики, логики и т.д. приводит мышление в определенные рамки которые помогают писать код более понятным и продуманным.
Также полностью согласен что для задач когда нужна не логика, а просто красивый UI, математика не нужна. Например когда надо верстать формочки, аля Delphi накидать компонент на формочки или рисовать UI в очередном JS framework.
>Из опыта открытия программистами без математики:
— Упрощение условий if на порядки, знания дискретной математики в этих случаях помогают
— Полно непонимание сложности алгоритма что такое P(n) или O(n) для них Chinese kanji
— Слово предикат (функция возвращающая булево значение) что-то странное из SQL
— Оптимизация алгоритмов, не для них. Написать 10-к вложенных циклов это просто так.
— Перед написанием кода сделать план или продумать архитектуру это только для математиков.
Это какие-то неправильные программисты. Обычных программистов именно этому учат на первых курсах. И даже "исследование операций" в программе обучения есть, а "функционального анализа" нет.
Вообще у программистов довольно много математических дисциплин *по сравнению с другими техническими специальностями*. На некоторых других специальностях даже дискретную математику из предмета "математика" не выделяют.
Т.е. код есть, работает, а для сопровождения нужно искать такого же математика.
<:o)
Если есть 2 экрана кода, делающего что-то, и нужно внести изменения с определённой даты, то некий человек делает ветвление по дате и копирует эти 2 экрана второй раз. Математически всё чисто, но теперь у нас 4 экрана кода.
Главное, не забыть потом убрать старый код.
1) Программист пишет программу так, чтобы она работа (правильно — не правильно, не важно, лишь бы работала, даже если изначально им даются неправильное и нерабочее задание)
2) Математик пишет программу так, как надо, и сдает нерабочую программу, если изначально ему дали нерабочее задание.
ЗЫ. Я прикладной математик если что. :D
и так куда не копни. весь мир как пример неправильного опыта жизни…
Хоть и звучит сей комент немного глупо, но здравое зерно в этом есть, у меня у самого была идея, что было бы круто обойтись без горы электроники, например вроде читал что муравьи вентилируют свои подземные муравейники как-то, плюс есть, все время зыбываю как называется, система вентиляции/охлаждения использующая только ветер, на востоке такие строили.
Тащемто, более чем все советские постройки рассчитывали именно на такой тип вентиляции. И на всякий случай еще добавляли во всех инструкциях вплоть до передач в телевидении про здоровый образ жизни — проветривать помещения хотя бы перед сном.
У тайцев что-то похожее в традиционных домах есть. Проблема таких традиционных подходов в том, что крайне сложно найти достоверную информацию, в сети большая часть почти изотерического бреда. Конечно, можно потратить много сил и времени на поиски и проверку информации, но не многие на это готовы, особенно если цель быстро построит дом без заморочек.
С дипломом есть нюанс.
Отдельно от всего синяя или красная картонка с гербом или без, в зависимости от страны и уровня сохраненных знаний есть пшик как и возраст, который иногда отождествляют с опытом.
В году 2005, когда среди вайтишников, те которые уже при галстуке, было стильно, модно, молодежно внедрять всякие аксапты, ораклы, сайбели с парусом и 1С. По отдельности или всё сразу. Удалось мне тогда побывать в АНХ РФ, где товарищи которые ни разу не видели интерфейса данных систем, которые ни разу не управляли промышленным или торговым предприятием, которые ни разу не читали листинг. Рассказывали не краснея как правильно и кошерно покупать сап или аксапту и что 1С это фу-фу-фу, отстой и анахронизм. И даже за это выдавали бумажку которая по тем временам стоила 1500 баксов. И да все люди которые были на тех курсах имели высшее техническое образование и были в должностях руководители ит-департаментов или замы.
Я думаю, тут немного в другом.
"Код, понятный машине, сможет написать каждый - искусство в том, что бы написать код, понятный человеку" (С)
Опыт одного человека или окружения этого человека ни в одной вселенной не может быть релевантным. А делать выводы из этого опыта, больше говорит о человеке, чем его диплом по математической специальности.
Исходя из набора качеств ( отличать верования и факты ), вы видимо не имеете диплом специалиста?
Программирование, Логика и Математика имеют много точек соприкосновения и областей перекрытия.
Я давно прошёл тот возраст когда левым дядям верят больше чем своим глазам.
Программирование — это как и математика/физика/etc творческое занятие. И безусловно, люди, которые сильны в математике, имеют больше навыка работать с абстракциями, чем Вася, который учился на сварщика.
Но на этом факте, мы не можем делать далеко идущие выводы, по которым отсутствие знания матана, является отсеивающим критерием хорошего программиста.
А если я вам скажу что не любое исследование опубликованное в рецензируемом журнале правда? А если я скажу что фейковых исследований очень много?
И даже если исследование настоящее, проведенное на совесть — и связанное со статистикой — то и там все не так просто.
Плюс сюда.
В последние годы очень сильно развилось представление, что программирование – это синтаксис. Программирование, всё же, прежде всего – математика.
матан видел, но как программист так себе
Ооо, естественно, очень часто. Наличие матана в прошлом вообще ни разу само по себе не делает разработчика хорошим. Но среди хороших очень у многих матан таки был. Я считаю это практически необходимым условием, но ни разу не достаточным.
что такое талант программиста — до эры pc традиционно считалось, что это способность легко и отчетливо понимать (и держать в голове) задачу сразу на нескольких уровнях — типа спецификации, система, модуль, код, в настоящее время все это сильно трансформировалось в сторону промышленного программирования, типа на конвейере по системе тейлора, когда необходима максимальное переиспользование кода, грамотное знание всякого рода пакетов, sdk, api и пр. много чего можно еще добавить, но пока так, как обычно строго imho
Кто нибудь пояснит за 7 пункт? Почему мне нельзя работать?
По жизни тоже все равны, но некоторые равнее
из любопытства, хотелось бы знать этих людей с которыми вы пересекались — «математики, физики, либо специалисты в иных очень сложных областях)», со своей стороны могу сказать, что видел достаточно программистов выпускников мфти и mit, но ничего похожего на упомянутую вами закономерность
Есть опасность, что вы начнёте писать на фортране (писать на фортране можно на любом языке программирования) и всем, включая вас, будет от этого больно.
С неё идут деньги в карман. Её берегут. Людей на ней — нет.
— Неужели вы, считаете, что мне когда-то пригодится эта ваша линейная алгебра?
— Вы её так плохо знаете, что определённо нет.
Каждый раз, когда я меняю работу, я сокращаю свои обязанности на 50% и увеличиваю зарплату на 50%Отличный у Вас коэффициент
Придумали коммунизм — закончили массовыми репрессиями.
Придумали новый путь в Индию — закончили геноцидом индейцев.
Придумали аджайл — закончили скрамом.
1 Работа в нашей отрасли полностью построена на порочных стимулах.
2 Лучший способ продвинуться по карьерной лестнице — это смена компании. Компании, в которых вы работаете, будут вознаграждать хорошую работу большей работой и ответственностью, а не большим количеством времени и/или денег. Компании, в которые вы переходите, вознаградят вашу предыдущую хорошую работу в других компаниях большими деньгами. На самом деле это не имеет смысла… См. Пункт №1.
можно кэпа? Каким образом короткая фраза «работа построена на порочных стимулах» объясняет почему переход на +50% не имеет смысла? Все пункты ссылаются на 1, но он звучит как «потому что гладиолус»
Как я понял, смысла не имеет поведение компаний, а не сотрудника.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
1) Потому что деньги — зло.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
в этом нет логики. «пьяный инженер» какраз говорил о том что не имеет смысл давать себя эксплуатировать больше за те же деньги и что проще уйти в другую компанию. На что «трезвый инженер» сказал что эти рассуждения чепуха потому что «Работа в нашей отрасли полностью построена на порочных стимулах.»
При этом страдает как сам человек — от изменений, потери налаженных связей и опыта — так и компания, которая всё равно понесёт лишние расходы (на потерю специалиста, переобучение, новую высокую зарплату).
Не страдает только одно: эго руководства. Эта схема давно известна — «мы не прогибаемся и любые деньги готовы отдать за то, чтобы нас не прогнули». Работник это враг руководителя, просьба поднять зарплату — это акт агрессии, этот акт агрессии должен быть отбит с любыми потерями. Идеальный вариант — полное уничтожение противника, который исчезает с поля боя (из компании).
вопрос к плакату в начале статьи, кто изображен на нем более-менее понятно — трезвый программист за обедом (автор?), но не совсем понятно, что собственно у него на тарелке?
такое впечатление, что художник в жизни нормальной котлеты не видел, или видел, но так давно, что забыл и рисует по памяти, неужели раньше такое в ресторане предлагали?
затем не понятно, кто именно программисту рюмку водки налил, и собственно с какой стати?
рискну предположить, что это представитель фирмы конкурента, просит оставить например багс в программе, и предлагает выпить, а герой картины отказывается, типа «что мне с этого»,
в общем сплошные вопросы, что очевидно отражается и на комментариях к статье — типа «как именно прикладная математика на мозги программиста влияет — строго отрицательно, или же таки бывают исключения» :)
Откровения трезвого инженера