70 тысяч айтишников (на 90% это именно программисты конечно) из России за последний месяц уехало, и в апреле ещё 100 тысяч собираются следом. Из занимающихся у меня -- где-то около 20% перебазировалось.

"Вторую волну" пока сдерживают только дорогие билеты, рост цен на жилье, а также то, что "русских никто не ждет" и "нет финансовой связности, невозможно транзакции проводить" (с) РАЭК

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

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

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

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

Ну и безусловно войти в российское ИТ уже в этом году станет значительно легче и проще, планка существенно понизится.

Кто из регионов, и пока думает "уезжать ли", рекомендую кстати тренировочную версию вашей задумки: переедьте сначала в msk/spb, тут классно и работы дофига :)

=

Знакомые рассказывают, как мучаются с "продлением" лицензий на самый разный софт (в АСУ ТП вообще швах...), который уже не купить/не продлить. Резко вырос спрос на взломщиков-крякеров, но это ведь временные решения, софт быстро устаревает, нужны свежие версии... Да и многие западные компании закономерно переходят на облачные версии с тонкими клиентами, как минимум какие-то кусочки логики делегируют серверу, ломать это бессмысленно.

=

Теперь нередко неайтишники стали спрашивать, а можно самим вот такое написать? а сколько это будет стоить?

Можно безусловно 100% реализовать любую ИТ-систему своими силами.

Но, сегодня это уже будет очень дорого и очень долго.

Единственная стратегическая мера что осталось -- развивать продуктивное обучение этому всему.

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

"...создание и доказательство безопасности формальных математических моделей средств защиты информации является обязательным шагом для прохождения сертификации продуктов от 4 уровня доверия и выше.
Что это значит простым языком? Теперь, чтобы пройти сертификацию во ФСТЭК разработчикам ПО в области информационной безопасности необходимо моделировать работу своих продуктов с помощью математических или программных решений."

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

"Я делал модель безопасности на Event-B для сертификации ФСТЭК. Делал на совесть и это было очень интересно, но это не помогло найти ошибок и описание не получилось строже и понятнее документации."

Жутко доволен таким трендом. Это сделало мой 2022-й :)
Нюанс ещё в том, что подобные услуги по понятным причинам, связанным с уровнем экспертности подрядчика, подразумевают если не миллионы долларов, то оплату на вполне западном уровне точно :)

P.S. Буду также срочно освежать мой курс по F*

Как правильно изучать теорию типов так, чтобы достаточно быстро получить практический профит?
TAPL или схожие книги не очень рекомендую для прикладных целей. Если вы миддл (раньше не надо) лучше всего начните с т.н. typestate-oriented programming -- когда мы думаем объектно-ориентированно, но не просто в терминах классов, а ещё и в терминах состояний. Каждому состоянию соответствует некоторая явная/наблюдаемая репрезентация в проекте (только не слишком увлекайтесь классическими state machines, основная абстракция тут именно first-class typestates), а методы переводят объект из текущего состояния в одно из новых допустимых.
Что поизучать:
https://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf
https://dl.acm.org/doi/10.1145/2629609

Подробнее разбираю эту тему на курсах по stateful и объектной вычислительным моделям.

Как сеньорам выживать в ИТ стратегически в современных условиях?

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

Поэтому для сеньоров схема "прийти на новую работу и вписаться в действующий коллектив" слегка теряет актуальность, а вот скилл "запилить фуллстек-проэкт любой сложности за разумную сумму" хм думаю взлетит космически.
Например сегодняшняя заметка на хабре "Как я оклад 2х хотел", где парня, претендующего на сеньора, постоянно возят по каким-то зашкварным техническим тестам, которые максимум для миддла. А вопросы вроде вычислительной сложности сортировки/поиска, это что? :) это же вообще джуниорство.

"По ощущением, ответил на процентов 70-80%. Пришел отказ."
Да, ну во-первых, конечно если претендуешь на сеньора, то и готовым надо быть реально на +30% к требуемым скиллам, это надо продемонстрировать, а не что-то миддловское.
Хотя в целом, не очень рекомендую связываться с такими мамкиными сеньорскими позициями, где от человека просто хочут хороших технических знаний и навыков.

