Жить лучше на те же деньги

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

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

Суть в том, что не так важны сами планы, сколько процесс их составления 💡 Он вызовет у вас вопросы «А чего я хочу?», «А сколько мне важно накопить?», «А какую зарплату я могу получить на рынке?» и т.д.

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

Приглашаю вас к просмотру:
😉 YouTube
😄 Вконтакте

P.S. Напишите свои инсайты в комментариях к видео на YouTube

Почему я выбрал C++

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

С С++ меня связали обстоятельства и особенности характера. В студенческие годы я много участвовал в олимпиадах по программированию, которые мы писал на Pascal. В какой-то момент Pascal на олимпиадах запретили, оставив только C, C++ и Java. Примерно в то же самое время я устроился на свою первую работу программистом, и там писали на C++. Очевидно, какой язык надо было изучить, чтобы подстрелить сразу двух зайцев 😁

После Pascal и поверхностного знакомства с С я просто тащился от С++ 😎 Шаблоны выгодно отличают C++ от Pascal тем, что позволяют переиспользовать код для разных типов, а код на С++ не выглядит так же убого и перегруженно как на C. Java ☕️ я тогда тоже изучил — в неё встроен класс BigInteger, который позволял на олимпиадах не писать свою длинную арифметику. Но Java меня всегда смущала избыточностью своего синтаксиса — приходилось гораздо большое стучать по кнопкам по сравнению с C++. Так что в начале моего пути программиста C++ правда был осознанным выбором из того, что тогда было популярно.

Во время одной из олимпиад я как-то в шутку сказал: «C++ — мой любимый язык, всегда на нём буду писать». Мне товарищи по команде часто её припоминали. Кто бы мог подумать, что фраза окажется пророческой 😃

Когда олимпиады ушли в прошлое, я продолжил погружаться в C++, чтобы лучше работать работу. Это было очень интересно. Уволившись с первой работы, чтобы сосредоточиться на диссертации, я уже очень-очень хорошо знал C++. В аспирантуре бывало, что я писал на C++ какие-то небольшие вспомогательные программки, которые любой нормальный программист сделает на Bash/Python/Go. Но язык настолько уже «сидел у меня в пальцах», что мне было проще нашарашить код на C++, чем разбираться, как это делается другими инструментами.

Неудивительно, что в Яндекс меня взяли как C++ разработчика 😉 До выхода в Яндекс я за 2 месяца освоил Python на приемлемом уровне, потому что меня предупредили, что им тоже придётся пользоваться.

🐍 К Python я всегда относился холодно, хлебнув горюшка отладки большой питоня̀чей кодовой базы 😭 Да, он хорош, потому что на нём можно быстро наваять прототип, но с ростом кодовой базы отсутствие статической типизации сильно бьёт по голове. Но в Python я ненастоящий сварщик — мне как-то сделали оффер на Middle Python developer, так что мне есть куда в нём расти.

В Яндексе я всё время был связан с C++: сначала я 5 лет был С++ разработчиком в Безопасном Поиске, потом делал курсы по С++. И даже в Яндекс Еду меня взяли, именно потому что я не только могу на C++ писать, но и могу хорошо ему обучать.

Илья, но почему ты на досуге не изучил Go, Rust, etc.?

Из-за особенностей характера. Я так устроен, что обычно копаю вглубь. Например, я очень неплохо катаюсь на горных лыжах ⛷ — прошёл 5 обучающих курсов по ним. Но я ни разу в жизни не становился на сноуборд. В 7 лет родители отдали меня в баскетбол 🏀 — я до сих пор стараюсь в нём совершенствоваться, и это единственный вид спорта, которым я занимался всерьёз. Вот так и в C++ я всегда видел, что ещё мне хочется изучить, чтобы писать код ещё лучше.

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

Я, в некотором смысле, заложник своей экспертизы. Меня зовут только в места, связанные с C/C++. Это мотивирует изучать С++ ещё глубже, а мотивации изучать тот же Go я сейчас не чувствую. При этом в мой летне-осенний цикл собеседований я собеседовался в три компании на Go-разработчика. В итоге одни предложили мало денег, вторые выбрали другого кандидата, а третьи на ходу переобулись, решив, что им всё-таки нужен человек с 2+ годами опыта на Go. Так что я был в шаге от того, чтобы погрузиться в мир Go, но не вышло 😎

Type `struct List` should match type `struct List`

Ошибка компиляции с такой формулировкой отобрала у меня 2 дня на этой неделе 🤯

Морозным апрельским утром 😆 я вникал в новую рабочую задачу, когда коллега написал, что моя фича не собирается в CI. Странно — у меня такая же нога и не болит я же проверял, что там всё успешно собирается 🤔 Это та самая фича, о которой я рассказывал в предыдущих постах. В ней я пробую применять C++ в Postgres. Исходно была такая ошибка на этапе линковки:

error: type of 'FindMatchingLine' does not match original declasration [-Werror=lto-type-mismatch]
ConfigLine *FindMatchingLine(List *config_rules, const char* user_name, Port *port);

