Илья Шишков: код, собесы, IT

Don't even try to PG_TRY

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

Залез в код, раскрыл для вас все макросы, показал то что скрыто 😆

Что я рассказал в видео:
— для чего именно сделали исключения в PostgreSQL
— как на языке С реализовали исключения в PostgreSQL, до самых глубоких деталей
— что будет, если нарушать гайдлайны использования PG_TRY
— что будет, если не поймать выброшенное исключение
— почему в коде PostgreSQL опасно использовать C++

Таймкоды видео:
— 00:00 — начало
— 01:01 — концепция исключений в языках программирования
— 02:56 — пример использования PG_TRY в коде PostgreSQL
— 05:26 — с какой целью в PostgreSQL применяется PG_TRY
— 07:16 — что ускользает из внимания в документации
— 09:48 — как внутри устроен PG_TRY?
— 14:30 — магия функции siglongjmp
— 17:12 — почему после PG_CATCH нельзя просто продолжить?
— 24:02 — где обрабатывается исключение, если нет ни одного PG_CATCH
— 28:35 — чего нельзя делать внутри PG_TRY/PG_CATCH и причём тут C++
— 33:49 — итоги

Можно смотреть:
— тут в Телеграм
— 😉 на моём YouTube-канале
— 😄 на странице в ВК

Когда производительность упирается в железо, а когда в архитектуру? Как проектировать надежные и быстрые системы на C++? Какие подходы используют разработчики компиляторов, рантаймов и системного ПО?

Ответы на эти и другие вопросы найдем на C++ Russia — конференции для C++ разработчиков, инженеров, разработчиков компиляторов, тимлидов и исследователей.

📅 7 мая 2026 — онлайн-день
📅 16–17 мая 2026 — Москва + онлайн

Три дня докладов, воркшопов и общения C++ сообщества. Будем говорить про язык и инженерные задачи: архитектуру, производительность, управление памятью, многопоточность и разработку низкоуровневого ПО.

Новое в этом году — системное программирование: компиляторы, рантаймы, операционные системы, управление ресурсами и дизайн языков программирования.

В карточках собрали несколько топовых докладов из программы.

Используйте промокод, чтобы купить персональный билет со скидкой — IMHIRED

Купить билет

Реклама. ООО «Джуг Ру Груп». ИНН 7801341446

Три главных инсайта с AI DevDay

Я сходил на второй AI Dev Day в Яндексе. Его главное отличия от первого мероприятия: позвали спикеров из других компаний и сфокусировались не на инструментах, а на анализе эффективности использования AI в разработке. И у меня после него осталось три чётких инсайта.

1. Концепция AI-first разработки

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

В последнее время я и сам стал на подобном себя ловить. Есть задачи, где нет исследования: нужно поправить несколько файлов, написать тесты, всё это прогнать и довести до рабочего состояния. Раньше это был режим «сел и сделал». А сейчас у меня первая мысль — «может, проще поставить задачу и проверить, что получилось».

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

2. Внедрение AI происходит крайне неравномерно.

В моём информационном пузыре сейчас все обсуждают ClawdBot, OpenClaw и подобные штуки. Создаётся ощущение, что «все уже там». На митапе я специально спрашивал всех подряд: кто реально пользовался и получил пользу. Я не нашёл ни одного. В то же время на одном докладе рядом со мной сидел человек, который с помощью Claude desktop возился с какими-то документами.

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

3. Как выглядит разработчик будущего

Разработчик будущего благодарит за поездку и просит поставить оценку в Яндекс.Go 🤪. Если смотреть на горизонт лет пяти, то это не «все станут не нужны» и не «все будут писать промпты». Разработчик по умолчанию становится кем-то вроде engineering manager — человеком, который:
— понимает разработку глубоко
— ставит задачи
— контролирует исполнение
— больше думает про архитектуру
— понимает продуктовый и бизнесовый смысл

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

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

То есть ты начинаешь менеджить не людей, а процессы и агентов.

Видео докладов есть на 😉 YouTube и 😄 ВКвидео.

Расскажите в комментариях, начинаете ли вы уже мыслить в AI-first режиме, когда берётесь за очередную задачу?

P. S. Я стараюсь выпускать 1 пост в неделю. Вероятно, в ближайший месяц посты будут выходить пореже, потому что надо уделить время подключению к каналу дополнительных площадок. Спасибо, что остаётесь здесь, но соломку надо подстелить.

Почему из PG_TRY нельзя «просто продолжить»

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

После того как стало ясно, что мои ожидания от исключений в PostgreSQL не совпадают с реальностью, я полез разбираться глубже. Сначала, как это часто бывает, кажется, что всё объясняется одной деталью: в основе исключений лежит longjmp, а значит, это не привычный unwind стека, а резкий прыжок управления. Уже этого достаточно, чтобы насторожиться.

Но довольно быстро выясняется, что longjmp — лишь вершина айсберга.