Потому что, во-вторых, сеньор должен мыслить и вести переговоры не в терминах веб-фреймворков и сильных абстракций (это само собой), но прежде всего на системном уровне -- в "бизнес-терминах", что заказчик хочет получить "под ключ", а технические темы его (заказчика) не должны заботить.

Вы просто берёте ТЗ изучаете говорите срок и бюджет подписываете договор -- ну и, пацан сказал пацан сделал :)

Да, это уже больше похоже на фриланс подряд ит-бизнес, как раньше были шабашники ))) Но это и будет нормальное взрослое развитие карьеры.

Тут самый большой риск -- завязываться на других спецов. Моя схема -- делать всё ключевое самому как сеньору/тимлиду, а всю рутину отдавать джуниорам, которые прозрачно отбираются по простому чек-листу (аккуратный код + навыки достаточно быстрого решения средних задачек на литкоде; знание фреймворков вообще не актуально, кто норм решает задачки, изучит основы любого стека за пару недель), и которых, самое главное, можно быстро и безболезненно заменять в проекте на других, буквально за сутки. Такая схема достаточно хорошо масштабируется на большинство проектов среднего размера. Ну может ещё 1 уровень абстракции добавить, когда объёмная работа -- пару миддлов :) , но в целом во всех проектах лучше всего полагаться прежде всего на собственный ум.

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

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

Как подготовиться? Если вы уже давным-давно не напрягали свой ум абстрактными задачами, то начните с задачника по арифметике для первого класса, решайте всё подряд без исключения (не смейтесь, сегодня даже на уровне 1 класса многим бывает нелегко :), потом последовательно переходите ко второму классу, и т. д. Как (если) пройдёте успешно все задачи по алгебре 7-8 класс, тогда значит потенциально готовы к изучению программирования.

Как вариант, можно поиграть в разные игры "для программистов", где придётся много думать.
https://habr.com/ru/company/timeweb/blog/645593/
https://habr.com/ru/company/timeweb/blog/599835/
https://habr.com/ru/company/vdsina/blog/565032/
Пошаговые стратегии вроде HoMM на чемпионском уровне тоже неплохо.

"Проблема в том, что большинство профессий завтрашнего дня в той или иной степени связано с IT-технологиями. А они требуют фундаментального образования и системного мышления. Тут переучиться не то что сложно, а практически невозможно. Если вы до 8-го класса прогуливали математику, то компенсировать отставание будет невозможно. А уж дальнобойщику найти себя в программировании, к сожалению, нереально."
(с) Юваль Ной Харари, профессор исторического факультета Еврейского университета в Иерусалиме

У него кстати интересные, пророческие :) книги выходят,
"Homo Deus: Краткая история будущего", "21 урок для 21 века" и др.

P.S. Ну и нехудожественные книги конечно тоже важно регулярно читать.

Interfaces are abstractions
— Olaf Thielke, "Code Coach"

Interfaces are not abstractions
— Mark Seeman, "Code that Fits in Your Head", "Dependency Injection"

In software, abstraction is the process of simplifying code by finding similarities between different parts of the code and extracting shared logic into a named component
— Eric Elliott, "Composing Software and Programming JavaScript Applications"

Abstraction is a process which is used to produce generalized concepts or models, but in software we often refer to individual parts of a model as abstractions as well
— Steve Smith, "Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure"

И это сегодня пишут, на минуточку, авторитетные специалисты в computer science, авторы учебников и серьёзных научных работ, известные во всём мире преподаватели. Чьих рекомендаций придерживаться? :)

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

К счастью, если обратиться к оригинальным монографиям святых computer science 40-50-летней давности, то можно найти хорошее формальное определение абстракции от одного из величайших учёных в информатике, которое прекрасно связывает теорию с требованиями современной программной инженерии. Скоро разберу это для донов, с соответствующими прикладными выводами (как правильно думать "абстрактно", что это вообще означает), в отдельном материале в СильныхИдеях.

Когда человек заявляет: "я применил этот system design в 32 проектах, и все они оказались успешными", это явный антипаттерн.

Во-первых, отбор астронавтов в команду корабля "Аполлон-11", совершившего посадку на Луну, выполнялся отнюдь не по схеме "берём тех, у кого много классных историй успеха". Наоборот, брали тех, у кого в карьере были эпик-фейлы, но они сумели их преодолеть. Брали Выживших :)