note: 'FindMatchingLine' was previously declared here
ConfigLine *FindMatchingLine(List *config_rules, const char* user_name, Port *port);
note: code may be misoptimized unless -fno-strict-aliasing is used

Попробуйте найти отличия в двух объявлениях выше (спойлер: их нет). Сначала я долго пытался понять, как так вышло, что одинаковые декларации отличаются? 🧐 Может, где-то русская "с" затесалась? Может, какие-то проблемы с порядком include'ов? И почему вообще у коллеги это не собирается, когда у меня в CI успешная сборка? 🤯

На последний вопрос ответить удалось быстро: у меня в CI успешно собрался debug, а у коллеги не собирается release 👌

Дальше моё внимание привлёк флаг компиляции [-Werror=lto-type-mismatch]. Я пошёл гуглить, что это такое. Стало понятно, что у нас в релизной сборке применяется LTO — link time optimization. В дебаге этого нет. И именно во время выполнения LTO linker почему-то видит две разные функции.

Я долгое время пребывал в недоумении. Обложился Гуглом, Чатом ГПТ, ГигаЧатом и стал копать. Кстати, очень интересный опыт: я с ChatGPT общался, как будто это коллега сидит рядом, и мы вдвоём дебажим. И ChatGPT настаивал, что проблема именно в типе List. Сперва я относился к этому скептически, но потом решил проверить. Мне удалось сделать минимальный пример, компоновка которого падала с ошибкой из заголовка поста. ChatGPT был прав! Осталось понять, что не так с типом List.

Уже не помню, как я к этому пришёл, но проблема была вызвана тем, что List — это структура, которая содержит flexible array member:
typedef struct List
{
NodeTag type;
int length;
int max_length;
ListCell *elements;
/* We may allocate some cells along with the List header: */
ListCell initial_elements[FLEXIBLE_ARRAY_MEMBER];
} List;

В языке С flexible array member используется, чтобы одной аллокацией выделять произвольный объём памяти под структуру и данные переменной длины в конце неё. (Занятно, что в C++ такая конструкция запрещена).

И вот тут паззл у меня сложился 💡:
— я использую типы Postgres в коде на С++ (в частности List)
— flexible array member успешно компилируется в С++, когда подключаешь Postgres-структуры через extern "C"
— компоновка с включённым LTO не срабатывает, когда в C++ используется тип с flexible array member 🤯 «Обычные» структуры такой проблемы не вызывают.

Дальше стояла задача это починить. В Интернете советуют отключать LTO в таких ситуациях. Советы ChatGPT и GigaChat оказались неверными. Мне долго не хотелось отключать LTO — это же оптимизация, в конце концов. Но потом я понял, что она хороша для CPU-bound кода, а мой таким не является. Поэтому я всё-таки отключил LTO для сборки только своей фичи (а не проекта в целом). И CI-сборка в релизе, наконец, успешно прошла ✅

Подведём итоги:
👉 GigaChat и ChatGPT оказались классными помощниками в расследовании, но все их исправления оказались непригодными
👉 если видите ошибку на этапе линковки о том, что типы с одинаковыми названиями не совпадают, проблема может быть в link time optimization и flexible array member
👉 на практике бывает полезнее отключить оптимизацию и решить задачу сегодня, чем вложить ещё несколько дней в раскопки, как добиться сборки с сохранением оптимизации

Как вам такие истории из моей практики? Видите в них пользу?

One function to rule them all, часть 2/2

В предыдущем посте я показал несколько разных типов в PostgreSQL: Relation, MemoryContext, SysScanDesc и т.д. Их все объединяет то, что они являются указателями на какие-то структуры: typedef struct RelationData* Relation. Итак, у меня есть указатели на разные типы, каждый со своей функцией очистки, и я в C++ хочу избежать их ручного освобождения. Кажется, это задача для unique_ptr'а с кастомным deleter'ом 💡 Пишем такое:
// C++17
template
std::unique_ptr guard_by_deleter(
T *p,
Deleter d,
std::enable_if_t<
std::is_invocable_v, void*> = nullptr)
{
return {p, d};
}

Давайте перепишем первый пример из предыдущего поста на использование guard_by_deleter:
Oid GenerateNewOidForPgAuthid(const CatCache *cache)
{
std::unique_ptr relation = guard_by_deleter(
table_open(relation_id, AccessShareLock),
[](Relation r) { table_close(r, AccessShareLock); });

if (IndexScanOK(cache, NULL)) {
// Таблица закроется автоматически, без явных вызовов
return GetNewOidWithIndex(relation.get(), ...);
}

std::unique_ptr scan = guard_by_deleter(
systable_beginscan(relation.get(), ...), systable_endscan);

for (HeapTuple tuple; (tuple = systable_getnext(scan.get())) != NULL;) {
...
}
...
// scan и relation очистятся автоматически
return ...;
}

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

