Как преодолевать начальный ступор.

#мысль

Расскажу важный секрет, благодаря которому мне кажется у меня получатся 2x к скорости разработки мат. моделей и других видов исследований.
Есть известная проблема чистого листа. Очень сложно начать новое дело. При исследованиях эта проблема усугубляется, так как по сути задача звучит как "пойди туда, не знаю куда, найди то не знаю что".
Вижу на своих новых сотрудниках (да и на куче других людей) один и тот же механизм ступора.
Человек сидит и пытается загрузить задачу в голову и уже потом начинает ее решать.

Этот путь на самом деле медленный. Гораздо более эффективно двигаться следующим образом. Не надо пытаться понять вообще всю задачу. По сути надо наоборот решать задачу, чтобы её понять. Механизм просто описывается, но очень сложно реализуется.
Надо понять какой-нибудь кусочек работы, который заведомо надо будет сделать. И сделать его.

Например написать рыбу программы состоящей из трех пунктов

* загрузка данных
* волшебство
* сохранение результатов.

Даже такой маленький кусочек решат сразу три проблемы.

* Сдвигание мозга с мертвой точки.
* Уменьшение исходной задачи (слона едят по частям!).
* И самое главное - когда ты что-то делаешь, мозг пропитывается задачей. И даже после такого, вроде бы бессмысленного, действия задача становится проще.

А вот попытка переварить задачу на мой взгляд является таким хитрым вариантом прокрастинации.
Наверное этот подход подойдет не всем, но все-таки существенно большему числу людей, чем кажется первоначально.
Я сегодня в боевом режиме учил сотрудника этой методике, нам тут прилетела очень срочная задача, которую надо 29 мая сдать, времени понимать её нету. Вроде успешно получилось.

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

Я постараюсь написать серию постов про этот подход с разных сторон. А пока процитирую один стишок, который был написан на базе реального разговора.

Любовью к наукам совсем не грешу,
Но в школе учение - праздник,
«Не понял задачу, совсем, но решу»,
Папе сказал пятиклассник.

На мальчика папа смотрел сверху вниз,
Держась, чтоб не прослезиться:
«Ты не представляешь, как этот девиз,
В жизни тебе пригодится!»

Что такое двойственная задача линейного программирования.
#математика #lp #мысль

Цитирую классную мысль моего приятеля Арсения Акопяна.
Придумал как объяснять житейским языком двойственную задачу линейного программирования (скорее оптимизации).

Прямая задача: Пусть вы понимаете, какой хотите сделать ремонт. Тогда цель, потратить как можно меньше денег на реализацию вашего плана.

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

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

Понимать не важно, ты считай, потом привыкнешь.
#математика #психология #мысль

Напишу еще про ступор и его преодоление.

Я учился в очень веселой школе СУНЦ МГУ, так же известной как ФМШ-18.

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

В общем мозг нам это тогда выносило сильно. А техника считай пока не привыкнешь пошла от квантовой физики. Там это оказалось единственно работающей техникой так как реальность в мозги не укладывается. Мало того что то, что известно взрывает мозг, так слишком мало известно, чтобы на этом сформировать какую-то полноценную интерпретацию.

Сейчас я этому принципу учу в боевом режиме сотрудников. Выполнили один срочный заказ для IBS.
Очень сложно людям все-таки работать в режиме, когда они не понимают до конца задачу.

Я отмечу пункты, которые надо нарабатывать

• Не бояться, что ты до конца чего-то не понимаешь (про это можно отдельный пост написать вообще, так как наше сознание, по-видимому, это орган для закрытия лакун, и нам эти лакуны оставлять невыносимо).
• Контролировать что ты понимаешь, а что нет.
• Находить кусок работы, для которого ты точно понимаешь, что надо делать.
• Контролировать, что твои решения не портят общий результат и не роняют «стеклянный потолок» качества решения.То есть надо опять же не понимая весь проект целиком, понимать достаточно чтобы быть точно уверенным. Типа не пытаться строить дирижабли из свинца.

#новости Моя заказчица написала статью для VC. Она реально очень клевая!
https://vc.ru/hr/1215299-kogda-govorila-pro-agile-v-inzhiniringe-kollegi-krutili-u-viska-teper-na-nashu-sistemu-smotryat-s-zavistyu

Главный секрет быстрого программирования.
#отладка

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

Задам еще одну школьную задачку.
Была тонна огурцов. Огурцы состояли на 99% из воды.
Потом они подсохли и стали состоять на 98% из воды. Сколько стали весить огурцы?

Ответ. Сухого вещества сначала был 1% и это 10 килограмм, потом это стало 2%, то есть общий вес огурцов 10/0.02 = 500 кг.

Во-первых, хочу отметить, что задача решается инвариантами. Отключаем инерцию мышления, которая подсказывает неверное решение, находим то, что не меняется и разматываем задачу

Ну а главное, про что я хочу написать, что разработка состоит из отладки процентов на 90%.

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