Ключевая особенность PostgreSQL в том, что при ошибке с уровнем elevel >= ERROR меняется глобальное состояние процесса. Причём не в одном месте и не в виде какого-то аккуратного, локального эффекта, а сразу в нескольких важных точках. Сбрасывается текущий memory context, трогаются счётчики вроде HoldOffCount, меняются глобальные переменные. Всё это происходит ещё до того, как управление вообще попадёт в PG_CATCH.

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

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

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

Важно, что всё это — не баг и не недоработка. PostgreSQL — это СУБД с очень чётким приоритетом: при серьёзной ошибке как можно быстрее и безопаснее прекратить обработку запроса. Исключения здесь — это не инструмент управления потоком, а аварийная кнопка. Они отлично справляются со своей задачей, но эта задача совсем не та, которую мы привыкли ассоциировать со словом «исключения».

И именно поэтому мой главный вывод за всё это время не в том, что «нужно внимательнее читать документацию» или «глубже разбираться во внутренних деталях». Иногда на такие грабли просто невозможно не наступить, особенно когда API выглядит знакомо и дружелюбно. Проблема в другом: нейминг PG_TRY / PG_CATCH / PG_FINALLY в 2026 году создаёт ложное ощущение знакомой абстракции и почти неизбежно вводит в заблуждение.

Синтаксис выглядит правильно.
Ощущение — тоже.
А вот семантика у этого механизма совсем другая.

А у вас было ощущение, что интерфейс будто обещает одно, а под капотом делает совсем другое?

Почему 5 центов радуют больше $10

Компании часто объявляют, что стремятся распределять зарплаты справедливо. Я не раз ловил себя на мысли, что это вообще значит — «справедливо»? С чьей точки зрения?

Есть такая модель SCARF (David Rock). Она описывает пять социальных доменов, которые мозг автоматически читает как награду или угрозу: Status, Certainty, Autonomy, Relatedness, Fairness.
Это про низкоуровневую работу психики — то, что срабатывает быстро и неосознанно.

Так вот в SCARF fairness — это не «хорошо/плохо» и не «правильно/неправильно». Это механизм оценки правил обмена: по каким правилам делят ресурс, одинаковы ли они для всех и какую долю получил лично я.

Самое контринтуитивное здесь то, что fairness почти не смотрит на абсолютные числа. Он смотрит на пропорции. Это хорошо видно в эксперименте, который часто приводят в исследованиях про справедливость и вознаграждение [1].

Парам участников показывали простые ситуации распределения денег. Каждый раз было ясно:
* сколько денег всего в «общем котле»;
* сколько из них получает каждый участник.

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

Например, в одном варианте человеку доставалось 5 центов из 10 — ровно половина. В другом — 10 долларов из 50 — лишь пятая часть.

Рационально второй вариант очевидно выгоднее. Но субъективные оценки участников показывали обратное: первый вариант чаще воспринимался как более приятный и «правильный».

Это важный момент. Люди прекрасно понимали, что $10 — это больше, чем $0,05. Это не ошибка восприятия и не «глупость». Просто психика в этот момент оценивает не сумму, а долю и правила делёжки.

Грубо говоря, внутри возникает ощущение:
— «Мне дали честно»
или
— «Со мной поступили несправедливо».

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

Важный вывод из этого: fairness — это отдельный контур психики, который живёт по своим правилам. Он способен перетянуть эмоции против сухого расчёта и сделать нас недовольными там, где «по цифрам» всё должно было быть ок.

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

А пока вопрос: в каких бытовых ситуациях вы ловили себя на реакции «дело не в сумме, а в ощущении справедливости»?

[1] Tabibnia, Lieberman (2007), "Fairness and Cooperation Are Rewarding"

Когда справедливость мешает заработку

В прошлом посте я писал, что мозг часто оценивает не сумму, а долю. 5 центов из 10 могут ощущаться приятнее, чем $10 из $50 — потому что во втором случае делёжка выглядит нечестной.

Теперь перенесём это в зарплату 💵. Представьте ситуацию. Вы рассчитывали на +10%, а получили +12%. Отличные новости! Но через пару дней вы узнаёте, что коллега на точно такой же позиции получил +25%... 🤔 Внезапно внутри что-то меняется. Хотя ваша цифра не уменьшилась ни на рубль, появляется ощущение: «Со мной поступили хуже». Это и есть fairness из SCARF в действии: психика начинает оценивать не прирост в деньгах, а позицию в системе и правила распределения. Зарплата перестаёт быть просто деньгами, а превращается в сигнал: какое у меня место; одинаковы ли для всех правила распределения.

Чувство справедливости может загнать вас в несколько ловушек.

Ловушка №1 — обесценить своё.
После повышения ваша ситуация объективно стала лучше. Но вместо вопроса «Меня это устраивает?» включается вопрос «Почему у коллеги больше?». И радость подменяется досадой не из-за нехватки денег, а из-за сравнения 🤯