Улучшим второй пример из первого поста. Для этого напишем небольшой макрос:
#define UNDER_MEMORY_CONTEXT(ctx) \
if (auto g = guard_by_deleter( \
MemoryContextSwitchTo(ctx), \
MemoryContextSwitchTo); \
true)

Тогда, если я хочу выполнить какие-то операции в глобальном контексте, я просто делаю так:
MemoryContext global_context;

void Foo() {
UNDER_MEMORY_CONTEXT(global_context) {
// Do something
if (failure()) return;
}
...
}

Читается проще, пишется быстрее — красота. Итого, с помощью одной простой функции guard_by_deleter мы сделали три разные вещи:
— закрыли таблицу
— завершили сканирование таблицы
— вернули прежний memory context

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

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

One function to rule them all, часть 1/2

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

В PostgreSQL есть куча самых разных ресурсов: память, таблицы, файлы, контексты памяти, регулярные выражения и т.д. Для создания и освобождения каждого из них используются свои функции: palloc/pfree для памяти, table_open/table_close для таблиц, pg_regcomp/pg_regfree для регулярных выражений и т.д. Как и в любом проекте на C, если вы в функции создали какой-то ресурс, надо обязательно освободить его, на любом пути выхода из функции. В C это обычно решается либо с помощью goto на метку с очисткой всех ресурсов, либо вызовом очищающх функций перед каждым return'ом. В PostgreSQL, по ощущениям, второй подход гораздо более распространён. Например,
static Oid GenerateNewOidForPgAuthid(const CatCache *cache) {
// Открыли таблицу
Relation relation = table_open(cache->cc_reloid, AccessShareLock);

if (IndexScanOK(cache, NULL)) {
Oid result = GetNewOidWithIndex(relation, ...);
// Не забыли закрыть таблицу
table_close(relation, AccessShareLock);
return result;
}

// Создали объект сканирования таблицы
SysScanDesc scan = systable_beginscan(relation, ...);
// ...
for (HeapTuple tuple; (tuple = systable_getnext(scan)) != NULL;) {
...
}
systable_endscan(scan); // Удалили данные сканирования таблицы
table_close(relation, AccessShareLock); // Закрыли таблицу
...
}

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

Другой пример, мой «любимый» — переключение memory context'а. Сейчас не так важно, что это такое (надеюсь, у меня дойдут руки рассказать про эту интересную технологию в Postgres):
MemoryContext global_context;

void Foo() {
// Будем выполнять часть операций с памятью в контексте global_context
MemoryContext old_ctx = MemoryContextSwitchTo(global_context);
...
if (failure()) {
// Возвращаем контекст old_ctx
MemoryContextSwitchTo(old_ctx);
return;
}
...
MemoryContextSwitchTo(old_ctx);
}

Проблемы те же: приходится писать много кода и надо внимательно следить, в каком контексте ты выделяешь память. Чтобы мне выполнить одну операцию в другом контексте, мне надо:
— придумать имя переменной типа MemoryContext и объявить её
— присвоить ей результат вызова MemoryContextSwitchTo()
— после выполнения полезных действий вернуть прежний контекст ещё одним вызовом MemoryContextSwitchTo()

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

Пару недель назад я решил в качестве эксперимента внедрить C++ в один достаточно большой модуль Pangolin'а. Как я сказал выше, мне удалось сделать одну конструкцию, которая позволила мне избежать перечисленных выше проблем в большом количестве кейсов.

В следующем посте расскажу, что я сделал.

«Обязательно ли быть активным в онлайне, чтобы стать успешным в карьере?»

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

20 марта я участвовал как спикер во встрече Грейд Клуба Яндекс Практикума. Был одним из пяти приглашённых экспертов, кому наряду с карьерой удаётся вести ценные телеграм-каналы. Помимо меня во встрече участвовали:
— Галя Лебедова — ведёт классный канал про управление людьми Карьерные шахматы (я подписан 😉)
— Елена Тупикова — ex-CPO Яндекс Еды, когда-то мы сидели за соседними столами 😃 — Стратегия, культура, продукт
▪️Екатерина Смоленцева, руководитель IT найма в Яндекс.Маркете. Канал-заметка kattsmol
▪️Евгений Вольнов, директор по контенту в HeadHunter. The Future Of Work

Встреча проходила в арт-пространстве Cube Moscow. Оно располагается на -2 этаже отеля Ritz Carlton на Тверской улице в Москве. Локация местами красивая, а местами шикарная 🕺

В начале мероприятия прошёл круглый стол, на котором мы обсудили, как совмещать ведение соцсетей с работой, помогает это или мешает, как к блогерству относятся работодатели, как понять, сто̀ит ли мне начинать вести канал. Мои тезисы были такие:
☝️ необходимо получать удовольствие от ведения канала; на одной силе воли и «надо» долго не протянешь
✌️ мне канал помогает в карьере: благодаря ему я поработал в HFT, получил опыт работы консультантом; кроме того, когда пишу посты, лучше понимаю темы, которые поднимаю
🤟 совмещать работу с блогерством сложно; см. пункт 1 — важно получать от этого удовольствие