По сути, NASA искало астронавтов с экстремальной психологической устойчивостью, потому что миссия "Аполлон-11", как предполагалось, будет чрезвычайно сложной.
В сложных современных ИТ-проектах психологическая прочность часто тоже становится ключевым фактором успеха, а отнюдь не хард-скиллы. И даже не софт-скиллы :)

Я с февраля ввёл более строгие требования к занимающимся, сейчас отчисляю где-то 50% слабаков, а с апреля, как буду понемногу делать новые наборы, планирую довести этот процент до 80%. Потому что многим прозаически не хватает характера. Отмечу кстати, что вот девушки кто у меня занимается, ну почти 100% усердные упорные трудолюбивые и добиваются хороших результатов, а вот довольно многие ребята (да и уже взрослые), хм, Илоны :) бесхарактерные и безвольные хуже капризных плаксивых девчонок.

Во-вторых, не зная конкретных метрик, сопутствовавших тем 32 успешным проектам (например, количество ошибок на 1000 строк кода), в принципе невозможно понять, был ли причиной успеха озвученный подход, или что-то другое. Может быть, товарищ просто работал в очень хорошей команде, или корпоративная культура компании оказалась такой позитивно-стимулирующей, кто знает?

P.S. Кстати, очень известные ИТ-компании, связанные с обучением в России, гордившиеся своей корпоративной культурой, трусливо сбежали, бросив своих платных учеников на произвол :) Ну понятно, погоня за долларом для капиталистов превыше всего.
Вот вам и характер (точнее, его полное отсутствие).

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

Но главное, что эти принципы на самом деле имеют глубокие математические обоснования, о которых вам однако не расскажут ни на одном онлайн-курсе (кроме моих, и некоторых американских :). А ведь такое фундаментальное понимание SOLID существенно повышает управляемость вашего проекта.

Ну например DRY (Не повторяйся) -- это вот точно анти-унификация.

Посетил конференцию Фибоначчи. Это было круто! Так круто, как две предыдущие конференции, вместе взятые.
Интересно, что инженеров там было больше чем программистов в соотношении примерно 1.6:1.

Наглядный пример, почему, когда вам начинают рассказывать про "современные" технологии, которые якобы куда круче олдскула, то это либо добросовестное заблуждение, либо примитивный пиар (чаще всего, смесь). Обычно такие заявления снабжаются мемами про супер-продуктивность, спасение мира ИТ и т. п.

Вот дескать как стать в 10 раз продуктивнее, изучая абстракции: "The Secret of Simple Code"
The secret to being 10x more productive is to gain a mastery of abstraction...
Abstraction is the process of simplifying code by finding similarities between different parts of the code and extracting shared logic into a named component (such as a function, module, etc...)

Нюанс в том, что этот вышеупомянутый процесс был формализован и автоматизирован(!) ещё в 1970-м легендарным Гордоном Плоткиным.

Как-то странно говорить на эту тему 50 лет спустя в контексте "десятикратной продуктивности" при ручном использовании абстракций, не находите? Ну вот такое сегодня массовое обучение программированию по всему миру, и такой уровень инструментария.

В информатике имеет смысл полагаться исключительно на мнения экспертов уровня PhD - выходцев из единичных школ computer science мирового уровня (Массачусетс, Карнеги-Меллон и им подобных).

Шикарная пародия FizzBuzzEnterpriseEdition на все эти ваши многослойные абстракции, получившие такое распространение в мэйнстриме "благодаря" книгам вроде "Паттерны архитектуры корпоративных приложений" Мартина Фаулера, ну и архитектуре Spring например, хм. Когда пишете бесконечные цепочки однострочных функций, вызывающих друг друга (что преподносится вам как функциональное программирование), или организуете иерархию классов в семи файлах (что подаётся как ООП).

Мартинфаулерщина например, это когда вы "оптимизируете"
contract.calculateTotalRevenue()

в Service Layer Abstraction (TM)
calculateTotalRevenue(Contract)

Но это не работа с формой, это не паттерн, это не правило думательной машинки, это просто какой-то детский сад :)

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

В отношении этого поста, мне тут справедливо заметили, что много анти-унификации тоже плохо :)

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

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

Кот Шредингера заходит в бар... и не заходит.

