Архитектура с Лаптевым

Обновления с рынка найма.
В этом году я активно нанимал людей и последние недели активно ищу работу. Взгляд будет с обоих сторон.

Со стороны соискателя.
1. ХХ перестал подавать признаки жизни для соискателя.
Отклики там дают 0 интервью буквально для меня.
Автоотказов нет при этом, хитрые автоотказы с дневной задержкой проверить не могу, но мало кто такие инструменты использует (дорогие).

2. Прямые контакты через телеграм почти в 100% случаев приводят к собеседованиям.
Но это внешние для компаний рекрутеры и им платят за поиск людей а не просиживание штанов как штатным ейчарам.

3. Компании активно возвращают работников в офисы.
Это уже не нишевые игры Сбера. Но понимания, что уход в офис требует повышение зарплаты, мало. Курс экономики на зашел 😄

Год назад я писал, что проблема поиска сигнала среди шума обострилась. Но HRD это не понимали и не понимают и вместо этого с ветряными мельницами бьются (читерами).
Прошел год и найм вымер полностью в их компаниях.

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

Со стороны компании.
1. Читеров и автооткликов не выше 10% и ловятся они за минуту человеческим взглядом.
Если доля читеров выше, то значит что-то в вашей компании их манит и надо бы это исправить. Писал про это детально год назад в этом канале.

2. Очень много code monkey или кодеров, мало инженеров.
Около 90% кандидатов обвешались фреймворками и лучшими практиками, прагматичности мало, мало решали реально сложные задачи, редко когда могут сформулировать четко мысли.

3. Да, откликов на позиции архитектора и тех лида получаешь 500+, но из них опытных ребят максимум 30 человек наберется.
Если умеешь извлекать сигнал среди шума, это вообще не проблема. Я такой скрининг за 10 секунд делал ✨

4. HH бесплатно предоставляет классные инструменты фильтрации откликов, но ими почти никто не пользуется.
Я про опросники при отклике и AI рекрутер (да, его тоже бесплатно дают), который тот же опросник.

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

Все хотят инженеров, но нанимать не могут. Уникальная ситуация

Боли бизнеса 2.0
В начале года я создал базу данных реальных болей малого и среднего бизнеса с категоризацией, фильтрацией и пометками - https://painsighthq.com
Затем ушел с головой в другой проект и только недавно вынырнул из него.
А база данных все это время продолжала наполняться данными. И набрались десятки тысяч реальных проблем бизнеса.
Золото а не данные, надо бы их куда-нибудь пристроить 🤔 Есть идеи куда?

Недавно вышла AI модель Jev от TypeSafe – ультра дешевая и быстрая для категоризации данных. У меня категоризации очень много, так что буду заменять некогда самую дешевую модель от ChatGPT на Jev теперь.

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

БД + ИИ = ❤️

Современные БД уже давненько ушли от SQL или около того запросов.
Помню как 16 лет назад писал на C# функции, которые MS SQL Server исполнял. Ну или в SAP Hana на стороне движка БД исполнять C++ или JS код.

DuckDB добавила поддержку Jev как расширения и SQL запросы теперь слились с натуральными запросами к ИИ.
В какие чудесные времена живем.

Как принять решение, когда все опции плохие?

Если жить в мире паттернов и лучших практик, то всегда можно натянуть сову на глобус и не переживать за выбор альтернатив. Но есть плохие новости – AI это умеет делать хорошо и без человека 😆

А вот при выборе решения прагматично архитектору часто приходится выбирать между "Клизмой и Сэндвичем" 😄
Надежное решение при этом очень дорогое. Дешевое решение очень хрупкое. Быстрое решение усложняет поддержку. А медленное решение никогда не одобрит бизнес.

В одной из моих прошлых компании у CEO была дилемма – как получить дешевую бизнес аналитику.
Ему предлагали серьезные решения и его пугала финальная цена. В итоге он решил нанять джуна без комплексов и страхов, который на коленках дал ему бизнес аналитику.
Джун понятия не имел как устроен мир дата архитектуры. Он покрыл весь код продукта генерацией событий, которые постоянно слались в вебморду для дашбордов.
Дашборды мимикрировали под реальные как могли, у них не было исторических данных а были только реактивные события.
Исходный код был загажен мусорными событиями, которые усложняли разработку продукта с каждым событием все сильнее и сильнее.
То есть полученное решение формально было как бы очень простым и дешевым а по факту было безумно дорогим (постоянное ухудшение развития продукта) и нефункциональным.