Главным итогом встречи для меня стало то, что я недоиспользую нейросети в блогерстве. Я почти не применяю ChatGPT для этого канала. Некоторые коллеги по цеху, оказывается, используют его и для формирования контент-плана, и для анализа качества контента, и для идей новых рубрик. Это сильно замотивировало меня углубиться в изучение более эффективного использования нейросетей:
— Уже прочитал Хабро-статью "Prompt engineering 101"
— Посмотрел выступления, которые упомянуты в этой статье
— Разобрался, наконец, что за buzz word RAG
— Стал читать бесплатный курс «Эффективное использование ChatGPT»

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

То пусто, то густо

Я давненько не был на оффлайн мероприятиях: конференциях, митапах и подобном. Наверное, с самой C++ Zero Cost conf в июле 2024 😳

И вдруг на этой неделе буду участвовать сразу в трёх:
👉 20 и 21 марта буду вести открытие и закрытие оффлайн части C++ Russia в Москве. Ну и оба дня проведу на конференции
👉 20 же марта вечером буду участвовать в оффлайн встрече Грейд клуба Яндекс Практикума как спикер на тему "В эпоху социальных сетей: обязательно ли быть активным в онлайне, чтобы быть успешным в карьере?" Буду рассказывать, как веду этот канал и помогает ли он а карьере
👉 наконец, 19 марта будем вместе с Ваней Ходором записывать подкаст "Достаточно ли качать харды, чтобы расти в доходе в IT?" Это для проекта "Выше вилки", хочу почелленджить своё убеждение, что надо самому постоянно заниматься своим доходом, иначе о тебе никто не позаботится.

Пожелайте мне со всем этим справиться 🤗

Приходите на весенний поток "Выше вилки"

У нас было уже 15 потоков тренинга по переговорам о зарплате в IT "Выше вилки".

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

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

На следующий поток мы существенно расширим экспертизу, которую будем передавать участникам. Напомню, тренинг "Выше вилки" состоит из трёх модулей:
☝️ Повышение оффера при трудоустройстве
✌️ Повышение зарплаты без смены работы
🤟 Повышение компенсации при увольнении

И на каждый из этих модулей мы пригласили эксперта со специализацией:
✅ Настя Авдонина возвращается как эксперт модуля про офферы. Она работает в IT рекрутменте, и переговоры об оффере - это её ежедневная практика
✅ Андрей Смирнов aka "золотой голос российского IT" будет экспертом на блоке о переговорах с начальством о повышении зарплаты. Андрей много лет руководит сотнями людей в X5 tech, и обсуждать с ними их зарплату - его регулярная практика
✅ На блоке про увольнения экспертом будет Виталий Шароватов - вероятно, главный эксперт по увольнениям во всём российском IT.

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

Если чувствуете, что вам есть куда расти в том, как вы договариваетесь о своей зарплате, приходите. Тренинг стартует 24 марта.

Все подробности - на сайте

Upd. 18 марта в 20:00 мск проведём с Пашей Филоновым онлайн-встречу "7 аргументов, чтобы поднять зарплату на текущем месте работы". Регистрируйтесь в боте @AboveTheRangeBot и приходите, если видите для себя пользу в изучении темы зарплатных переговоров.

Стендапы: форма та же, цель другая

Продолжение предыдущего поста...

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

Очень круто, подумал я, — фокус на результате, всё как в умных книгах и мотивационных докладах о личной эффективности! Походив неделю на такие стендапы, я понял, что никто не соблюдает эту форму, скатившись в обычные «я делал свою задачу TASK-123», а главное — на 15-минутную встречу приходит от 15 до 28 человек. Какой там knowledge sharing и spreading ideas, когда вместе собирались разработчики, тестировщики, release manager'ы, и каждый быстро выпаливал короткий доклад на своём птичьем языке?!

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

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

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

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

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

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

Когда я недолго был в HFT, у нас не было стендапов. Наконец, сейчас в СберТехе они есть. Начальник говорит, что их цель — своевременно узнавать, когда что-то идёт не так. И это первые за много лет стендапы, которые меня не напрягают:
✅ небольшой smalltalk
✅ честный обмен новостями
✅ если кто-то высказал переживания, дали ему/ей поддержки и пошли работать.

Никакого лишнего давления, ощущения недоверия и попыток заклеймить лентяев позором ☺️

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

А какое ваше отношение к ежедневным стендапам?

Зачем вы проводите стендап?

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

📌 Оригинально их провозгласил Agile как способ делиться знаниями о проекте, чтобы каждый участник команды был в курсе, что творится у коллег, и мог делиться своими идеями и получать быстрый фидбек. Прекрасная мотивация! «Knowledge sharing», «spreading ideas», «collaboration» и прочие мотивирующие buzz word'ы 🤔

Я даже видел, как это работало на практике. Была в Яндексе команда из трёх разработчиков, которые не менее 2-х лет работали над одним проектом. И они решили проводить стендапы. По их личному мнению, это улучшило их производительность, потому что «knowledge sharing», «spreading ideas» и вот это вот всё действительно происходили.

