Взяли еще одного сотрудника. Растем. Лиды идут бешенным потоком. В понедельник +2 лида. Лето будет очень насыщенным.
#текучка

Благотворительность и контракты.
#текучка #мысль

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

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

В общем мораль, надо не лениться заниматься "благотворительностью".

#текучка #компания
Друг научил, что рабочие совещания надо устраивать в ресторане. Развиваю эту традицию у нас. А то на удаленке все время работать имеет свои недостатки.

Как правильно выбирать товар или продукт.
#мысль

Много раз приходилось делать тот или иной выбор. Какой библиотекой воспользоваться, каким солвером, каким репозиторием и т.п. Сейчас вот подумали каким git репозиторием пользоваться и не надо ли съезжать с gitlab.com. Скажем на https://codeberg.org/ или https://gitflic.ru/

В случае если ценность продуктов на глаз примерно одинаковая или её невозможно заранее оценить, я для себя придумал следующее простое правило:
1. Продумывая фильтры, то есть то что заведомо не подходит.
2. Выбираем самый массовый продукт из тех что не отфильтровались.

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

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

Про Т-образных и других людей.

#мысль

Про форму людей. Есть такое понятие – Т- образный человек. То есть человек, который является глубоким специалистом в одной конкретной области, и обладает более широкими, но менее глубокими познаниями в других областях. Это позволяет эффективно взаимодействовать с другими людьми, воспринимать их точку зрения и т.п. Это действительно правильная и универсальная формула, которая повторяется на многих уровнях вселенной. Например нейрон, который имеет много коротких отростков (дендриты) и один длинный (аксон). Или автомобильный завод, который получает множество деталей совершенно разного типа, а выпускает однотипную продукцию.

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

С порядком не очень понятно, но вот точно плохо быть палочкой, что горизонтальной, то есть знать все по верхам, но ни в чем не быть специалистом, что вертикальной – как еще Козьма Прутков писал «специалист подобен флюсу, полнота его одностороння».

А еще есть очень редкие люди П-образные люди или даже с большим количеством палочек. В Древней Греции был, например, Эратосфен, который занимался всем подряд и везде был вторым. В эпоху возрождения, разумеется, Леонардо да Винчи, и вообще есть понятие «человек эпохи Возрождения» или полимат.

А из современников меня лично очень впечатляет Георгий Леонардович Васильев.

Он учился одновременно на двух факультетах МГУ – географическом и экономическом. А в дальнейшем умудряется совмещать одновременно очень крутого «физика» и «лирика».
Как физик он основатель Российской Фьючерсной биржи и Билайна, как лирик член группы Иваси (я ходил к ним на концерты в 90-ых), автор мьюзикла НордОст, продюсер Фиксиков.

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

#мысль

Расскажу важный секрет, благодаря которому мне кажется у меня получатся 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 солверами иногда бывает.