Вообще, есть единственный стратегический вопрос, которого следует придерживаться в любом проекте, и ответу на который я стараюсь учить: Как мы можем сделать это правильно?

Если вы осознанно не атакуете сложность, она обязательно будет атаковать вас.

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

Оборот индустрии картонных коробок в США -- 41 миллиард долларов. Для сравнения, НФЛ зарабатывает в год 13 миллиардов долларов, МЛБ -- 9 миллиардов, НБА -- 5 миллиардов и НХЛ -- 4 миллиарда долларов.

Но что, по-вашему, более достижимо -- попасть в НХЛ, как наш вратарь Сергей Бобровский, или начать бизнес по производству картонных коробок? Или, может быть, создать ИТ-стартап в сфере AI, которая уже в этом десятилетии перерастёт триллион долларов?

Правда в том, дорогие, что ваши самые глупые и простые идеи часто срабатывают лучше всего. Ориентируйтесь на как можно более массовое и простое применение сервиса.

Джеймс Альтушер, автор десятков книг включая классную "Учитесь говорить "Нет", участвовавший в создании множества стартапов, управляющий крупными хедж-фондами, рекомендует простой приём: завести привычку каждое утро записывать 10 идей по актуальной для вас теме.

"А если просто не получается придумать 10 идей? Есть один фокус: если не можете придумать 10 идей, придумайте 20. ...Вы слишком сильно на себя давите. Перфекционизм – ВРАГ идейной мышцы. Мозг пытается защитить вас от вреда, мешает придумать глупую идею, которая вас опозорит или принесет боль. Этот механизм можно отключить, заставив мозг придумывать плохие идеи...

Делаете два столбца, в левом – список идей, в правом – список ПЕРВЫХ ШАГОВ для их реализации. Запомните: для каждой идеи надо записать только один первый шаг."

Ричарду Брэнсону (миллиардер, слетавший в космос в 70 лет, основатель консорциума Virgib Group с сотнями компаний -- так назвал, потому что был "девственником" в бизнесе), когда он ещё был рядовым издателем журнала, однажды не понравилось обслуживание авиакомпании, которой он летал. Поэтому у него возникла идея: "Я создам новую авиакомпанию". Как это можно создать авиакомпанию с нуля и без денег? Его первый шаг: он позвонил в Boeing и узнал, можно ли взять у них в аренду самолет. Ну и закрутилось.

...А сегодня в одной только теме ИТ-стартапов AI куча вполне продаваемых идей просто на поверхности лежит, пишу и тут в частности регулярно.

Jim Fan -- AI-исследователь в NVIDIA и PhD Стэнфорда, рассказал, как в Stanford Vision and Learning Lab создаётся ObjectFolder -- "a very unique dataset for multisensory object-centric learning, geared towards object recognition, reconstruction, and manipulation with sight, sound, and touch. Features 100 real-world household objects and 1,000 neural objects. Each is defined by an "ObjectFile"..."
То есть Стэнфорд создаёт объектно-ориентированный AI )))

Кстати, на днях в Scientific American вышла статья, где предполагается, что посещающие возможно Землю инопланетяне НЛО рептилоиды -- это не органические существа, а активно развивающийся где-то в других мирах AI, добравшийся и до нас. А кожаные-белковые, которые его создали, уже давно всё :)

Поэтому давайте срочно оседлаем волну экспоненциального прогресса!
До тех пор, пока мы ещё можем идти в ногу со временем...

Сэм Альтман: Я за регулирование AI-отрасли!
Также Сэм Альтман: Кроме моих работ. Мне можно доверять!

Ораклу зачёт: классно троллит мировое ИТ )))

JEP 445: Unnamed Classes and Instance Main Methods

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

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

Когда я узнал, что Роберт Харпер (один из святых computer science, написавший кучу курсов для CMU) выгнал Java из учебных планов, настояв на преподавании OCaml и SML (семантику которых он описал формально), то сперва подумал, что он просто выдумывает причины, чтобы навязать свой любимый язык всем остальным. Теперь же я уверен, что он абсолютно прав, и поэтому в частности прикладной курс по ФП сделал на F#.

Java просто откровенно плоха в предоставлении нескольких интерфейсов для одной и той же реализации. Харпер пытался научить этому модульному принципу в Java в течение многих лет и потерпел неудачу. Сейчас я и сам иногда с этим сталкиваюсь, когда прошу курсантов привести примеры одной реализации с несколькими интерфейсами, и в 80% случаев получаю пример одного интерфейса с несколькими реализациями.

=

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

Забавная вещь происходит, когда система декомпозируется на модули, а затем позволяет их комбинировать (исчисление модулей в OCaml). Если это делать правильно, то в проекте появляется новая сущность, отдельная от системы и более долговечная, чем сама система: интерфейс.

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

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

Причём скиллы композиции и декомпозиции, конечно, ортогональны, и изучать их надо осознанно по отдельности.

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

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

Это сейчас такой прям модный-модный мем, что только под эту фотку не придумывают. Мой вариант: "за 3499 долларов, математики смогут наконец визуализировать многомерные пространства".

Однако вот более реалистичная версия...

Хорошее:

The C4 model — misconceptions, misuses, and mistakes... includes notation, abstraction levels (number of & naming), abstraction vs organisation, ADRs, DDD, event modeling, microservices, message-based architectures, and more.

От автора учебника "Software Architecture for Developers"

Его же "The lost art of software design"

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

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

Ну, это только потому, что вы не понимаете, как это работает :) Разберитесь, пройдите курсы по ФП (а для начала просто активно применяйте в своём коде map/reduce), и будете получать от использования функций высших порядков огромное удовольствие.

В продолжение про интерфейсы.

Например, мы вполне можем убрать из интерфейса стека специальные слова push и pop, и назвать эти операции просто add и remove. Потом мы можем создать интерфейс очереди, также используя операции add и remove. Когда я делал курсы по алгоритмам, сразу отметил, насколько похожи интерфейсы классов стека и очереди. Фактически, если заменить push и pop на add и remove, мы получим идентичный интерфейс! Не знаю, хорошо это или плохо, но люди, которые хотят объединить эти два интерфейса, встречаются примерно так же часто, как люди, которые требуют, чтобы их обслужили первыми, потому что они вошли в очередь последними.

Это показывает, что когда мы думаем об интерфейсах, мы думаем не только о том, содержит ли модуль функции с определёнными сигнатурами. Мы также думаем о спецификации -- о том, какого именно поведения мы ожидаем от этих функций. Возможно, рядом с функцией pop() есть комментарий, говорящий, что она обратна функции push(). Этот факт можно считать частью типа модуля в той же мере, что и сами сигнатуры функций, потому что знание этого факта необходимо для использования модуля! В идеале его надо сделать "физической" частью типа.

Существует несколько языков с достаточно мощными системами типов, чтобы выразить связь между push() и pop() -- например, Coq, Agda, Idris. Я могу показать вам, как это выглядит на любом из них, но к большому сожалению это совсем непрактично. Поэтому пока основное решение -- материалы из СильныхИдей, где я постоянно поясняю, как правильно думать на более высоком логическом уровне -- абстракциями, которые в обычном коде отсутствуют по определению.

Несколько потоков? Давайте запустим их в голове последовательно.

Иммутабельное состояние? В наших головах оно постоянно изменяется и читается атомарно.

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

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

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

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

И затем переделайте это так, чтобы оно стало проще. Вот этот способ.

Правильнее сегодня бояться не гонки суперинтеллектов AI, а гонки человеков, кто из них больший идиот...

(Так-то AI уже давно бы с нами покончил, если бы не python packaging...)

Как человек, который занимается архитектурными темами десятилетия, я совершенно уверен, что в ближайшее время нет и не будет никакого AI, способного разумно рассуждать на темы software/system design.

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

В прошлом году американские кадровые ИТ-консультанты стали жаловаться на существенное снижение спроса со стороны разработчиков на их услуги -- причём впервые за 10+ лет, раньше постоянно был регулярный рост (даже, можно сказать, бум спроса на сеньоров в крупные компании). Началось падение ещё весной 2022-го, задолго до явления ChatGPT. С чего бы это? )))

Статья в Computer World, где поясняются причины и приводится весьма обширная статистика по сокращениям.

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

На картинке: как снижался интерес программистов к помощи карьерных консультантов (преимущественно поиск новой работы), а доходы этих консультантов упали на 70-90%. Они, кстати, берут приличный процент от того повышения зарплаты, которое получает клиент (а моя помощь курсантам по карьере бесплатна).

Кто поклонник "Начала" Нолана и в целом многоуровневых фильмов "про подсознание", наконец появился его духовный наследник -- "Гипнотик". Очень хороший, рекомендую, многомерная реальность (только уже не во снах), местами в духе "Мистера Робота". Смотреть надо внимательно, и финал неплохой (только досмотрите после финальных титров, не пропустите).

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

P.S. Ёлки, не в тот канал отправил )))

В России же ситуация на рынке труда такая, что джуниоры уже довольно давно особо никому не нужны, и спрос на высокооплачиваемых сеньоров ощутимо снизился (компании не хотят вкладываться в нестабильной обстановке; причём и в США спрос упал сильнее всего именно на них), а вот крепкие миддлы чувствуют себя прекрасно, и платят им хорошо, и компании предпочитают растить сеньоров из своих проверенных кадров.

Дело в том, что книги курсы по карьере (да и не только) хороши максимум на 80%, однако важнее всего внедрять некоторую методологию развития карьеры для конкретной ситуации конкретного человека, а это возможно только в индивидуальном порядке. Мне, кстати, особо интересно помогать ребятам, у которых в плане карьеры сложилась самая сложная ситуация, какая только могла сложиться :) Потому что в таких ситуациях и я сам здорово прокачиваюсь как тренер. Типичная болезненная ситуация: хороший миддл получил 1-2 оффера, и начинает паниковать и метаться ))) принять или нет? а если принять, как не продешевить по зарплате?

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

Главное ограничение индивидуальной помощи в том, что она не масштабируется. И при этом хочется помочь как можно большему числу людей, хм. (Уловка-22)

Когда пишешь на языках с динамической типизацией )))

(Я действительно не понимаю, почему люди отказываются от преимуществ, предоставляемых системой типов)