👋Открываю календарь. Всё рябит от разноцветных квадратиков. 10:00 - дейли, 11:00 - груминг, 12:00 - какой-то мутный «alignment meeting» с соседним отделом.

Это не работа. Это ритуальное сожжение самого дорогого ресурса - времени инженера.

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

Давайте честно: 90% встреч - это коллективная безответственность.

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

Посчитайте burn rate. Десять инженеров на час - это стоимость нового Макбука, выброшенного в окно. И ради чего? Ради резолюции «давайте соберемся еще раз через неделю»?

Мои три правила выживания в этом цирке:

1️⃣Нет адженды и четкой цели - инвайт летит в корзину. Без разговоров. Мое время - не мусор.

2️⃣ Встреча без протокола - преступление. Нет письма с итогами «кто-что-когда»? Значит, встречи не было. Вы просто украли у компании час времени.

3️⃣Правило красной трубки. Если ты молчишь больше 15 минут и не понимаешь, зачем здесь, - жми красную кнопку. Ваше время дороже чужих обид.

Работа делается в тишине, в IDE и консоли, а не в болтовне. Хотите эффективности? Объявите «дни без встреч» и посмотрите, как внезапно начнут закрываться тикеты, которые висели месяцами.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋На днях собеседовал очередного кандидата. Сеньор. Резюме - хоть сейчас в рамку, на стену вешай. Все модные слова на месте: Kafka, Kubernetes, Istio, все дела. Светится, как новогодняя елка.

Ну, думаю, дай спрошу что-нибудь простое, из жизни. Говорю: «Окей, представь. У нас есть сервис А и сервис Б. Сервис А меняет какие-то важные данные. Как ты обеспечишь консистентность этих данных в сервисе Б с минимальной задержкой и гарантией доставки?»

Парень завис. Похлопал глазами. А потом его понесло. Он начал мне рассказывать про партиции в Kafka, про брокеров, про репликацию и retention policy. Он говорил минут десять. Я слушал. А потом остановил его и спросил: «Подожди. А почему именно Kafka? А если у нас там нагрузка - три сообщения в час? Может, хватит обычной таблицы в Postgres для исходящих событий?»

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

И вот что я вам скажу. Мы перестали растить инженеров. Мы начали штамповать операторов конкретных технологий.

У нас есть «Postgres-эксперты», «Kafka-евангелисты», «Kubernetes-гуру». Каждый из них вырыл себе очень глубокий, но очень узкий колодец. Они знают всё о своей маленькой ямке, но понятия не имеют, что происходит на поверхности. Они видят небо в виде крошечного круга и думают, что это и есть весь мир.

👀Архитектура в таких командах превращается в ад. Это как в притче про слепых и слона. Один пощупал ногу и кричит: «Это колонна!». Другой схватил за хвост: «Это веревка!». Третий наткнулся на хобот: «Это змея!». И никто из них не видит слона - то есть всю систему целиком. А архитектор бегает между ними, единственный зрячий, и пытается объяснить, что их веревки и колонны - части одного живого организма, который вот-вот на них наступит.

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

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

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

🤡Пожалуй, это последний мой выплеск яда в этом году. Скоро все будут резать оливье и смотреть на салюты. Так вот, я не буду желать вам удачи или денег. Я желаю вам в новом году одного - широты взгляда.

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

С наступающим. И не наступайте на те же грабли.💯

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋На днях наткнулся на интересный проект — OpenIDE . Позиционируется как «наша новая открытая среда разработки».

Что это по факту? Взяли IntelliJ IDEA Community Edition, вытряхнули из неё всю телеметрию и проприетарные компоненты JetBrains, а затем прикрутили обратно то, без чего современный Java-разработчик чувствует себя голым: поддержку Spring и Docker.
То есть, по сути, нам вернули часть функционала платной Ultimate-версии, доступ к которой для нас сейчас, мягко говоря, затруднён.

Но давайте без иллюзий. Это не революция. Это реакция.

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

Все эти пляски про «серверы в России» — это не про удобство разработчика. Это про снижение рисков для бизнеса. Теперь ваша IDE ходит за плагинами не в Прагу, а, условно, в Мытищи. Это важно для юристов, но это не повод для инженерной эйфории.💯

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

👉Делитесь мнением: кто уже пробовал? Как ощущения? И есть ли тут те, у кого в компании переход на отечественную IDE уже стал обязательным требованием?👈

#интересное

🤡Токсичный (it) архитектор🤡

👋На днях ревьювил архитектурную схему одного юного дарования, свежеиспеченного выпускника модного курса. Везде микросервисы, CQRS, Event Sourcing, Kafka... И всё это на проекте, где нужно было сделать CRUD для трех табличек.

Я посмотрел на схему, потом на него, и спросил: «Тебе самому-то не смешно?».

Проблема в том, что люди разучились включать голову. А ведь это главная задача архитектора - думать.💯