Волей судьбы спустя время я присоединился к этой команде, и она в целом доросла до 7 человек. И проектов, которые мы делали, стало не один, а три. Мы где-то полгода по инерции вели стендапы, но потом отказались от них, заменив еженедельными часовыми встречами. Причин отмены было две:
🔻 не происходил обмен знаниями: Вася рассказывает, как делает огромную задачу в проекте А, Илья рассказывает, как делает огромную задачу в проекте Б, — они ничего не знают про задачи друг друга, и ежедневные 30-секундные доклады не помогают въехать
🔻 не происходил обмен идеями, потому что на стендапе нельзя было задавать вопросы: нас стало семеро, стендап с трудом помещался в 10 минут, а вопросы порождали долгие обсуждения, которые заставляли бо̀льшую часть команды стоять и тратить время впустую.

Вопросы всегда пресекались фразой «обсудите после стендапа», но обычно мы после него просто возвращались к своим задачам.

Спустя пару лет я оказался в другой команде, где тоже были стендапы… но с неожиданным поворотом. 😏

👉 Что это был за поворот? Об этом во второй части!

Никогда не говорите этого на стендапе!

Я осознал, что с 2019 года почти каждый рабочий день участвую в стендапах: они были в Яндекс Браузере, Яндексе Еде, есть сейчас в СберТехе. Мне кажется, за эти годы я собрал кучу примеров, как сто‌ит и как не сто‌ит вести себя на стендапе. А также примеры того, как их сто‌ит проводить, а когда лучше занять время коллег чем-то более полезным.

Сегодня хочу поделиться одним таким антипаттерном.

Я абсолютно уверен, что говорить на стендапе "Я на выходных сделал Х" очень вредно.

Дело именно в выходных. Давайте разберём пару ситуаций:

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

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

2. Вы — руководитель программистов, и рассказываете, как работали на выходных. Такой посыл может отбить у сотрудников желание расти в руководителя, потому что придётся работать на выходных. Кроме того, вы как руководитель являетесь образцом поведения для сотрудников. Что делаете вы, будут делать и они.

Есть ещё третий вариант. Вы — руководитель руководителей руководителей. Тогда говорите сколько угодно о работе в выходные — вы и ваши подчинённые хорошо друг друга понимаете 😂

Мне в этом отношении нравится позиция Алексея Шаграева (ex-Яндекс, ex-Google). В одном из видео, которое я не смог найти, он очень здорово сказал: "Я люблю много и сильно фигачить. По выходным, по ночам. Мне это нравится. Но я делаю всё, чтобы мои подчинённые этого не видели".

Я тоже иногда что-то делаю на выходных или ночью, потому что я много во что вовлечён, и невсегда удаётся всё успеть сделать в рабочее время. Но нигде это не афиширую и на ежедневных встречах просто говорю: «Я сделал Х». А когда и как — это уже моё дело.

Что вы думаете о рассказах про работу в нерабочее время?

Получите оффер в YADRO всего за 3 дня! 🚀

Компания-лидер инженерной индустрии в России YADRO приглашает C++ Software Engineer на SPRINT OFFER.

Команда Телеком ждёт кандидатов сразу в два направления: Telecom Platform и Разработка стека протоколов LTE/GSM для базовых станций.

Если вам интересно принять участие в разработке первых российский базовых станций стандартов GSM/LTE — присоединяйтесь к команде Телеком. Вы будете с нуля создавать решения для беспроводных мобильных сетей и сопутствующих услуг: от исследований и прототипирования до вывода в коммерческое использование.

Большую часть кода разработчики пишут на C++. В зависимости от компонента применяют как последние «фишки» С++20, так и занимаются низкоуровневой оптимизацией кода для повышения производительности.

🔵 Читайте подробности на сайте и оставляйте заявку до 9 марта → по ссылке.

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

Базовые навыки программиста никогда не устаревают

На прошедшей неделе пришлось много заниматься отладкой. Продолжаю добавлять новую функциональность в Pangolin и покрывать её тестами 🧪 Тесты помогают находить баги быстро — почти сразу после их совершения 🕐 Правда иногда мне приходится вложить не один и не два часа в отладку, чтобы понять, что идёт не так.

Столкнулся с интересной проблемой. Когда к СУБД подключается новый клиент (например, консольный psql), она с помощью fork порождает новый процесс для обработки его запросов. Нельзя просто взять и запустить отладочную сессию в VS Code, чтобы подключиться к этому новому процессу — его PID становится известен только в runtime в середине выполнения теста.

Если я не прав, и вы знаете, как это сделать в VS Code, расскажите, пожалуйста, в комментариях 💬

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

Мне рассказали лайфхак, как всё-таки подключаться отладчиком к порождённому процессу:
1) настраиваешь в VS Code в launch.json debug-конфигурацию, которая подключает GDB к переданному PID'у
2) вставляешь в интересующем месте в коде sleep(20)
3) когда тест выполняется, с помощью ps aux находишь PID порождённого процесса
4) передаёшь этот PID в конфигурацию с шага 1, пока процесс спит на sleep
...
N) PROFIT!