Далее отладка разных видов. Синтаксические ошибки, некорректные входные данные некорректная модель.
Я за день обычно делаю одну фичу, которая занимает 20-100 строк. То есть пишется максимум полчаса. Продумывается иногда дольше, но в целом все вместе укладывается в час обычно. То есть 87.5% работы – это отладка.
И так же, как с огурцами, разработчикам совершенно неочевидно по началу, что оптимизировать надо не разработку, а отладку.

И мои личные правила следующие:

• Локализация ошибки (упоминал в этом посту).
• Важный кусок локализации ошибки, это контроль границы между работающей области и не работающей. То есть надо иметь пару состояний программы. В одной точно все ок, а во второй или неизвестно (когда только что-то написали) или бага.
• Так же стоит в каждый момент времени отслеживать статус основной задачи где мы там находимся а так же статус всей цепочки подзадач до текущей задачи. То есть надо точно знать, что ты делаешь и как это помогает основному проекту. Это требует мозговых усилий но помогает не потерять ориентиры когда отлаживаешься. Это конечно про SMART идеологию, но в контексте отладки.
• Всегда делать ровно одну фичу (иначе запутаешься, что работает, а что нет). Лучше делать фичи медленней и их последовательно проверять.
• Не стесняться писать добавочный код, если он помогает отладке. Например тесты, визуализации и т.п.
• Классические советы хорошего стиля программирования. Комментировать текст программы. Писать лаконично, но так чтобы понял “условный дурак”. Зачем это все надо становится ясно с точки зрения того, как в будущем будут появляться баги.
• Писать соглашения о входных данных, какие свойства данных мы ожидаем, даже если они очевидны. Типа многогранник выпуклый и содержит начало координат. Сейчас это очевидно, а через год будет уже нет. Лучше эти соглашения переводить в ассерты или другой вид кода.

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

По крайней мере в нашей области программирования, которая, по сути, исследовательская (R&D), а не разработка (Software Development).

#текучка #размышления
Когда я работал в институте, я не любил заполнять бумажки, и даже паспортные данные заполнял плохо. Бухгалтерия ругалась :) Думал, сделаю свой бизнес и не буду париться со сдачей чеков на авиабилеты и прочей мутью. А теперь оказалось, что бумажек намного больше. И я наизусть помню не только паспортные данные, но даже ИНН.

#программирование #отладка
Вот с такими данными приходится иногда работать. В целом ошибка тривиальная, но с непривычки народ пугается.

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

Я как-то долго долго не мог понять почему не работает на корректном входном файле. Локализовывал ошибку и дошел до того что было два пустых входящих файла и на одном программа работала, а на другом падала. Размер файлов был разный, один оказался юниксовый без возврата каретки,а другой виндовый с возвратом.

#мысль #мышление
В работе вылезло. Люди стесняются задавать "глупые вопросы" 😩. А это само по себе очень плохо, а для работы на удаленке вдвойне.

Задавание вопросов это собственно главный способ развиваться, и вообще основа интеллекта. Но при этом и правда нельзя "сойти за умного".

Шимпанзе, например, говорить по человечески могут научиться (язык жестов). А вот вопросы не задают.

Выложил картинку из книги "Гибкое сознание" Кэрол Дуэк. Помимо задавания вопросов отмечено еще несколько важных моментов.

Книжку рекомендую почитать, но она классическая американская. То есть пишем одну идею, даем про нее 3 интересных примера и потом 100 страниц с разных сторон обсасываем. Но не вредная, на четверочку.

Я кстати жутко болтлив, и в результате я никогда не стеснялся задавать вопросы. Кажется это и есть связь гена болтливости FOXP2 с интеллектом.

После дождичка в четверг добрался до конференции по текстильной промышленности.

Почему не страшно выглядеть и даже быть глупым.

Марку Твену приписывают цитату: "Всего 10% людей думают, еще 10% думают, что они думают, остальные 80% готовы умереть, чем начать думать."

В более простой формулировке – 80% людей дураки.

При этом насколько я могу судить, с такой формулировкой много кто согласен. Что смешно, больше 20% людей.

На мой взгляд более честная формулировка следующая: 80% времени каждый человек – дурак.
Чтобы думать надо прикладывать усилия, и постоянно это делать замучаешься. Нужно иногда голову и выключать. И еще у каждого человека свои способности. Кто-то хорошо готовит, кто-то решает задачки, кто-то очень вежливый и заботливый, кто-то ничего не забывает, а кто-то хорошо соображает по жизни и так далее. И каждому кажется, что это знание тривиально и остальные тупят.

При этом ум похож на фонарик из глаз. Мы видим ровно то, что видим. А понимаем мир ровно там, где понимаем. А непонятные для нас вещи мы не замечаем обычно или не придаем им значения. В результате со стороны чужие глупости хорошо видны, а свои нет.

Тот кто активно занимается наукой знает, как быстро он упирается в соображалку своей головы, и насколько он слабее скажем реально крутого ученого типа Арнольда, Джона фон Неймана, или Теренса Тао. И даже их можно завалить простыми задачками, которые они не в силах будут решить. На любой решенный вопрос сразу появляется два нерешенных. Область знаний, которую мы понимаем, занимает ровно 0% от всей области знаний.