Тахион заказывает пиво. Тахион заходит в бар.

Гейзенберг едет в машине с Шредингером, когда полицейский останавливает их за превышение скорости.
- Вы знаете, с какой скоростью ехали? - спрашивает полицейский.
- Нет, - отвечает Гейзенберг, - но я могу точно сказать, где я нахожусь!
- Ладно, умник, открывай багажник!
Гейзенберг подчиняется.
- Вы знаете, что у вас в багажнике дохлая кошка? - спрашивает полицейский. Шредингер отвечает:
- Теперь знаю!

Кстати, специфика собеседований по System Design такая, что в отличие например от АСД, где оцениваются достаточно формальные моменты (алгоритмический и практический проблем солвинг, ясность кода...), в SD интервьюер старается не оценить то, в чём вы норм разбираетесь, а выявить ваши слабые места, где вы плаваете, где у вас мало опыта, и начать давить на них посильнее (сам так очень люблю делать).

Правильная стратегия тут: продемонстрировать приблизительное (на тройку-четвёрку) понимание всех компонентов на высоком уровне, и достаточное смирение, чтобы честно сказать в специфических или глубоких моментах "я этого не знаю". Ну, в смысле "я этого не знаю, но изучу по курсам ... или учебникам ... уточню у коллег если будет такая возможность" -- как минимум, по силлабусам курсов и книг SD у вас должно быть очень хорошее представление ("если ответите, какой вообще предмет вы сдаёте, получите тройку" :).

Не ведите себя на собеседованиях как дитя.

Хороший учебник "System Design. Общие принципы прохождения интервью по проектированию ИТ-систем", рекомендую (конкретно по теме его названия).

Классная задачка, встречается нередко при проектировании нагрузки в распределённых системах.

У вас в саду есть N бамбуковых деревьев с разными темпами роста. В конце дня вы можете спилить один бамбук до размера 0.

Надо подготовить график спиливания деревьев, чтобы минимизировать высоту самого высокого бамбукового дерева.

Частный случай -- когда темпы роста это N значений последовательности Фибоначчи, например для N=8 деревьев: [1, 1, 2, 3, 5, 8, 13, 21].
В первый день самое высокое выросло до 21, спилили; на второй день получилось 26=13+13, спилили ... Получится ли например далее удержать минимальную высоту 26 ?

Эта задача была формализована как Bamboo Garden Trimming (BGT).
Стратегий две: руби самое высокое, и руби самое быстрорастущее среди тех, кто выше x; главное, правильно их скомбинировать.

Какая красотища: Church of the Least Fixed Point

Сегодня День науки (был в СССР) кстати.

Мощная работа про полный обход конём шахматных досок самых разных форм, даже многомерных.

А "Magic: The Gathering", оказывается, Тьюринг-полная. Ух, сколько я в MtG играл...

Многократно подтверждено практикой в данном случае, это не просто теория Парето, что 80% багов в проекте генерируют 20% программистов в проекте.

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

"Единственное, что растет быстрее, чем производительность компьютеров -- это человеческая глупость"
приписывается Бьярну Страуструпу (автор С++)

Есть такой малоизвестный класс алгоритмов задержки (backoff algorithms), которые используются во многих распределённых системах, когда несколько сущностей/устройств конкурируют за общий ресурс. Часто задачки по этой теме формулируются как "шары в корзины" (и оказывается, что важным критерием становится количество синглтонов - корзин с одним шаром); однако существующие схемы анализа алгоритмов применяют сложные вероятностные инструменты.
Вот например полезная вводная заметка "Exponential Backoff или как "не завалить сервер", рекомендую всем, кто изучает фундамент highload:
"Совет: используйте экспоненциальное откладывание при любом повторе запроса — в клиенте при обращении к серверу или в сервере при обращении к базе данных или другому сервису."

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

Мартовский свежачок, где пацаны из университета Миссисипи показали, что можно эти задачи решать гораздо проще и точнее с помощью так называемых стандартных границ Чернова (простое оценивание вероятностного распределения); в тему неплохая лекция "Границы Чернова, маршрутизация пакетов по коммуникационной сети".

Сам Герман Чернов кстати, профессор MIT, родился в семье эмигрантов из России в 1923-м и прекрасно себя чувствует :)