Современный мир позволяет не напрягать мозг. ИИ уже может генерировать сложные куски кода. Но проблема в том, что этот код надо валидировать. Нужно понимать, что именно вам нагенерили. А вместо этого молодые специалисты бегут на курсы с названием «Микросервисная архитектура», где им обещают, что эта волшебная таблетка сделает продукт быстрее и надежнее.

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

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

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

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

И тут возникает резонный вопрос: «А что, тогда не учиться по книгам? Есть же классика проектирования!»

Отвечаю: Книги и курсы - это не инструкция к применению. Это каталог.

Каталог чужих решений для чужих проблем. И это бесценно. Когда у вас действительно возникнет боль, вы сможете заглянуть в этот каталог и найти подходящий анальгетик. У нас медленные запросы на чтение? Окей, давайте посмотрим, что там пишут про CQRS.

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

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

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Всем привет. Сегодня нет желания токсичить, есть вопрос к вам.

Из каждого утюга сейчас вещают, как ИИ «изменит всё», «повысит маржу» и «сделает нас счастливыми».

На днях постучались ко мне ребята, которые клепают курсы. У них там направление для архитекторов, и, естественно, нужен блок про ИИ. Потому что без магических букв «AI» на обложке сейчас любой курс считается устаревшим.

Спрашивают: «Как припахать ИИ к реальным архитектурным задачам?».

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

Но если отбросить маркетинговую шелуху, польза есть. Первое, что сразу пришло в голову:

1️⃣Валидация ADR (Architecture Decision Records). Скормить контекст и спросить: «Где я идиот?». Иногда он реально находит граничные случаи, про которые вы забыли в 3 часа ночи.

2️⃣ Саммари бесконечных созвонов. Два часа переливания из пустого в порожнее сжимаются в пять буллитов. Это не просто удобно, это спасение для психики.

3️⃣Быстроскриптинг. Накидать на коленке Python-скрипт для расчета метрик или парсинга логов, чтобы не вспоминать синтаксис библиотек.


Короче, вопрос к вам, выжившие.

Как вы реально применяете ИИ в работе? Не для «вдохновения» и генерации картинок с котиками, а для дела. Что можно внедрить в курсы или рассказать коллегам, чтобы они научились делегировать машине именно мусорную работу?

Жду ваши кейсы в комментариях.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Смотрел вчера резюме очередного «сеньора-помидора». 12 лет в одной конторе. Гордится стабильностью, ждет медаль. А я смотрю на это и вижу не лояльность, а диагноз.

Нам с пеленок вбивали: сиди на попе ровно, стань ветераном труда, получишь грамоту. Наверное, это прекрасно работает для хирургов или пианистов. Но для архитектора «30 лет в одном энтерпрайзе» — это профессиональная деформация, несовместимая с жизнью.

Если ты сидишь на одном месте десяток лет, ты не архитектор. Ты — хранитель костылей.

Я не говорю про аутсорс, где проекты меняются как перчатки. Да, там тоже хватает говнокода, но там хотя бы мозг постоянно тренируется на новых вводных.

В продуктовом же энтерпрайзе ты просто выучил свою систему. Ты знаешь историю каждого «велосипеда», изобретенного в 98-м, и начинаешь верить, что это и есть индустриальный стандарт. Твой кругозор сузился до размеров корпоративной VPN. Ты не решаешь проблемы бизнеса, ты просто знаешь, в каком месте пнуть этого монстра Франкенштейна, чтобы он не сдох до понедельника. Это не архитектура, это стокгольмский синдром.

Способен ли теоретический опыт из книг сделать хорошего практика? Не смешите мои тапочки. Теория без боли от внедрения в разных контекстах — это беллетристика. Если ты не видел, как твои «гениальные» паттерны с треском ломаются в другой среде, ты — теоретик. Картонный генерал.

И тут возникает вопрос: «А если я меняю работу, но остаюсь в одной сфере?».

Прыжки между двумя банками — это как пересаживаться из одной камеры в другую. Стены те же, решетки те же, только баланда чуть солонее. Ты учишься решать специфические банковские проблемы (ACID любой ценой, бюрократия, легаси на мейнфреймах), а не инженерные. Глаз замыливается. В итоге ты начнешь пихать транзакционную целостность даже в сервис лайков для котиков, просто потому что «мы в банке всегда так делали».

И что нам остается делать?

✅3-5 лет — золотой стандарт. Спроектировал, внедрил, хлебнул горя с поддержкой (это обязательно!), исправил свои косяки — и вали. Не засиживайся.

✅Меняй домены. Уйди из финтеха в ритейл, из ритейла в IoT или медиа. Это больно, страшно, но это единственное, что выбивает дурь из головы и учит думать, а не копипастить.

Не путай опыт с выслугой лет. Один год опыта, повторенный 20 раз подряд — это не 20 лет стажа. Это стагнация.

❓Делитесь мнением: верите ли вы в существование крутого архитектора с одной записью в трудовой за 15 лет? Или это миф?

#заметкинаполях

🤡Токсичный (it) архитектор🤡