Вообще, кстати, есть одна мысль, которая пришла в голову

А вы вообще задумывались, что то, что люди радуются, когда пишут заявление на увольнение - эт вообще-то показатель лютейшей несостоятельности компании?

А это ведь норма современной жизни. Я буквально отовсюду слышу типа «Блин, я на свободе», «Ура, я так счастлив(а)», «Лучшее решение в моей жизни» и так далее

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

Они ловят кайф от работы, представляете? Вот вы давно ловили кайф от своей работы? Ну вот прям чтоб по-настоящему? Чтобы прям такой встал с утра и такой блин как я щас с кайфом поработаю. Спрашиваю, кстати, без сарказма, уверен, что такие люди есть

Но, как ловить кайф от постоянных зум созвонов?

Как ловить кайф от неадекватных менеджеров, которые сами не помнят, что хотели сделать вчера?

Как ловить кайф от задач, которые даже блин тем, для кого они якобы предназначены, не нужны?

Как ловить кайф от вредительства?

В нас на самом деле заложены достаточно мощные механизмы сотворения добра. Мы искренние переживаем внутри, когда понимаем, что делаем какое-то гавно.

И этот механизм давится нами сознательно, ну потому что жизнь такая, надо на что-то жить, это они виноваты, я просто исполнитель и тд и тп

Расплатой как раз становится вот такая вот нежизнь. Когда уход с работы воспринимается буквально как освобождение от рабства

40 часов в неделю (по факту еще больше) ты находишься в этом самом узаконенном рабстве. В ментальной тюрьме. Интересно даже узнать стоит ли оно той зарплаты? Ну мне можно не отвечать, себя-то не обманешь

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

У нас было 2 джиры, 75 bpmn-диаграмм, 5 менеджеров, пол-ставки админа и целое множество баз данных всех сортов и расцветок, а также Java, Kotlin и Spring. Не то что бы это был необходимый запас для проекта. Но если начал кодить, становится трудно остановиться. Единственное что вызывало у меня опасение - это suspend-методы. Нет ничего более беспомощного, безответственного и испорченного, чем корутины в проде. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Мы с Женей всегда говорили: важно не просто делать, а действительно понимать, что ты делаешь и как это работает.

И вот CEO GitHub Томас Дохмке на VivaTech 2025 в подтверждает это Париже:

• AI‑ассистенты позволяют баловаться с вайбкодингом — быстренько запиливаем, не погружаясь слишком в пучины технологий.
• Но это только начало. Без глубокого понимания системы стартап сложно масштабировать — чтобы привлечь раунды инвестиций, нужна техническая команда с реальными навыками
• По словам Томаса: «Ценность вашего стартапа определяется не тем, что вы можете собрать задёшево» и «нужно понимать, когда использовать ИИ‑подсказку, а когда писать код самому»

Непрошеный совет от нас: не гонитесь слепо за инструментами или хайпом. Гонитесь за пониманием. ИИ может ускорить старт — но чтобы вырасти, нужен фундамент: знание работы системы, архитектуры и процессов

Пить чай с бухгалтерией иногда важнее написания кода

Вспомнилась другая история примерно из 2014 года, как я прикручивал мастеркард к одной большой платежной системе. Удивительным образом часть моей работы заключалась….в испитии чая вместе с бухгалтерами.

Почему так?
У меня не было отдельных системных аналитиков, которые бы рассказали как какая авторизация/рефанд/реверсал/что угодно будет отражена на счетах. Приходилось разибраться в тонкостях процесса, бухучета и хрен знает чего еще. На мониторе у меня были налеплены стикеры с основными терминами, а я мог объяснить логику укладки транзакций не хуже банковского аналитика. По итогу это был самый пустяковый проект для меня с точки зрения доработок и допилок, хотя предметкка нифига не простая

Как приучить python-котиков к лотку

Как вы знаете, я не очень жалую питон. На это есть 2 основные причины
- Он слишком много разрешает. Можно поприседать задницей на клавиатуру и интерпретатор исполнит получившийся результат. Сначала это выглядит как ВОООУ ГИБКОСТЬ!!11, а потом нужны еще +3 человека, чтобы эту гибкость выпрямить
- Динамическая природа языка. Её можно поправить, но только отчасти

Так вот, проект куда меня позвали спасать был написан на питоне. Он был свеж и можно сказать greenfield, но спустя совсем непродолжительное время начались классические проблемы — код перестал быть поддерживаемым: запутались в цепочках вызовов и перестали понимать что происходит

