#мысль

Сформировалось определение джун/миддил/сеньор для своей компании.

Джун потребляет внимание.
Сеньор производит или экономит внимания больше чем потребялет.
Миддл производит внимания примерно столько же сколько потребляет.

Внимание это сейчас самый дефицитный ресурс в компании и получается, что все от него пляшет.

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

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

Миддл соответственно человек, который либо делает без присмотра простые задачи. Либо делает с присмотром сложные, и сам может присматривать за джунами.

Тоже получилось такое функциональное, а не схоластическое определение.
Оно не универсальное, но для меня то, что нужно.

UPD. Главное не изображать сеньора и не работать молча, если ты не на 200% уверен в том, что делаешь. А то потом приходится доделывать и чинить в сжатые сроки, и это потребляет еще больше внимания, чем просто вовремя спросить.

UPD2. Внимание это время руководителя на задачу.

#ии #прогноз

Давно собирался продолжить писать прогноз изменений на следующие 10-20 лет в мире из-за ИИ.

Получается простыня. Потому просто накидаю тезисы. Может позже раскрою отдельно некоторые.

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

2. Не будет резких скачков безработицы. ИИ будет давать сильную отрицательную обратную связь. Повышение безработицы будет уменьшать уровень зарплат, а это будет убивать рентабельность ИИ проектов. Отдельные профессии могут выпадать, но массовая безработица вряд ли произойдет. Процессы пойдут в странах с высокой зарплатой. В России будет время осмотреться. Зарплаты могут заметно изменяться.

3. Вырастет роль уникальных знаний и инфобеза.

4. У России много ресурсов, мы будем скорее в плюсе. Будем следующие 10-20 лет заниматься импортозамещением, автоматизацией производства, кластеры темных заводов.
5. При повышении безработицы увеличится уровень войн и беспорядков. Просто потому, что это тоже занятость человека. Усилятся армии США, Европы. Усилится позиция России как производителя оружия. Турбулентность будет серьезная.

6. Возможно, повысится рождаемость, просто как условная сфера занятости.

7. Могут быть прорывы в лекарствах и биологии в добыче минералов. Но их общий эффект на мой взгляд будет небольшим, относительно слабее НТР 20 века. Потому что низко висящие плоды уже были собраны. Но какие-то прикольные штуки будут. Рожденные в СССР все-таки почувствуют, что они в будущем. Хоть и без летающих автомобилей, но может с летающими булками хлеба.

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

9. Софт будет дешеветь, но рынок вырастет благодаря парадоксу Джевонса.

10. Скорость прогресса определяется скоростью адаптации людей, а не развитием ИИ. ИИ уже забегает вперед. Есть естественные механизмы замедления прогресса. Каждая крупная организация заинтересована в монополизации и сохранении статус кво. Дорогое тестирование лекарств и их лицензирование про это. Мир очень вязкий, потому упорство важнее мозгов. Это относится и к людям, и к ИИ. Правда этот механизм отключается в период войн, а мы как раз в эпохе смены гегемона…

Продолжаем открытые семинары
Следующий доклад будет завтра 21.11.2025 в 16.00 по Москве.

Ссылка на подключение
https://telemost.360.yandex.ru/j/60806382544603

🎓 Метод Branch and Cut: в теории и на практике

Метод ветвей и границ не является панацеей при решении задач дискретной оптимизации.
Современным солверам приходится пользоваться миксом из различными подходов, чтобы быть эффективными.
В ходе доклада мы разберём метод Cutting Plane, который часто применяют вместе с методом ветвей и границ. Эту связку и называют Branch and Cut.

🔹 Мы напомним всю необходимую информацию из предыдущих докладов про LP и Branch and Bound
🔹 Разберем основу метода Cutting Plane, а именно добавление новых ограничений, которые упрощают решение задачи
🔹 Рассмотрим различные способы как генерировать эти ограничения (каты), а также управлять ими
🔹 Приоткроем завесу черного ящика, а именно воспользуемся API солвера SCIP, чтобы собственными глазами посмотреть на добавляемые каты

Через полчаса начинаем https://telemost.360.yandex.ru/j/60806382544603

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

#мысль
Декларативное против императивного.

Поймал тут одну важную мысль.
Языки описания мат моделей для ЦЛП по сути своей декларативные. Это очень крутая, но контринтуитивная штука.
С одной стороны тебе надо просто задать "что" ты хочешь получить, а не "как". И это очень здорово так как алгоритм на базе ЛП более гибкий, Если ты сделал алгоритм/эвристику с конкретным "как" делать, то как только у заказчика изменится обстановка, алгоритм придется переделывать. Скажем высокий сезон прошел и пошел низкий. Конкретный алгоритм так же плохо обобщается. А в ЛП с этим всем красота и благодать.

Но при этом люди не отделяют "что" от "как". Постоянно в ТЗ заказчики занимаются прямым руко-водстмом. Объясняют как делать ту или иную штуку.
Заказчики ладно, им можно. А вот исполнитель хороший, который работает с солверами, должен уметь разделять.

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

Более менее измеримых вещей которые можно сделать я тут вижу две:

1. Думать и осознавать что написание целевой функции для солвера это важная часть работы, чуть ли не главная. Все остальное это просто формальная корректность или оптимизация скорости.
2. Чтобы понять правильно ли сформулирована ЦФ, надо подумать какое солвер может найти максимально бесполезное решение с заданной ЦФ.


Еще небольшое упражнение на различения декларативного и императивного стиля работы.
Какая из этих фраз в каком стиле сформулирована:

1. Копай отсюда и до обеда.
2. Я хочу чтобы все унитазы к вечеру блестели.

Приехал в Екатеринбург общаться с коллегами/партнерами. Очень полезно общаться в живую. Уже доволен результатами. Осталось только получить клиента с живыми деньгами

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

1. На этапе прототипа надо рассматривать самое сложное а не простое. Я это называю принципом Ильи Муромца, позже напишу пост.
2. Язык описания данных не должен просачиваться в модель. Между ними надо делать переходник и дальше делать с моделью, что тебе удобно. В одном проекте не стал так делать, и до сих пор огребаю.
3. Если по какой-то установке не надо принимать решения, то она выкидывается из модели. Например труба. Даже если решение есть, например что качать некоторым насосом, то чуть чуть загрубив задачу мы от этого можем избавиться, то это надо смело выкидывать из модели.
4. Заказчику надо делать визуализацию в его формате, а уже потом переходить на правильный. Они уже привыкли и сходу в своем формате все видят. И он может оказаться в чем то и правильней.
5. Абсолютно правильные рассуждения против комбинаторного взрыва. Надо понимать какие решения ключевые и выбирать сначала их варианты а потом все выстраивать вокруг.
6. Тесты

Насчет ЦЛП против перебора. Главное, что победителей не судят. Я видел аналогичные проекты, которые делались подобным подходом и проваливались.
Здесь перебора хватило и прекрасно. CP кажется здесь лучше должен подходить прямого перебора и ЦЛП.

Кажется, что докладчик местами переизобрел велосипед и мог бы воспользоваться готовыми библиотеками, чтобы скажем организовать перебор. Но это просто экономия 10-20% времени проекта, а не рисков. И главное, что проект сделан. И здесь вопрос просто в том, к чему человек привык.

Я бы его все равно бы стал делать при помощи ЦЛП, скорее всего мне было бы легче с перебором, но было бы сложнее с интервалами времени.
Но сложность задачи на глаз такая, что я тоже скорее всего сделал бы. Прямо сейчас сдаем ЦЛП алгоритм для завода с большим числом SKU с более разнообразными заморочками. Правда у нас со временем попроще.

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

Запись семинара

Виталий Черненко (Амальгама), Практическое применение комбинаторной оптимизации на примере задачи планирования молочного завода. YouTube | Дзен | RuTube (~1 час 25 минут).

Пробуем провести доклад, который сорвался на прошлой неделе.
Доклад будет сегодня 28.11.2025 в 16.00 по Москве.

Ссылка на подключение
https://telemost.360.yandex.ru/j/3763851219

Будет комната ожидания для защиты от спама. Пишите пожалуйста полные имена при подключении и отметьтесь в комментариях.


🎓 Метод Branch and Cut: в теории и на практике

Метод ветвей и границ не является панацеей при решении задач дискретной оптимизации.
Современным солверам приходится пользоваться миксом из различными подходов, чтобы быть эффективными.
В ходе доклада мы разберём метод Cutting Plane, который часто применяют вместе с методом ветвей и границ. Эту связку и называют Branch and Cut.

🔹 Мы напомним всю необходимую информацию из предыдущих докладов про LP и Branch and Bound
🔹 Разберем основу метода Cutting Plane, а именно добавление новых ограничений, которые упрощают решение задачи
🔹 Рассмотрим различные способы как генерировать эти ограничения (каты), а также управлять ими
🔹 Приоткроем завесу черного ящика, а именно воспользуемся API солвера SCIP, чтобы собственными глазами посмотреть на добавляемые каты

Начинаем через 4 минуты. https://telemost.360.yandex.ru/j/3763851219

#текучка
Искал телеграм-каналы порекламироваться. Один канал отказался рекламу давать, в результате познакомился с интегратором, у них есть в целом свой отдел математиков оптимизаторов, но знакомство все равно не помешает.
Забавный вариант достучаться :) лучше чем через linkedin.

Еще нанял пиарщиков, чтобы системно заниматься продвижением. Посмотрим, что получится.

Проводил касдев с потенциальным заказчиком по одному потенциальном продукту и возникла дилемма. Делать пилот бесплатно или за деньги.
И то и другое имеет минусы.

С одной стороны люди плохо фильтруют настоящие и не настоящие проблемы. Настоящие это только те, за которые люди готовы платить денег.
Это даже в моей истории было, мы обсуждаем очень важную фичу. После вопроса - сколько вы за нее готовы заплатить, заказчик сливался. Даже 10к в месяц был не готов ))

Так что очень важно брать денег за фичу. По этой же причине котят продают хотя бы за 1 рубль, а не дарят.

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

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

#мысль

Принцип Ильи Муромца.

Илья Муромец, когда стоял у камня выбрал дорогу ведущую к смерти. Опасный путь, зато решает проблему.

Сложные проекты начинаются с прототипа. Прототип должен быть упрощенной версией основной задачи, и написание прототипа должно отвечать на вопрос:
Можно ли сделать этим методом задачу или нет?

Как правильно выбрать какие фичи писать в прототипе, а какие нет? А вот про принципу Ильи Муромца.
Надо выбирать самые сложные фичи, а простые и рутинные игнорировать.

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

Вообще смысл прототипа - если проект провалится, то лучше именно на этапе прототипа.

P.S. У японцев есть подходящий и более звучный термин бусидо. Но хочется стащить идею у японцев, как в свое время стащили идею матрешки.

Никто еще не начал делать русский роблокс ?

#семинар
Сделали запись доклада про Branch&Cut от 28 ноября.
Рутюб/Ютюб