Но есть проблема — почему-то после подключения к процессу отладчик VS Code выдаёт ошибку "Segmentation fault" и сразу завершает debug-сессию. Когда я с таким сталкивался, я расстраивался и переходил на отладку через консольный вывод.

Но потом вдруг решил попробовать подключаться к процессу просто с помощью gdb -p в консоли. И это ... работает как часы! 💡 Если его ещё запускать с параметром -x, который позволяет при запуске сразу расставить все нужные breakpoint'ы, то получается быстро и удобно!

Конечно, консольный GDB — не самая удобная вещь, но зато работает! Я его неплохо освоил ещё в своей самой первой команде в Яндексе — в онлайн-антироботе. У нас тогда бинарник часто сваливался в корку, и приходилось часами в них ковыряться, чтобы понять, что пошло не так. Я всегда был поклонником графических отладчиков и поначалу долго саботировал погружение в GDB. Но мой тогдашний руководитель сказал: «Удели время, вникни — оно того сто̀ит» Как в воду глядел.

☝️ И даже сейчас, в 2025 году, консольный GDB порой оказывается незаменим. Отладка с помощью GDB — это базовый навык программиста. Графические отладчики — это, своего рода, синтаксический сахар. И этот базовый навык не теряет актуальности.

А как у вас с GDB? Как считаете, если ли более простой способ отлаживаться, чем то, что описал я?

Когда адекватно воспринял обратную связь

Со мной произошла удивительная история, которой я, наконец, могу с вами поделиться.

Осенью 2023 года я рассказывал про свой опыт собеседования в HFT-компанию. Я дал ей вымышленное название "5 ns". Если кратко, я решил все задачи на всех секциях, но мне отказали, дав очень невнятный фидбек. И я об этом подробно рассказал в канале.

Спустя почти 9 месяцев, летом 2024 мне написали из компании "5 ns" с неожиданным предложением 💡 Они сказали, что согласны с фидбеком, который я дал в своём канале, и предлагают мне в роли консультанта поработать над улучшением их процессов 😳 Цель была — сделать так, чтобы кандидаты, получившие отказ, понимали, над чем надо поработать, чтобы в следующий раз собеседование прошло успешно.

Я был тронут таким предложением и взялся за эту работу 👍 Что я сделал:
— изучил все задачи, которые дают кандидатам на интервью
— провёл несколько встреч с лида̀ми, чтобы понять, какие навыки кандидатов для них необходимы, а что они готовы развивать уже после найма
— отсмотрел фидбеки, которые компания давала кандидатам, получившим отказ (всё анонимно, без доступа к персональным данным кандидатов)
— проанализировал логи интервью, которые ведут интервьюеры, чтобы понять, на что они обращают внимание

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

Мне удалось связать в единую систему 3 вещи:
1) навыки, которые лиды̀ ищут в кандидатах
2) фидбек интервьюера на выступление кандидата
3) обратная связь кандидату, которому решили отказать

Недавно "5 ns" сообщили мне, что внедрили мои рекомендации в свои процессы! Работа, наконец, доехала до продакшн, поэтому можно о ней и рассказать 😊

Я очень рад, что "5 ns" увидели возможность для улучшения в моей критике. Мне было очень интересно работать с ними над этим проектом, и я рад, что мои идеи дошли до внедрения.

Переработки в Яндексе 🥵

Про Яндекс ужасы рассказывают про переработки, много нужно перерабатывать, правда или нет?
Подобные вопросы периодически приходят ко мне в личку. Человек 8 написали в разное время уже. Поделюсь своим опытом здесь, чтобы потом просто отвечать этим постом 😉

Давайте начнём с того, что такое переработка. Мы как-то разбирали эту тему с Пашей Филоновым в нашем канале «Выше вилки». У этого слова есть негативная коннотация, и она, на мой взгляд, состоит в том, что ты в принципе не можешь выдавать приемлемый уровень производительности за 40 часов в неделю. И ты вынужден, безо всякого личного желания, уделять работе 50+ часов в неделю.

Если тебя штырит, ты погружен в задачу, думаешь о ней и днём, и ночью и растворяешься в ней — это не переработка, это состояние потока. И вполне ок уделять ему и 40, и 50, и 60 часов в неделю (IMHO).

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

У этого есть хорошее и плохое последствия. Хорошее — по большому счёту, я не знаю, что такое профессиональное выгорание 😃. Плохое — я очень часто чувствовал себя чужим среди своих 😔. Дело в том, что в Яндексе переработки всячески восхваляются (моё личное мнение, может отличаться от позиции компании):
— Объявили о запуске чего-то нового и крутого — обязательно отметили, что команда последние 3 месяца «работала без выходных», «жила в офисе», «отменила все свои отпуска» или, в крайнем случае, «работала по 16 часов в сутки»
— В очередной дискуссии о непрозрачности процесса ревью какой-нибудь руководитель нет-нет, да и ляпнет «я своим поставил повышенные, потому что они перерабатывали»
— Начальники, обедающие прямо в переговорке во время встречи, «потому что календарь забит, нет времени сходить пообедать»
— Какой-нибудь очередной нанятый топ-менеджер в приветственном видео говорит: «Я всегда учил своего сына: "Невозможно добиться больших результатов, работая по 8 часов в день"».