Джун понял, что что-то не то и решил это исправить, засунув ручки в продовую БД (соединить дашборды и продовую БД продукта 🤣). Тут и подключился я, отрубив доступы к проду, и предложил альтернативу.

Вместо "сэндвича" я предложил ему "клизму" – реплицировать продуктовые данные в DWH и отвязать аналитические запросы от прода. Ну и конечно удалить его мусорные события из кода.

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

Как часто вам приходится выбирать наименее худшее решение?

Простота.

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

Дэвид говорит:
1. Публичные облака – это дорого и сложно. Мы можем сами создать свой дата центр и на коленках написать аналогичные решения. Станет сильно проще ведь мы контролируем все.

2. Очереди сообщений – это очень сложно. Мы их хоть и не использовали, а вместо них взяли самописный костыль поверх Redis.
Теперь мы делаем сапомисный костыль поверх БД. Это будет сильно проще чем мачурные очереди сообщений.

3. Нафиг Rails, мы будем вайбкодить на Rust теперь и всю кодобазу уже переписали. Создали 6 нативных приложений вместо одного.
AI теперь пишет код, наша жизнь стала проще.

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

А что простота означает для вас?

Низкое лейтенси и кеш, или снова про прагматизм.

Как-то само собой в наших головах устоялось как факт – хочешь низкое лейтенси, используй кеш а не БД.
Но время идет, и кеши и БД развиваются друг к другу на встречу. Кеши теперь от БД не отличишь, а БД содержат кучу всевозможных in-memory кешей.

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

Реляционные БД обычно не поддерживают шардирование из коробки (масштабирование операций записи), MySQL поддерживает но с кучей исключений.
Из коробки! - не надо тут про франкенштейнов поверх ядра вроде Postgres Pro и Тантор.
Кеши шардирование обычно поддерживают. Поэтому когда операций записи слишком много, кеши на удивление помогают, но не с производительностью как это принято считать, а с масштабированием 😁
А когда у нас в запасе NoSQL БД с часто неограниченным масштабированием, то и нужды в кеше получается что и нет.

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

Shopify убрал Redis и оставил MySQL и легко справился с их сумашедшей нагрузкой 😆
И это все не супер новая какая-то история, уже лет 10 как эти идеи актуальны. Но я по прежнему встречаю очень популярное заблуждение - хочешь низкое лейтенси, используй кеш а не БД.

Недавно видел одну как бы микросервисную архитектуру, где все сервисы обращаются к одному инстансу PostgreSQL 😄
Нагрузка постоянно растет, но БД ее не замечает. Как такое возможно?
А потому что эту БД со всех сторон обложили Redis вроде как кешом, а на самом деле каждый инстанс Redis – это отдельная NoSQL БД.
Меня улыбнула эта находка, но расстроило что за долгие годы я первый кто это заметил 🤣

Поэтому давайте будем прагматичными а старые верования пора обновить 😜

AI и SDLC
Этот пост не про то, как AI помогает, а про целую дисциплину, которую AI разломал.

Уход водопадных методологий на задворки трансформировал традиционное управление проектами.
Они стали про минимум оверхеда (планирование, болтание, согласование) и больше про разработку и деливери.

AI сделал написание кода commodity. И как теперь управлять проектами?
- Как оценить задачу/проект/затраты?
- Как оценить производительность человека/команды?
- Как оценить опыт инженера? Вчерашний джун уже мидл или еще нет?

Да никак и никто пока не придумал как. Но точно придумают и управление проектами снова изменится.

В моих командах, где мы внедряли AI в разработку с 2022 года, отчетливо выделялись следующие особенности
– Непредсказуемое velocity. Какие-то задачи AI решает за минуту, а какие-то задачи проще решить человеку.
– Человеческая нагрузка перенеслась с написания кода на его ревью и функциональное тестирование
– Средние значения метрик стали еще менее полезными
– Lead Time и поиск узких мест стали еще важнее

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

