Это сейчас такой прям модный-модный мем, что только под эту фотку не придумывают. Мой вариант: "за 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)

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

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

"Intelligent Machines and Idiotic Humans: A Startup Story"
(идеи для AI-стартапов)

Серия 8. Мета-автоматизация.

8 направлений, по которым сегодня можно неплохо использовать ChatGPT в помощь программистам.

1. Использование в качестве помощника/ментора в обучении программированию. Для начинающих очень хорошо, решения несложных задачек подробно объясняются.
2. Мозговой штурм.
3. Генерация шаблонного кода под вашу задачу (с которым потом всё же придётся поразбираться, как и с ответами на SO). Полезно попутно просить сразу написать тесты к решению (возможно, со 100% покрытием).
4. Code review.
5. Написание документации к коду.
6. Аннотации данных для машинного обучения.
7. Перевод кода с одного языка на другой.
8. SQL-запросы к БД. Только надо подробно объяснить схему базы, зато можно также, например, просить построить визуальные представления (мапы, графы...).

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

"World Wide Web получился ровно таким, которого мы всеми силами старались избежать: отсутствие необрываемых ссылок, постоянно меняющиеся или отсутствующие ссылки, цитаты, которые вы не можете отследить до оригинала, отсутствие версионного контроля и контроля за правами..."
— Ted Nelson, изобретатель гипертекста, легендарный ИТ-пророк, особо недолюбливающий HTML/XML и браузеры :)

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

"Generative AI is the source of digital effluence that is releasing massive quantities of textual shit, leaving a stain on everything it touches. As several others have observed, this moment in time delineates the Web not unlike nuclear testing did for low background steel."
-- Гради Буч, автор UML, IBM Research

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

2022: К 2030-му рынок метаверсумов составит 5 триллионов долларов.
-- McKinsey

Ну и где теперь это всё?

2023: В ближайшее время генеративный AI будет ежегодно добавлять мировой экономике 4,4 триллиона долларов.
-- McKinsey

Ну штош... А не отнимать ли?

Простые способы удерживать сложность проекта разумной, если вы не пишете highload на 100k rps.

-- синхронное, а не асинхронное
-- последовательное, а не мультитредовое
-- stateless, а не stateful

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

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

Я люблю дедлайны. Мне нравятся звуки, с которыми они пролетают мимо.

-- Douglas Adams ("Автостопом по галактике")

...В течение десятилетий мы боролись с использованием объектно-ориентированных языков, таких как Java или C++, чтоб объяснить эти простые идеи, и все время терпели неудачу. И я могу сказать тем из вас кто не вовлечен в сферу академического образования в данный момент, многие из моих коллег по всему миру находятся в той же ситуации, и отчаялись найти выход из нее. Уродливая методология, "шаблоны проектирования", "руководства по стилю", все они мешают преподавать принципы программирования. И даже если это отодвинуть в сторону, вы по-прежнему придерживаетесь императивного программирования на эфемерных структурах данных. Это просто не работает, поскольку это фундаментально неправильная вещь. Просто попробуйте преподать, скажем, удаление в двоичном дереве поиска; это ужасающая путаница! Вы закончите абсурдной ерундой "null-указателей", и сложной путаницей вызванной методологией, а не самой задачей. Очень скоро вам придется прибегнуть к "шаблонам" просто чтобы дать студентам шанс довести до конца что-нибудь вообще, отдаляя их от существа идей и создавая впечатление, что программирование болезненно и уродливо, что является огромной трагедией.

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

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

-- Роберт Харпер

Выложил в СильныеИдеи два больших материала, где разбираем его подходы, хотя бы на уровне базового понимания.

Ну и в целом вся моя Школа построена по схемам Харпера и других святых computer science из лучших университетов мира -- обучаю фундаментальным принципам программирования.

Девушки учатся "программированию"

(и вообще у автора неплохие ролики про карьеру программиста)