Глядя на это всё, я чувствовал себя неправильным, ненастоящим яндексоидом. «Вот люди... вот они вкладываются, вот они и правда меняют мир. А я так... не выкладываюсь 😰».

При этом я 1,5 года делал «Пояса по С++» по выходным, до и после работы. Код, из которого потом родился мой доклад на C++ Zero Cost Conf, я писал ночью, потому что не мог заснуть из-за переполнявших меня идей. То есть бывало, я прям много работал, но я не считаю это переработкой — мне просто было в кайф 😎

Отвечая на вопрос в начале поста, скажу так.
1️⃣ Если вы достаточно толстокожи, чтобы не пускать внутрь постоянно витающий вокруг флёр «ЕБШ 24/7», если можете выстроить личные границы, вы не будете перерабатывать.
2️⃣ Если вы попадёте на своё место; будете увлечены тем, что делаете, и лично вам будет важно сделать хорошо, вы периодически будете работать больше 40 часов в неделю. Но вам будет в кайф! 🔥

Кто из Яндекса, сходится мой опыт с вашим?

Где учиться, расти и не застрять на месте? 🧑‍💻

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

1️⃣ Solvery — канал для бэкенд-разработчиков, которые хотят расти в карьере, разбираться в трендах и уверенно проходить собеседования. Здесь опытные менторы из разных компаний рассказывают, как выбрать лучший язык программирования для Backend, что делать на первых этапах карьеры и как не наступить на грабли? А если ищете работу, то вот инструкция по выживанию. Плюс также бонус 30+ моковых собеседований для практики, с которыми можно ознакомиться, чтобы стать еще чуточку увереннее в себе.

2️⃣ Никита Ульшин про IT — канал от опытного руководителя, управлявшего командами от 5 до 35 человек в разных компаниях. Никита в своём блоге рассказывает о создании сильных команд, построении отношений с людьми и профессиональном росте. Никита расскажет: про развитие сотрудников через неопределённость, делает обзоры книг по управлению и саморазвитию. Скорее переходите и изучайте множество интересных постов и книг.

3️⃣ Machine Learning — топовый канал, где собрана вся база по ИИ и машинному обучению. Здесь Senior разработчик AI-алгоритмов и автономных агентов, разбирает внутренности алгоритмов, редкую литературу и код самых интересных ИИ проектов. Уже ни для кого, не секрет, что в 2025 году ИИ выйдет на совершенно новый уровень тот, кто не успеет за прогрессом - отстанет, а кто разберется - сорвет куш. Подписывайтесь, чтобы ничего не пропустить.

📌 Подписывайтесь на ребят и черпайте для себя лучшие практики

А как у вас проходит демо?

У нас на работе есть отличная практика — устраивать демо своей работы для коллег. Это не просто показ кода, а настоящий мастер-класс! 💪 Вчера я как раз проводил такое демо, и оно привело к неожиданным результатам. 😲

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

Моё первое предложение было продемонстрировать код тестов и показать, что они работают. Но лид сказал, что по правилам нужно выполнять команды в консоли прямо во время демо, чтобы не только разработчики, но и администраторы БД понимали, что я сделал. 😒

Ну ладно, начал готовиться. Всё локально настроил, запустил — не работает 😳 Разбирался, разбирался — понял, что допустил опечатку в одном из конфигов. 🤦‍♂️

Настроил другой сценарий — тоже не работает. 🤔 Стал разбираться — понял, что не предусмотрел один сценарий, сделал доработку. 💡

Настроил третий сценарий — опять не работает 🤯 Оказалось, вылез баг, который я не отловил автотестами. 🛠 Ну и так далее... Только один из пяти сценариев заработал сразу. 😞

По итогам подготовки:
— Вся рабочая неделя ушла на подготовку к демо. 📅
— Сделал одну доработку функциональности. 🔧
— Исправил два бага. 🎯
— Доработал тесты, добавив сценарии, которые возникли только во время подготовки. 📜

Главный результат — я гораздо лучше стал понимать сложность эксплуатации своей фичи, позанимавшись ручной настройкой всего и вся. 🧠

Необычность этой практики для меня в том, что она позволяет собрать фидбек с коллег, увидев их взгляд на вещи. 👀 Раньше я привык к режиму: «Сделал фичу, выкатил в прод, проверил, что работает; побежал дальше, потому что нужно больше перформить». 🏃‍♂️ По старой памяти, было тревожно целую неделю готовиться к демо — в голову лезли мысли: «А достаточно ли я перформлю?» 🤔

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

А как вы проводите демо и что необычного в вашей практике?