Как видите SDLC процессы в мире с AI?

Найм без участия рекрутеров. Как это?
Отлично 😁

Я снова ищу архитектора к нам. Но в этот раз по другому – без участия рекрутеров.

Этапы:
1. HR скрининг.
Заменил его обязательным опросником при отклике. Конверсия упала с 50% до 5% (из 1231 просмотров вакансии 56 отклик).
Максимум 10 секунд трачу на проверку каждого кандидата.

2. Проверка скилов.
Сразу прошу порешать архитектурные пазлы и описать самые важные технические решения, что кандидат принимал недавно.
Максимум трачу 2 минуты на каждого кандидата.

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

Меньше чем за 24 часа с момента открытия вакансии запланировал 2 финальных интервью.
Сколько времени на это потребуется рекрутерам? 3 недели? Месяц?

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

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

Я сам не люблю инвестировать время в неадекватные процессы, особенно когда в них вовлечена автоматика, которая неадекватность множит. Потратил время на тесты и получил 0 ответа 😢
Поэтому я и в описании вакансии и на каждом этапе уточняю, что рекрутеры не участвуют, поэтому будет несколько коротких и интересных тестов. А фидбек я даю в течении часа после отклика.

Давайте, делитесь любовью к рекрутерам в комментах 😄

P.S. ни один рекрутер не пострадал при написании этого поста

Observability нового уровня.

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

Работают они обычно через HTTP хелс чеки. Вернул HTTP эндпойнт 200 статус, значит продукт здоров и работоспособен.
А что если я скажу, что это вообще ничего не значит? 😄

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

Звучит круто, но почему тогда почти никто это не измеряет? Это отнюдь не новая идея.
Раньше это было дорого. Поди разорись на покупку NewRelic, который это поддерживает.
Сейчас это стало комодити и поддерживать это стали многие observability инструменты.

Ну что теперь то мешает?
Это непросто реализовать. Во-первых DevOps синтетическое тестирование не знают, некоторые QA знают.
А ты возьми да подружи PO, DevOps, QA и разработчиков это сделать. Лебедь раком щуку...

Раз уж пост от меня, то как тут себя не похвалить 🤣
Наш DevOps Lead поменял наш репортинг доступности на измерение реально важной функциональности пользователям.
И это было сделать сложнее чем обычно, ибо наши клиенты пользуются и несколькими десктоп приложениями, и веб приложением, и даже API. Про такое в книжках уже не пишут.

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

Трансформация принятия решений от разработчика к архитектору.

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

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

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

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

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

Замечали похожее?

Страх изменений.

Часто встречаете архитекторов, боящихся изменений?
Это фатальное качество для архитектора, ибо его для изменений и нанимают.

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

А ведь именно энтерпрайз – главный потребитель архитектуры. И многие архитекторы его касались.

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

Как избавиться от этого страха?
1. Сделать лоботомию 😄

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

3. Деливерить больше, страх быстро уйдет.

4. Проверять гипотезы на прототипах.

А как вы избавляетесь от страха изменений?

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

На подходе 2 поста – менеджерский и про архитектуру. На все вкусы 😁

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

Мне очень не хватало прозрачности. Кто у нас работает и как.
Что получилось за 3 месяца:
1. Мы в реальном времени видим производительность каждой команды и каждого инженера.
Это количество заделиверенных рабочих единиц.

2. Мы в реальном времени видим качество работы каждого инженера.
Это реворк и количество багов.

3. Мы в реальном времени видим процент попадания разработки в ожидания бизнеса.
Он разный, но у одной команды он идеальный.
Используем Sprint Drift - ABS (100% - Delivered/Expected)

4. Мы провели ассессмент по когнитивным навыкам и скилам.
Мы видим гепы и сильные стороны каждого. И инженеры у нас очень крутые.

5. Мы добились 70% адаптации AI в разработке.
Метрику я хитро проверяю и она очень близка к реальности. У адептов AI производительность дико высокая.

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

На подходе измерение Lead Time и точечная работа с узкими местами.

Как думаете, чего не хватает в такой системе измерений?