Что нас в итоге спасло:
- Разделили убер-классы с бизнес-локикой на небольшие классики, похожие на UseCase
- Внедрили статическую типизацию через mypy и заставили ее работать, а не просто формально присутствовать (хотя к работе mypy тоже есть вопросики, но это обусловлено самим языком и все же лучше чем ничего).
- Впоследствии еще сделали прото-объекты-значения, чтобы понимать какой float что обозначает в параметрах метода
- Приделали returns . Стало понятно что можно ожидать от метода. Кстати есть плагин для mypy
- Обмазали правилами из pylint . Самое эффективное правило у нас - ограничение цикломатической сложности. Поскольку проект был MLный, то нередко можно было встретить код с 10ю вложенными циклами, что уводило читабельность и понимаемость в отрицательную зону

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

Я недавно рассказывал, что мы запустили новую авантюру под названием курсовой проект. Задача: освоить TBD (Trunk-Based Development), чистую архитектуру и на практике пощупать DDD и другие DD путем совместной разработки относительно сложного приложения, а то и нескольких. И, конечно, наступить на максимальное количество граблей, ибо бег по граблям — это суть обучения (без шуток).

На этой неделе закончили моделировать предметную область через Event Storming (по ссылке результаты)  и нарисовали концептуальную модель данных. За основу взяли пару процессов из банка — KYC и непосредственно переводы деняк.

Правда, предметка хоть и похожа на реальную, но не стремится быть точной копией. Если пытаться сделать 1 в 1, можно увязнуть в деталях и не успеть реализовать самое важное, учитывая что подход знаком не всем. А усложнить всегда можно и даже нужно, ибо мы будем вносить изменения (с нуля то и обезьяна может разработать). Сразу попалась ситуация когда как будто вырисовывается 2 контекста, но пока лингвистических конфликтов нет, то будем держать все в одном, а потом разделим если понадобится. Такое вот эмпирическое правило, заодно потом потренируемся выделять контексты и микросервисы

Выводы на текущий момент: Возможно, Event Storming больше проводить не будем в следующих потоках (если они будут), уж больно много времени ушло. Главная цель — потрогать код, получить контролируемые страдания, а не рисовать стикеры. В конце концов, умельцев, которые только и делают, что рисуют диаграммы, в интернете и так хватает. Хотя… посмотрим.

🧠Как работают ИИ-модели? Исследование, которое проливает свет на магию

Когда спрашиваешь людей, «почему Т9, которая вчера дописывала слово “приветики”, сегодня пишет код как уверенный джун?», чаще всего в ответ слышишь:
«Нууу, там обучееееение, весаааааа, тоси-боси… в общем, сам не знаю».

Но! Недавно попалось исследование, в котором авторы реально попытались докопаться до сути — что именно происходит внутри LLM, когда они делают то, что делают.

Вот парочка занятных моментов:

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

Статья большая, но даже поверхностное знакомство — уже пища для мозга. Рекомендую, если вам тоже не даёт покоя вопрос: “Как вообще это возможно?”

вот еще годный конспет по тому, как работают LLM

Можно ли смешивать стили в архитектуре?

Да, и иногда это даже необходимо.

Вот пример. Допустим, наше приложение решает две задачи:
– выполняет сложную бизнес-логику,
– и просто проксирует запросы в соседний сервис, проверяя авторизацию.

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

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

Что с этим делать? Разделить приложение на две части, каждая со своим стилем:
• для бизнес-логики — использовать полноценную архитектуру, паттерны, валидацию, слои и всё такое;
• для прокси — ограничиться минимальным набором: контроллер и HTTP-клиент. Тут вообще напрашивается готовое решение, но иногда проще сделать внутри, учитывая что логика может появиться, хоть и очень простая.

Вывод: Стили можно (и нужно) сочетать, если это упрощает разработку. Главное — чтобы архитектура была практичной, а не просто нагромождение абстракций ради абстракций.

Единая модель, множественные страдания

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

В один условный Order свалили всё подряд:
– маркетинг,
– доставку,
– гарантию,
– бухгалтерию,
– и еще кучу других контекстов.

Один класс. Несколько таблиц. Сотни полей. Всё ради принципа DRY.

Выглядело это как «единый источник правды», но по факту стало «единым источником страдания». Потому что теперь, чтобы добавить одно поле в заказ, нужно пройти согласование у двух десятков (!) команд и потерять к жизни интерес.

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

Делитесь своими кулсторями про универсальные модели в комментах. Мы знаем, они у вас есть)

Божественный костыль для тех, кто не умеет