А у вас тоже есть шпаргалка по perf?

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

Однако есть инструменты, которыми объективно тяжело пользоваться. Для меня, например, таким является профайлер в perf. У него так много опций и возможностей, что я каждый раз заново изучаю, с какими параметрами его надо запустить, чтобы построить flame graph тормозящей программы.

Я знаю, что у многих просто есть шпаргалка, как его запускать, и они просто копируют оттуда команды в консоль 😁

На днях в мире стало одним профайлером больше — Яндекс выложил в Open Source свою систему непрерывного профилирования Perforator. Во всех подробностях они рассказывают о нём у себя на Хабре.

Мне очень понравилось, что одной командой sudo ./perforator record --serve :1234 -- ./main можно прогнать профайлер и сразу получить flame graph у себя в браузере. Это удобно.

В статье очень много технических деталей и подробностей того, как профайлеры работают под капотом — прочитал с интересом.

Perforator поддерживает программы на нативных языках (C++, C, Go, Rust), а также экспериментально Python и Java. Он используется внутри Яндекса уже довольно давно для анализа производительности распределённых бекендов (ещё когда я там работал, я встречал это название 😃). Поэтому Perforator умеет работать не только локально, но и в k8s.

Исходный код доступен под лицензией MIT (и GPL — для eBPF-программ) и запускается под x86-64 Linux.

Визуализация — здесь.

Переходите в гитхаб и попробуйте Perforator в деле

API курильщика или «Хорошо, что я не психопат»

СУБД Pangolin, в которой я теперь работаю, основана на open-source'ном код PostgreSQL. А значит, наша кодовая база является бесконечным источником говнокода поучительных примеров 😁

Я вчера два часа жизни потратил на отлавливание проезда по памяти. Написал код, который создаёт новый кортеж для последующей вставки его в таблицу. И там segfault 💣 А Postgres — это всякие межпроцессные взаимодействия, синхронизация через общую память и прочие места, где легко накосячить. Ну вот я копал в эту сторону, обложившись GDB, breakpoint'ами и отладочным выводом в логи.

Какого же было моё возмущение, когда я нашёл причину 😬🤬

В Postgres есть довольно простая функция создания нового кортежа — heap_form_tuple:
HeapTuple heap_form_tuple(
TupleDesc tupleDescriptor,
const Datum *values,
const bool *isnull);

Она принимает некое описание кортежа и два массива:
- значения его колонок
- булевский массив, который задаёт, какие колонки имеют значение NULL
Размер этих массивов записан в tupleDescriptor.

А ещё для удобства есть константы, которые задают номера колонок системных таблиц. То есть массив values можно заполнять вот так:
Datum *values = ...;
bool *isnulls = ...;

values[Anum_pg_authid_oid] = ObjectIdGetDatum(roleid);
values[Anum_pg_authid_rolname] = CStringGetDatum("user");
...
isnulls[Anum_pg_authid_rolvaliduntil] = true; // Говорим, что эта колонка имеет значение NULL

HeapTuple tuple = heap_form_tuple(desc, values, isnulls);


И какого же было моё изумление, что нумерация констант Anum_pg_authid_oid, Anum_pg_authid_rolname и т.п. начинается с единицы! С единицы, Карл! В языке, где вся индексация везде осуществляется с нуля! 🤯

И проезд по памяти у меня происходил в строке isnulls[Anum_pg_authid_rolvaliduntil] = true, потому что Anum_pg_authid_rolvaliduntil имеет значение 12, а в массиве isnulls как раз было выделено 12 элементов 🤦‍♂️

А значит, чтобы корректно использовать удобные константы, нужно каждый раз вычитать из них 1 при заполнении кортежа (код ниже взят отсюда):
new_record[Anum_pg_authid_rolname - 1] =
DirectFunctionCall1(namein, CStringGetDatum(stmt->role));
new_record[Anum_pg_authid_rolsuper - 1] = BoolGetDatum(issuper);
new_record[Anum_pg_authid_rolinherit - 1] = BoolGetDatum(inherit);
new_record[Anum_pg_authid_rolcreaterole - 1] = BoolGetDatum(createrole);
new_record[Anum_pg_authid_rolcreatedb - 1] = BoolGetDatum(createdb);
new_record[Anum_pg_authid_rolcanlogin - 1] = BoolGetDatum(canlogin);
new_record[Anum_pg_authid_rolreplication - 1] = BoolGetDatum(isreplication);
new_record[Anum_pg_authid_rolconnlimit - 1] = Int32GetDatum(connlimit);

Хороший API легко использовать правильно и тяжело — неправильно. API выше — плохой. Гораздо лучше было бы пронумеровать константы с нуля, а внутри функций, которым нужна нумерация с единицы, делать +1. А так получилось, что деталь реализации пролезла в интерфейс, и отобрала у меня 2 часа на дебаг 😔

Как говорится, пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете. Хорошо, что я не психопат и, разобравшись с этим, продолжил заниматься рабочими задачами. А то ж ведь мог и в git blame полезть 😆