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

Как готовиться к встречам 1 на 1, чтобы они не превратились в пустую формальность

Я выше рассказывал, что 28 февраля мы с Пашей Филоновым проводим практический воркшоп «Как проводить 1 на 1 с руководителем». Будем на тренироваться принимать фидбек от руководителя и давать ему свой. Если ваши 1 на 1 скатились в «Привет! Как дела? — Нормально. А у тебя? — Да тоже норм. Ну что, пошли работать?», приходите, чтобы научиться с помощью них двигать свою карьеру вперёд.

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

1. Ведите логи встреч

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

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

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

Когда я был тимлидом в Яндекс Еде, я много изучал, как правильно проводить такие встречи со стороны руководителя. И выработал принцип: на 1:1 нужно обсуждать только то, что нельзя обсудить ни на какой другой рабочей встрече.

Теперь, когда я сам иду к руководителю как сотрудник, я придерживаюсь того же правила. Никаких статус-репортов, никакого обсуждения текучки по проектам — для этого есть другие форматы.

3. Что именно включать в повестку?

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

✔️Свои переживания. Речь не о курсе доллара, а о рабочих ситуациях. Например, я боюсь, что выполню план, но не получу ожидаемый бонус. Или я где-то ошибся, релиз уехал на неделю, и я переживаю, что это испортит мою репутацию или приведет к депремированию.

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

✔️ Деньги. Встреча один на один — самое уместное место для таких разговоров.

4. Будьте в активной роли

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

5. Не бойтесь обсуждать коммуникацию

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

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

А как вы обычно готовитесь к таким разговорам? Или считаете, что это лишняя бюрократия?

«Пишите комментарии в коде, чтобы он был понятнее», — говорили они. Ок, принято:

    /* 再帰終了の判断 */
    IF cnt <= 1 THEN
        RETURN 0;
    END IF;

Из Open source расширения PostgreSQL pg_hint_plan. Раньше я не очень одобрял, что у нас в Pangolin нельзя писать комментарии на русском, теперь буду смотреть на это иначе. А то вдруг мой код в upstream попадёт 🙃

P.S. Текст комментария: «Определить завершение рекурсии»

Встречи 1 на 1 как рабочий инструмент, а не просто progress report

Я всё время забываю тут вовремя сообщать о мероприятиях, которые мы проводим в моём проекте «Выше вилки». Расскажу лучше поздно, чем никогда.

28 февраля, в субботу, в 19:00 мск мы с Пашей Филоновым проводим воркшоп «Как проводить встречи 1 на 1 с руководителем». Как и всё, что мы делаем в «Выше вилки», — это практическое мероприятие, где мы будем тренироваться делать две вещи:
— запрашивать, принимать и обрабатывать обратную связь от руководителя
— давать руководителю обратную связь о своём опыте работы с ним/ней

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

Воркшоп платный, завтра последний день скидок (ещё раз прошу прощения, что поздно пишу об этом здесь).

Что делать дальше:
— «Хочу! Иду! Куда платить?» — переходите сюда 💵
— «А можно поподробнее? Длительность? Программа?» — читайте этот пост в канале «Выше вилки» 🤔
— «Я не знаю, надо ли мне идти» — смотрите видео в канале «Выше вилки» 📹, если ваши встречи проходят, как в начале видео — вам надо 😃

Когда проявление личных границ мешает

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

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

Ситуация такая. Разработчик пишет в командном чате:

Ребята, я устал от того, что мои pull-request’ы висят без ревью по 4–5 дней. Я всё делаю по нашему процессу, прошу обратить внимание, но ничего не происходит. Мне приходится снова и снова писать ревьюерам в личку, и возникает ощущение, что я здесь не код пишу, а занимаюсь только борьбой за внимание.

Человек высказал переживание. Причём в очень корректной форме — через «я-сообщения», без обвинений и перехода на личности. Спустя время в том же чате отвечает тимлид:

Такие вопросы, пожалуйста, не поднимайте в командном чате. Давайте обсуждать это на еженедельных встречах, потому что у меня нет времени разбирать подобные проблемы в переписке. Что касается pull-request’ов автора — я посмотрел: последний был смёржен в тот же день. В целом система работает.

И на этом он выходит из дискуссии. Что произошло? Тимлид обозначил личные границы: он не готов обсуждать процесс в формате чата. Формально — корректно. Но если посмотреть глубже, получилось следующее.

Во-первых, он обратил внимание на частный случай («последний PR смёржен в тот же день») и тем самым обесценил поднятую проблему. Хотя разработчик говорил не о конкретном эпизоде, а о повторяющемся опыте.

Во-вторых, тимлид не показал, что взял проблему в работу. Хотя из сообщения очевидно, что в процессах команды есть проблема. Он просто сказал: «Я это обсуждать не готов». И вышел.

Было бы иначе, если бы его сообщение заканчивалось примерно так:

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

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

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

Тимлид мог ответить:

Мне сложно обсуждать такие вещи в формате чата. Я вижу проблему. Давайте разберём её на ближайшей встрече, и я к ней подготовлюсь.

В этом случае граница обозначена — и при этом проблема не обесценена.