Так что следующая цитата Эйнштейна насчет глупости верна буквально.

“Есть только две бесконечные вещи: Вселенная и глупость. Хотя насчет Вселенной я не вполне уверен.”

Ну и главное, что в этом нет ничего плохого.

Классическое комбо мелких компаний:
#текучка

1. Доделываем срочный проект, который оказался сильно сложнее ожидаемого.
2. Прилетает срочный и важный заказ. Начинаем делать.
3. Разработчик сидя в какой-то деревне во Вьетнаме роняет и разбивает свой макбук.

Разбираемся как можем.

MIP vs LLM. Или когда искусственный интеллект победит солверы.
#ии #оптимизация #размышления

Я занимаюсь в основном дискретным линейным программированием (так же известное как ЦЛП, MIP).

Это крутая штука, но на самом деле старая. Сто лет в обед, точнее 85. К примеру, это программирование назвали в честь линейного программирования, а не наоборот. Теперь лучше уже говорить линейная оптимизация, чтобы было меньше путаницы.

А есть новые модные штуки типа искусственного интеллекта. И для меня жизненно важно разобраться, не будет ли у нас смена парадигмы. В этом случаи мой очень большой опыт в значительной своей части пойдет на свалку.
Помимо страха есть и плюсы в переходе на ML. ЦЛП не параллелизуется. И это уже очень странно, когда мы можем запускать задачу при желании хоть на миллионе процессоров.

Было много заходов решать дискретные задачи при помощи методов машинного обучения. И в прямую за уже 15-20 лет ничего не сработало.
Видимо это связано с принципиальной разницей между непрерывными и дискретными задачами.

Получается успешно внедрять ML внутрь MIP солверов. Там внутри есть куча эвристик, которые хорошо можно ускорять машинными методами.

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

Я для себя определил канарейку - тестовую задачу. Когда ее научатся решать методами ML тогда надо будет спокойно смотреть и переключаться на использование методов в моих задачах.
Это просто классические задачи дискретной оптимизации: задача коммивояжера и задача о ранце.
Появляются статьи, которые решают их методами ML. Но если покопаться, то оказывается, что они там сильно гетерогенные и главное, что особого прорыва нет.

Например, есть такой интересный метод. Берем большую задачу коммивояжера и режем на кусочки, и нарешиваем её на этих кусочках классическими методами (есть программа Concorde). А потом методами ML склеиваем кусочки между собой. Получаем результаты достаточно быстро и качественно.

Но пока это все ерунда все таки.

И мой вывод следующий:

Пока не будет в коммивояжере настоящего прорыва, ML методы для MIP задач можно вообще не рассматривать.
А вот как канарейка сдохнет, значит есть несколько лет разобраться и переключиться на новые методы.

#текучка
Нашли баг солвера, точнее связки двух солверов scip+ipopt. Задача не решается, а если зафиксировать переменную то сразу решается. Чего быть не может. Много крови на эту проблему потратили. Очень редкая история, хотя с open source солверами иногда бывает.

#текучка
Задача от знакомого прилетела. Распознавание аудио. Узнавать надо знакомые сигнатуры типа трактора или мотоцикла. Есть специалисты с кем можно задачку обсудить ?

#текучка #рецензия
У меня сегодня день рождения, 46 лет. Это неожиданно круглая дата. Я был совершенно отмороженным вундеркиндом в детстве. В 4 года научился читать причем сам, и дальше поглощал математические книжки. В 6 лет ходил в библиотеку, где перечитал сначала всего Волшебника изумрудного города, а потом добрался до математических книжек среди которых запала в душу "Секрет великих полководцев" Абчука. Несмотря на на военное название, эта книга про теорию принятия решений и теорию исследования операций, а это "военное" название дискретной оптимизации.

Так что мой стаж по дискретной оптимизации аж 40 лет! 😂

Мне там правда больше в душу запала теория игр, но она пока не применилась.

#текучка #выступление
Приехал на конференцию МОТОР-24 по математической оптимизации и исследованию операций.
Люди все хорошие, а доклады как обычно на таких конференциях скучноватые.

Вспоминаются 3 вопроса, которые Ричард Хэмминг задавал своим коллегам. Он раз в недельку приходил и задавал по очереди три следующих вопроса. Народ обижался, а через некоторое время благодарил.

1. Чем вы занимаетесь?

2. Какая самая важная проблема в вашей области?

3. Почему это не одно и тоже?

А нет ни у кого знакомых студентов, которые хотят летом подработать? Задач перебор, людей не хватает. Нужно знать питон и математику. Желательно иметь опыт решения задач дискретной оптимизации на python/pyomo. Тогда можно больше задач сходу дать.

#текучка
Да, я уже бизнесмен, а не математик.

Сделал короткое выступление на МОТОР. Ни одного комментария.😳 Потом подошёл один из организаторов и стал мне доказывать, что алгоритм должен быть точным, а если с гепом, то это ерунда. Кое-как отбился, рассказав про свою теорему про 13 шаров. Но в целом дело было не в этом, просто его и других людей кажется триггернул мой подход. Немного жаль, ну да ладно. У каждого свой путь.