Ловушка №2 — отказаться от притязаний на большее.
Вы приходите обсуждать повышение, а вам отвечают: «Какая прибавка? Вон Вася перформит как ты, а получает меньше тебя. А у него трое детей и ипотека!». Вы сразу чувствуете несправедливость своих притязаний и капитулируете 😔 Либо разговор скатывается в спор о справедливости, вместо обсуждения вашей роли, ответственности и следующего шага.

👆Я однажды пал жертвой второй ловушки. Пришёл к руководителю со словами: «Я вижу, что мой совокупный доход за год снижается по сравнению с прошлым годом. Что мне сделать, чтобы он снова стал расти?» Услышав в ответ «Да у меня так же», я почувствовал, что человек и сам не рад, а тут ещё я со своими притязаниями. И разговор закончился. А зря...

Знание про fairness полезно не для того, чтобы «не чувствовать». Он всё равно срабатывает. Но важно уметь с ним работать. Вот что можно делать:

1. Фокусироваться на сумме, которая важна именно вам.
Есть вопрос: «Сколько мне нужно, чтобы меня устраивало?» И есть вопрос: «Как это относительно других?» В переговорах вам нужен первый.

2. Чужие цифры воспринимайте лишь как данные о рынке.
Если узнали про зарплату коллеги Пети — это не повод для зависти/обиды/возмущения. Это лишь данные: «В нашей компании можно зарабатывать вот столько. Надо узнать, как»

3. Возвращайте разговор к критериям.
На фразу «Вон у Васи ещё меньше» не нужно спорить о справедливости. Просто спокойно сказать: «Давай обсуждать мою роль и мой вклад. Какие критерии и результаты нужны, чтобы мой уровень оплаты был X?»

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

Напишите в комментариях, какая из двух ловушек вам более знакома?

Ненавижу покупать авиабилеты ✈️

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

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

Я хорошо помню, как лет 20 назад покупка билетов в Интернете была символом прогресса 🚀 Тогда вокруг меня многие ещё ездили за железнодорожными билетами на вокзал: стояли в очередях, толкались, ругались. А самые продвинутые люди с лёгкой гордостью говорили: «А я купил билет в интернете 😎».

Это ощущалось как победа технологии над хаосом. Быстрее. Проще. Удобнее.

А потом что-то сломалось. Все эти неочевидные формы, галочки, допродажи, ловушки в интерфейсе — это же не случайность. Наверняка за ними стоят A/B-тесты, метрики, продуктовые гипотезы. В таком варианте авиакомпания зарабатывает больше. То, что пассажиру при этом хуже, — уже побочный эффект.

Когда я только заходил в IT, мне нравилась мысль, что мы создаём технологии, которые делают жизнь людей проще. А правда оказалась в том, что современные Интернет-технологии часто делают жизнь сложнее — просто потому, что так выгоднее 😔

И мне кажется, с ИИ мы сейчас проживаем очень похожий момент.

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

Примерно так же когда-то ощущался Интернет!

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

Может быть, платная подписочная модель частично от этого защищает. А может, и нет. Кто знает, что будет через 10 лет.

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

P.S. С 27 апреля по 14 мая еду в США воспользоваться туристической визой, пока она ещё действует 🇺🇸. В программе Нью-Йорк, Ниагарский водопад, Лас-Вегас, Гранд-Каньон и Лос-Анджелес. Пишу сюда, потому что в прошлую поездку удалось познакомиться и интересно пообщаться с подписчиком канала. Вдруг и в этот раз это сообщение приведёт к интересной встрече.

А как вам кажется: сейчас золотое время ИИ?

Второй AI dev day в Яндексе

Первый был в июле 2025

Пришёл сегодня в московский Яндекс на встречу, где представители разных компаний: Яндекс, Авито, Озон, Сбер, Т-Банк, -- рассказывают о своём опыте внедрения AI в разработку.

В первом докладе сфоткал для вас слайд с ответом, уволят ли всех разработчиков

Вышла моя вторая хабростатья!

Весной прошлого года я в Питере выступал на System Kernel Meetup с рассказом о том, как применил C++ в коде Postgres-расширения в рамках своей первой задачи в R&D Pangolin.

Об отдельных частях того выступления я рассказывал у себя в постах:
— Самое сложное выступление ever
— А на C++ правда стало лучше?
— Как я подготовил некрутой доклад и почему это нормально

Полное выступление есть на 😉 YouTube и 🥰 Rutube. А для тех, кто предпочитает читать, а не смотреть, мы с коллегами из СберТеха переработали доклад в полноценную статью на Хабре.

Из статьи вы узнаете:
— плюсы и минусы кодой базы PostgreSQL
— что есть в PostgreSQL, но нет в С (если вы внимательно читаете мой канал, с этим пунктов вы уже знакомы 😉)
— ради чего пришлось добавлять C++ в мой код
— посмотрите примеры моего кода и сможете оставить комментарий «Я бы сделал лучше» 😄

Приглашаю к прочтению 📖

P.S. Это моя вторая публикация на Хабре. Первая была аж в 2017 о принципах создания и итогах запуска «Белого пояса по С++»!