Ах, ИИ — новая волшебная таблетка! Достаточно добавить «с ИИ» в описание проекта, и вот уже инвесторы бегут со следующей порцией подливы, клиенты оттягивают вам резинку труханов, чтобы напихать хрустящих купюр, а код сам себя пишет. Напоминает вам что-то? Например, NoSQL в 2010-м, микросервисы в 2013-м и блокчейн в 2017-м — только вид сбоку.

Конечно, есть команды, которые реально получают буст от ИИ. Но сюрприз-сюрприз: у них и до этого всё было неплохо — и требования вменяемые, и в коде разобраться можно.
А есть другие. Те, кто уже в своём коде не разбирается, но свято верит, что вот-вот появится ИИ, в который можно запихнуть весь проект, нажать кнопку «Сделать хорошо» — и вуаля, можно идти пить тыквенный латте (это не шутка, я слышал такие разговоры).

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

Мы все живые люди, а не собственность работодателя.
Работа — это просто работа. И многих HR сам факт этого доводит до микроинсульта.

Если бы не кредиты, ипотеки и не современная экономическая система —
большинство из нас вообще бы не работали, а занимались бы чем-то реально интересным.

Будем честны: какой вообще интерес — до конца жизни перекладывать JSON на одной из этих джейсоноразвесочных фабрик, коими стали огромное количество проектов?

И если уж мы начали оценивать вовлечённость по внешним признакам — может, стоит проверить, нет ли у автора поста детей, супругов, собакенов? Ведь это всё тоже мешает KPI-экстазу.

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

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

Идеальное описание такой вакансии звучало бы так — «Умеете включать компьютер и не ходите под себя? Приходите! Платим сотни нефти». Разумеется, деньги — аргумент. Можно хотя бы поплакать в свою финансовую подушку, когда следующий HR с неподдельной скукой будет слушать, как вы вовлечённо закапывали свои навыки, амбиции и ментальное здоровье.

Но вообще мне повезло, со мной хотя бы пообщались.

Если вы тоже работаете в компании,в которой главный продукт -- производство обсуждений, ставьте лайк

ИИ снова в новостях: то удалил БД, то слил данные. Ничего удивительного — ИИ может "глючить".
Но вот что странно: никто толком не понимает, как он работает (исследования только начались), а его уже внедряют повсюду. Что же может пойти не так?

P.S.: А ещё это огромное хранилище уязвимостей — под LLM даже свой OWASP Top-10 появился.

Иногда у них даже получается

Cultural map на пальцах. И без переломов

Недавно мой коллега, коренной британец, с пафосом викторианского джентльмена пожаловался на американцев в стиле «Ну тупые». Его пример: в Британии — horse riding, в американском английском — horseback riding. Мол, зачем эти уточнения? Ну и так же ясно, куда именно надо садиться на лошадь. Не на хвост же, хотя, конечно, в жизни всякое бывает.

Но на русском это вообще будет «верховая езда». И тут мы пошли ещё дальше: мы даже не уточняем, на ком или чём мы там верхом. Всем и так понятно, что не на корове (а вот когда Шурик в Кавказской пленнице на осле ехал — это все еще верховая езда?)

Это, кстати, отлично иллюстрирует книгу The Culture Map. По мнению автора, одна из ключевых разниц между странами — это сколько контекста подразумевается в сказанном.
• У американцев контекста почти нет: что сказали, то и имели в виду.
Пример: «Let’s meet at 3 p.m. at Starbucks on 5th Avenue» — это буквально приглашение встретиться в 15:00, в конкретном Старбаксе, на конкретной улице.
• У британцев контекста больше: надо понять подтекст, тон, скрытую вежливость.
Пример: «We should get together sometime» — значит «Мы, конечно, никогда не встретимся, но я вежливо изображаю заинтересованность, чтобы не показаться хамом».
• В России уровень контекста ещё выше: половина смысла в интонации, а вторая половина — в том, что не сказано.
Пример: «Надо бы встретиться» — в зависимости от тона это может значить:
1. «Я тебя реально хочу увидеть»
2. «Мы больше никогда не увидимся»
3. «Ты мне должен денег»
4. «Я уже возле твоего дома»

В общем, чем восточнее, тем меньше слов и тем больше догадок. Книга однозначно рекомендована к прочтению.

Вакансия: Платформ-лид в Яндекс Крауд

Компания Яндекс открыла позицию платформ-лида.

В описании упоминаются:
• DDD
• Clean Architecture
• Trunk-based Development
• Event Storming
• TDD

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

Из хорошего: количество собеседований сократили, так что можно попробовать свои силы;

По всем вопросам пишите CTO @Dzirtik

P.S.: Это не реклама, а вакансия от проверенных людей. Публикуем, потому что таких позиций на рынке 3,5 штуки.