А как вам поведение лида в данной ситуации?

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему 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"

Почему из 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 году создаёт ложное ощущение знакомой абстракции и почти неизбежно вводит в заблуждение.

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

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

Исключения в PostgreSQL — не всё то золото, что блестит

Когда я только погружался в кодовую базу PostgreSQL и Pangolin, меня по-настоящему порадовали две вещи. Во-первых, автоматическое управление памятью через memory contexts — мощный и при этом довольно изящный механизм. Во-вторых, наличие исключений. В тот момент это выглядело почти как подарок: С-код, но с привычными абстракциями, которые обычно ассоциируются с более высокоуровневыми языками.

При этом в сами исключения я долго не лез. Они просто существовали где-то рядом: встречались в коде, выглядели знакомо, и этого было достаточно. В PostgreSQL есть PG_TRY, PG_CATCH и PG_FINALLY, и на уровне синтаксиса всё это выглядит настолько похоже на исключения из Java или Python, что очень сложно не провести прямую аналогию. Я, по крайней мере, её провёл — и довольно надолго.

В голове сложилась простая и, как потом выяснилось, ложная модель. Если внутри PG_TRY происходит что-то плохое, управление передаётся в PG_CATCH, там мы это обрабатываем и дальше спокойно продолжаем работу. Ровно так, как это работает в большинстве языков программирования. Ничего экзотического, всё привычно.

С этой моделью я и подошёл к одной из рабочих задач. Мне нужно было делать бинарную десериализацию из области памяти, и в этом месте некорректные данные — не что-то из ряда вон выходящее, а вполне ожидаемый сценарий. Данные могут быть повреждены, устаревшими или просто не соответствовать формату, и код должен уметь это переживать. Для этого я написал небольшой фреймворк для бинарной (де)сериализации, опираясь именно на исключения: если данные некорректны — «бросаем исключение», клиентский код его ловит и идёт по альтернативной ветке, считая, что десериализация не удалась.

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

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

В этот момент стало понятно, что дело не в мелком баге и не в неудачном тесте. Проблема была глубже — в самой ментальной модели того, что такое исключения в PostgreSQL. И чем дальше я начинал разбираться, тем яснее становилось, что внешнее сходство с исключениями из Java или Python здесь крайне обманчиво.

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

А у вас было такое, что знакомая на вид абстракция вела себя совсем не так, как вы от неё ожидали?

Исключения в C коде PostgreSQL

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

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

Но в последнее время произошла перемена - всё больше времени в телефоне я общаюсь с ChatGPT. После выхода ChatGPT 5.2 с ним стало гораздо проще обсуждать свои дела: работу, личные цели и даже переживания. Например, я сделал проект, в который загрузил книгу "Джедайские техники", и в нём теперь обсуждаю, как мне справляться со всеми своими делами.

Есть много преимуществ в этом:
- полный фокус на теме; никакие сообщения в других чатах или сториз в ТГ не отвлекают
- я обсуждаю свои дела, а не читаю про чужие
- он общается со мной на том языке, который я хорошо понимаю. Мне, например, тяжело читать всяких успешных предпринимателей - слишком уж там много восторгов и восклицаний. Но я могу ту же мысль вытащить из GPT, где всё будет лаконично и по делу. И я её усвою лучше.

А какое самое популярное приложение у вас?

Как бороться со стрессом собеседования

Всем привет! Всех с началом рабочего года! Как ваше состояние: «никто так ни нуждается в отдыхе, как человек, вышедший из отпуска» или «мы бодры и веселы»?

Хочу начать этот год с темы борьбы со стрессом на собеседовании — она часто всплывает в комментариях. Действительно, на собеседовании есть большая психологическая нагрузка, которая часто лишает ясности ума и мешает показать себя наилучшим образом. У меня было минимум одно собеседование, которое я завалил, потому что не смог справиться с волнением.

Однако со временем я научился сохранять спокойствие на протяжении всего собеседования. В моём методе есть две части: стратегическая и тактическая.

Стратегическая часть

Она состоит в том, чтобы максимально снизить ценность любого отдельного собеседования. Сюда входят:
— проходить собеседования, когда у вас есть стабильная работа
— проходить собеседования, когда вы не находитесь в активном поиске работы (чуть отличается от предыдущего пункта)
— собеседоваться параллельно в 3+ компании
— пройти много-много собеседований

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

Тактическая часть

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

Для меня физические нагрузки работают безотказно.

Если во время собеседования я поймал себя на том, что меня трясёт, мне помогает пауза. Остановиться, закрыть глаза, сделать глубокий вдох и выдох. Это занимает 3-4 секунды, поэтому интервьюер может и не заметить. И после этого сразу сконцентрироваться на решаемой задаче. Я иногда начинаю сам себя оценивать в процессе решения задачи: «Не, это слишком слабая идея. Наверняка они хотят услышать что-то покруче», «Мда, что-то я медленно с этим вожусь. Это некруто, наверное, я проваливаюсь». Вот этот голос страшно мешает как следует себя проявить на интервью. Вдох/выдох помогают его заткнуть и снова сфокусироваться только на решаемой задаче.

А какие у вас методы? Делитесь в комментариях.