Продуктовая разработка одним слайдом

Почти 2 недели (начиная с 1 марта) у меня ушло на встречи.

Для меня это много, и я бы точно не хотел это количество увеличивать.

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

Важно учитывать, что любая встреча (даже 15 минут) занимает больше времени, чем непосредственно ее длительность:

- это подготовка ко встрече;
- дорогое переключение контекста на нее;
- и возвращение в рабочий режим.

Поэтому, если вы лид или продакт, то, пожалуйста, помните об этом, когда ставите встречи коллегам-разработчикам.

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

📝 А еще: используйте асинхронное общение, где это возможно.

А сколько времени у вас занимают рабочие встречи? Для вас это много или мало?

@time2code

Декабрь 2024:

📌 Пока все подводят итоги уходящего года и планируют 2025, я тихо радуюсь, что бешеный темп, на который вышел 2024, постепенно сошел на нет.

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

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

ключевые события

✔️ Со своей продуктовой командой запустили крупную фичу для пользователей, к запуску которой мы шли весь квартал и очень плотно трудились, чтобы это стало возможным. Уже за первую неделю показали крутой результат и закрыли ОКР.

✔️ Стал ментором младшего инженера из соседней команды на период его онбординга. Поставил встречи 1-1 и уже провел несколько, по результатам которых получил положительных фидбек.

✔️ Много практики на F#. Решил десятки задач с рекурсией, через которые знакомлюсь с языком. Удобно изучать ЯП через подобные задачки + хорошая тренировка ума.

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

посты

⭐️ Хочешь стать Senior инженером? Начни с мышления. (читать)

🔖 Цена невнимательности в высоконагруженной системе (читать)

🔖 Мощная привычка, которая отличает опытных разработчиков (читать)

🔖 Кто такой Senior? (читать)

🔖 Продуктовая разработка одним слайдом (читать)

#результаты -> #дайджест

@time2code

5 шагов для крепкого селф-ревью (секретный рецепт)

Завершается очередной период перформанс-ревью. Как базово к нему подходить - делился в прошлом году.

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

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

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

Итак, надеюсь, вы:

1. Хорошо поработали в прошлом периоде :)
2. Фиксировали результаты своей работы и базово то, над чем работали (мелочи важны - потом лишнее можно будет убрать).
3. Успели насобирать продуктовых метрик о том, как вы улучшили мир. Без этого, к сожалению, будет проблематично доказать свою ценность. Проще всего за цифрами сходить к продакту, но можно и к тимлиду, и даже к аналитику (но это совсем на крайний случай).

Когда все ингредиенты собраны, остается только выбрать рецепт, по которому это можно вкусно подать.

Спустя пять периодов перформанс ревью я нашел такой:

3ORV (Objective Output Outcome Role Volume => three O R V).

Три ОРВи звучит не очень благозвучно, поэтому мне больше нравится произносить как "thrive" - что означает "процветать" и, вероятно, поэтому и работает.

Рассмотрим по шагам.

Цель (Objective)

Шаг 1 - Копируем и вставляем название ОКР'а или ключевого результата.

Сюда хорошо ложится формулировка из ОКР'а, но можно и любую другую, чтобы была лаконичная и понятная, которая обозначит контекст, к которому будет относиться все последующие блоки.

Что сделано (Output)

Шаг 2 - Копируем и вставляем артефакты нашей работы, которые собирали за весь период (если же не собирали, то предстоит увлекательное путешествия в недра Джиры, Гита и мессенджера, чтобы поднять всю свою работу; тут может пригодиться удобная формула для выполненных задач в Джире).

Здесь идет перечисление вашей работы: разработал сервис, проресечил проблему и декомпозировал задачи - все в таком духе. Обязательно указывать ссылки на ПР-ы, issues и треды в мессенджерах для подтверждения своих слов.

Какой результат принесло (Outcome)

Шаг 3 - Копируем и вставляем цифры, полученные от продакта / тимлида / аналитика.

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

Роль (Role)

Шаг 4 - Указываем зону ответственности, например: Разработчик Backend.

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

Объем (Volume)

Шаг 5 - Указываем цифру, например: 3 спринта.

Цифра в спринтах / кварталах. Может потребоваться подсчет, но можно и приблизительно.

Если работаете с матрицей компетенций и остается место, то можно еще добавить блок с ссылками на проявленные компетенции в ходе своей работы (имеется в виду, что вы проявляете компетенции инженера более высокого грейда).

И все!

Пример селф-ревью по методике прикреплю в треде.

Такой подход помог мне качественно оформить 7 целей на 800 знаков каждая (лимит на цель), возможно, будет полезен и вам.

@time2code

Форс-апдейт без негатива: это реально?

Хард / форс апдейт - это то, что происходит, когда вы заходите в приложение, а оно сообщает вам о необходимости загрузить обновление.

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

Любое дополнительное действие для пользователя - это стресс.

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

Конечно, обычно не все так пасмурно и обновление приложения происходит проще.

Не знаю, как у вас, но у меня всегда это вызывает негатив. Возможно, это связано с принудительным разрывом контекста.

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

А теперь предлагаю изучить 2 сообщения о форс-апдейте и подумать, какое у вас вызвало бы меньше негатива и побудило бы к обновлению (см. скрин):

🛴 от онлайн-магазина Самокат

+ Сочная обложка со свежими фруктами.

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

🌻 от сети магазинов Лента

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

- Стандартное системное окно. Можно было бы что-то красивое придумать, но для меня важнее, что подумали про содержание, нежели чем про обертку.

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

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

2. Если у вас форс-апдейты случаются часто, значит, вы что-то неправильно делаете. Есть смысл пересмотреть свою архитектуру, чтобы деплой новых фичей не ломал совместимость со старыми, конечно, при условии, что любите своих пользователей.

3. Еще хорошей практикой считается предложить пропустить текущее обновление и обновиться в удобное время. Конечно, если это возможно.

4. Пока готовил этот пост, зашел на форум ios-разработчиков и почитал Reddit. Там было предложение ограничивать доступ к новым функциям вместо форс-апдейта. То есть вы просто уведомляете, что какие-то фичи доступны только в новой версии, а старый функционал не пострадал и доступен без обновления.

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

@time2code

Мои карьерные ОКР на 2025 год

Планирование занимает много времени, а хорошее планирование может занять все, поэтому важно вовремя остановиться.

У меня получилось 4 основных приоритета на год, в каждом до 4-х ключевых результатов.

0️⃣ > Взятие следующего грейда

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

Ключевые результаты:
- KR 0.50 - Перевод трафика на проект, разрабатываемый в рамках рабочего тех. OKR
- KR 0.30 - Разработать механизм масштабирования для инициативы X
- KR 0.20 - Вынос специфичной логики из сервиса Y в домен Z

1️⃣ > Развитие сильного мышления

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

Ключевые результаты:
- KR 0.40 - Пройти школу SRE от LinkedIn
- KR 0.25 - Пройти курс по архитектуре FE
- KR 0.25 - Прочесть 2 книги по микросервисной архитектуре
- KR 0.10 - Пройти курс по лучшим практикам в DevOps

2️⃣ > Усиление бренда

Основной фокус на развитие блога и LinkedIn.

Ключевые результаты:
- KR 0.50 - Аудитория @time2code выросла до 300 человек
- KR 0.30 - LinkedIn Challenge -> каждый месяц по 1 посту
- KR 0.10 - Перевести блог с github pages на свой домен
- KR 0.10 - Статья на Habr или VC

3️⃣ > Математика

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

Ключевые результаты:
- KR 1.00 - Курс по основам математики

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

Планов много, работы - еще больше, а месяцев остается 11, хотя по китайскому еще только канун. Поэтому желаю каждому легкого и успешного года!

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

#цели

Лямбда-исчисление: зачем оно вам?

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

Так ли это?

На выходных развлекался с лямбда-исчислением (в дальнейшем буду называть "лямбда") и бета-редукцией.

Казалось бы, для чего и как это поможет в работе?

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

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

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

Влияние на разработку

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

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

В реальном коде

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

func LoggingMiddlewareWithHandler(logFn func(format string, v ...interface{})) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            logFn("Request: %s %s", r.Method, r.URL.Path)
            next.ServeHTTP(w, r)
        })
    }
}

LoggingMiddlewareWithHandler – функция, принимающая http.Handler и возвращающая новый обработчик. Это классический пример функции высшего порядка, которая модифицирует поведение переданной функции.

А при помощи logFn мы передаем произвольный обработчик логов.

Использование в коде:

logMiddleware := LoggingMiddlewareWithHandler(log.Printf)
http.Handle("/hello", logMiddleware(http.HandlerFunc(helloHandler)))

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

Что почитать по теме?

Есть полезные материалы на английском языке прямиком из Стэнфорда:

- Подробная публикация с примерами
- Интересная статья с онлайн-калькулятором бета-редукции

Если знакомы с лямбда-исчислением, то пишите в комментариях, что получится в результате бета-редукции 🤓

(λx. λy. x y) (λz. z) a

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

@time2code

Январь 2025:

ключевые события

✔️ Завершился очередной перформанс ревью. Предварительно все хорошо, конкретные результаты менеджеры, как обычно, держат в тайне до момента X. Пора выдохнуть начать готовиться к летнему (см. п.1). Очередной раз убеждаюсь, что, если начать подготовку заранее, то это значительно облегчит этот процесс вам в будущем.

✔️ Начал изучать материалы по SRE. LinkedIn по этим материалам онбордит новичков в SRE. Актуальная документация - отличный инструмент, который следует использовать всем компаниям для обучения сотрудников - это экономия многих сотен часов.

✔️ Погрузился в идеологию VIM и понял, как можно повысить свою эффективность, отказавшись от мыши. Пока продолжаю работать на VS Code, но со временем планирую отказаться и от нее (как уходил от Goland рассказывал в посте). Изучать VIM, когда вы привыкли к удобной IDE, выглядит очень странно и больно. Но есть инструменты, способные сгладить кривую обучения, например: vim-adventures - прошел бесплатные уровни, поэтому могу смело рекомендовать.

✔️ За пару вечеров при помощи AI написал простенький шахматный тренажер на JS (всего 200 строк). "Только я вам его не отдам", так как он не идеален, а сырой проект не хочется показывать. Интереснее здесь не сам проект, а инсайты, которые получил, работая с AI (спойлер: работу у программистов пока не отнимают).

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

посты

⭐️ Мои карьерные ОКР на 2025 год -> читать

🔖 Лямбда-исчисление: зачем оно вам? -> читать

🔖 Форс-апдейт без негатива: это реально? -> читать

🔖 5 шагов для крепкого селф-ревью (секретный рецепт) -> читать

🔖 Итоги 2024. Целый год по методике ОКР, выводы -> читать

#дайджест

@time2code

30 минут, которые могут изменить ваш продукт

Речь пойдет про мощный инструмент в исследованиях UX: User Day (UD).

UD относится к категории качественных исследований, а бывают еще количественные (если меня вдруг читают исследователи, то поправьте).

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

Большинство вопросов направлено на проверку гипотез, которые формулирует Дискавери команда.

Примеры гипотез:

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

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

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

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

За подробными примерами из практики рекомендую сходить на популярные ресурсы: habr, vc. Так, например, ребята из Selectel пару лет назад делились кейсами, как такие дни помогли им улучшить свой продукт.

Для чего это разработчику?

1. Это интересно

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

Конечно, когда получаешь такой положительный отклик о проделанной работе, это не может не радовать. Никто не любит работать "в стол", каждому важно, чтобы его труд был оценен.

2. Это расширяет твой кругозор

Когда слышишь реальный рассказ про опыт взаимодействия с твоей фичей, то начинаешь думать иначе. К техническому мозгу добавляется продуктовый и теперь, когда появляется задача от бизнеса, тебя не только заботит реализовать ее "as is" (лишь бы она была рабочая и отказоустойчивая), но невольно начинаешь думать про UX и по возможности стараешься влиять на это.

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

3. От тебя это ожидают

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

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

Вывод

Это мой второй юзер-дей за 2,5 года в компании. И хоть он требует от тебя некоторой подготовки и отнимает время у других задач, это определенно того стоит. Особенно, если вы хотите усилить свои софты.

А вам как кажется: стоит ли инженеру интересоваться подобной практикой? Может, пусть команда UX вместе с Продактами этим занимаются, а мы лучше сфокусируемся на хардах?

@time2code

Выжимаем из performance-review максимум

Недавно я делился собственным фреймворком для написания селф-ревью - 3ORV.

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

Фреймворк работает

Объявили результаты прошедшего периода, и мне удалось получить "сверхрезультат"!

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

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

И для того, чтобы выжать из перф-ревью максимум, мы переходим к завершающему пункту нашей дорожной карты => Анализируем

Обозначаем точки роста

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

Как их найти? - Пропускаем отзывы, которые приятно читать, и фокусируемся на оставшихся.

Я их выписал отдельно по следующему шаблону (см. скриншот):

- Грейд
- Фамилия
- Отзыв

Внимательно изучаем отзыв и стараемся емко сформулировать его суть (основные мысли). Фиксируем рядом с хэштегом.

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

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

Достаточно один раз проанализировать на что нужно сделать упор и уже на следующем ревью вы заметите, насколько сильно выросли за прошедший период.

* * *

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

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

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

@time2code

Февраль 2025:

ключевые события

✔️ Значительно продвинулся в одном из поставленных на текущий год ОКР'ов приоритета P0, достигнув половину ключевого результата.

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

✔️ Разобрался в работе hoverfly для интеграционного тестирования и симуляции API в изолированном окружении. Могу рекомендовать.

✔️ Изучил нетиповые структуры (abstract syntax tree, binary welded tree, blockchain, neural network).

✔️ Научился формализовать надежность системы, определяя ключевые свойства.

✔️ Больше углубился в философию юнит-тестирования, попрактиковавшись фокусироваться на свойствах системы, а не сценариях.


посты

⭐️ Лямбда-исчисление: зачем оно вам? -> читать

🔖 Архитектура - это не про System Design -> читать

🔖 Выжимаем из performance-review максимум -> читать

🔖 30 минут, которые могут изменить ваш продукт -> читать

#дайджест

@time2code

🧑‍💻 Почему на интервью не проверяют прикладные скиллы и зачем нужен лайвкодинг?

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

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

Попробую высказать непопулярное мнение в защиту ненавистного формата.

Основные моменты

1️⃣ Во всем мире подобные интервью стали своеобразным стандартом - метрикой для оценки инженера, поэтому ее легко применить и адаптировать под себя.

2️⃣ Такой формат легко масштабируется. Когда у тебя сотни заявок в неделю, то легко создавать воронку из нескольких собеседований, как это делают Биг Техи.

3️⃣ Так или иначе, алгоритмы и структуры данных - основа CS и работы программиста. Без их понимания невозможно стать сильным инженером.

4️⃣ Лайвкодинг буквально перемещает тебя в зону дискомфорта и стресса. Во время интервью важно оценить, насколько ты способен с ним справляться.

5️⃣ Очевидно, что компания из десятка человек хочет получить лучшего для "перекладывания json", а если все справились отлично, то как выбрать?

6️⃣ Подготовка интервью, на котором бы проверялись реальные скиллы для работы, очень ресурсоемкий процесс, который сложно масштабировать.

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

Поэтому кроме проверки технических скиллов существуют так называемые "поведенческие интервью" (behavioral interview), где идет уже проверка софтов и которую уже хакнуть или натренировать сложнее. По крайней мере, заученный текст популярных ответов или неискренность будут сразу бросаться в глаза.

Что на практике

В посте прикрепил табличку по MAANG'у, в которой наглядно представлено количество этапов:

- Recruiter Screen - быстрый созвон, чтобы обсудить ожидания и соответствие компании
- Tech Phone Screen - лайвкодинг, вайт-борд и пр.
- Onsite Rounds - смесь кодинга, системного дизайна и поведенческих раундов

В среднем насчитывается 7 интервью, что не мало! Но вполне допустимо для компаний такого уровня.

Комфортный режим

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

Например, для backend инженера:

0) быстрый созвон с рекрутером, чтобы познакомиться с компанией
1) быстрый тех. скрининг (не более 30 минут)
2) секция лайвкодинга (пара задач с литкода easy/medium)
3) платформенная секция, где спрашивается специфика домена, в котором предстоит работать
4) сист. дизайн (для высоких грейдов)
5) финальное интервью с командой без технических вопросов

Столько этапов предстоит пройти в Авито. И мне до сих пор кажется это адекватным (у меня, правда, было аж три финальных интервью, чтобы подобрать идеальную команду).

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

А в Т-банке то ли 4, то ли 5 (пишите в комментариях, если знаете, сколько точно).

Так или иначе, но адекватность компании можно оценить по тому, как она выстраивает свой процесс найма и сколько времени вам необходимо потратить на трудоустройство в нее.

Тестовое задание

Еще стоит кратко отметить, что тестовое задание на позиции >=middle для меня является своеобразным красным флагом.

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

Поделитесь опытом сколько у вас было этапов и как вы относитесь к такому количеству интервью?

Осуждаете ли лайв-кодинг? :)

@time2code

Чем опасен разрыв контекста?

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

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

Если нет времени на статью, то вот ключевая цитата:

Исследование от UC Irvine показывает, что разработчикам необходимо в среднем 23 минуты, чтобы полностью заново выстроить свой фокус после того, как их отвлекли.

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

Вот и получается, что при 8-часовом рабочем дне, двух-трех митингах в день и всего лишь 4-5 упоминаний в рабочих чатах у нас остается менее 5 часов на разработку.

И это, если мы не оставляли своих задач, а просто отвлеклись и попросили нас не беспокоить, то есть не потратили еще дополнительных 10-20 минут на ответ или объяснение того, что написано в документации, которую вы скидывали вчера.

В прошлом году анализировал сколько времени ушло на созвоны и цифра была около 20 000 минут.

Если тема откликнется, то сделаю замер, сколько реально времени в день уходит на код (включая размышления о нем).

Проблема ясна, но что с ней можно сделать?

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

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

1️⃣ Оставляем зацепки контекста

Оставляйте комментарии в IDE о том, что вы делали, чтобы была возможность быстро восстановить разрушенный контекст, так называемые "хлебные крошки".

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

Смысл в том, чтобы выгружать свой контекст и формализовать его.

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

Как можно еще себе помочь?

2️⃣ Фокус дня

Чтобы не завязнуть в длинных туду-листах, можно фокусироваться на важных событиях дня, сужая скоуп задач, убрав все ненужное.

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

3️⃣ Ставим защитный барьер

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

4️⃣ Игнорируем "срочное"

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

Поэтому, если я отвлекся на сообщение, то мне быстрее сразу ответить или написать, что отвечу позже, если это требует времени.

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

Важно оценивать степень срочности и важности.

Если лежит прод, то тут уже не до состояния потока и переживаний о контексте - сразу чинить.

Но зачастую 90% поступающих запросов могут подождать, а некоторые из них - даже сами и разрешатся, так как человек, формализовав свой вопрос нередко сразу находит на него ответ :)

@time2code

☕️ 25% на код, 75% на тыквенный латте! Сколько времени мы пишем код?

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

Среднее значение получилось в районе двух-трех часов*.

Это составляет 25% от рабочего дня, что может показаться не так много для программиста.

«Эффективные» менеджеры могут решить, что остальное время идет на тыквенный латте, но это не так. На тыквенный латте нужно не более 15 минут :)

Разберемся, куда уходит время.

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

✍️ Коммуникации

Это самый большой потребитель вашего времени. Сюда попадает все: Slack, MatterMost, Teams, общение на код-ревью или документах Конфлюенс.

Но что можно реально сделать?

1. Ставить явные блоки в календаре, во время которых включаете режим "Не беспокоить" и переходите в режим Deep Work. Лучше их делать небольшими, например, по 50 минут, чтобы была возможность восстановить свои силы и при необходимости ответить на срочные сообщения.

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

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

🗣 Встречи

Встречи - это тоже коммуникации, но более формальные и фиксированные в календаре, поэтому их стоит рассматривать отдельно.

В лучшем случае, 30 минут, а в худшем - целый день, плюс затраты на переключение контекста и подготовку к встрече.

Хоть PM и тимлид защищают разработчиков от избытка встреч, но совсем от них избавиться все равно не получится. Одним словом - Agile.

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

🥱 Рутина

Есть еще несколько категорий, на которые может уйти немало времени.

Например, можно легко полдня потратить на поиск проблемы или локализацию бага. Здесь сложно что-то предложить, кроме как не писать код с багами :)

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

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

По моему опыту, 90% упавших билдов связаны с проблемами в инфраструктуре или сервисах, находящихся в чужой зоне ответственности.

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

Вывод

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

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

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

@time2code

Dependency hell. Есть ли выход?

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

Еще со времен проектов на .NET постоянно страдал, что программа отказывает запускаться из-за отсутствия какого-нибудь *dll. Хотя ты на 1000% был уверен, что всего должно хватать...

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

* * *

Сколько времени потребуется, чтобы добавить проверку на еще одну константу в if?

Порассуждаем:

1) Мы знаем какую константу нужно добавить и куда? -> Да
2) У нас есть юнит-тест на этот if? -> Да, но нужно будет поддержать тест-кейс с учетом новой логики
3) Нужно будет протестировать в тестовом окружении

Выглядит как работа на несколько часов. Однако...

1. Оказывается обновить код нужно в библиотеке dict-lib, которую использует logic-lib, которую используют два сервиса и shared-lib, которую используют еще два сервиса...

2. А еще существует древняя библиотека old-logic-lib, которая серьезно завязана на старое поведение dict-lib при этом очень давней версии.

Узнаем, конечно, это неожиданно.

Мы поднимаем dict-lib до 3.14, но old-logic-lib перестает компилироваться, так как использует версию 2.71, что не позволяет обновить shared-lib, пока не будет устранена проблема с зависимостью.

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

Из вариантов: сделать быструю заплатку хардкодом и добавлением комментария или можно найти оунеров и разобраться в том, как в текущих реалиях должно все работать и поправить…

4. Когда все проблемы решены, начинаем делать последовательные ПР-ы, сопровождаемые каскадным поднятием версий библиотек, но настроенный CI вносит свои коррективы, сигнализируя "красной" сборкой и предлагая нам так сильно не ускоряться и чуть насладиться моментом резолвинга зависимостей, вручную перезапуская билды и анализируя, что могло пойти не так.

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

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

6. Код-ревью везде пройдено. Торжественно мерджим 8-ПРов и выкатываем несколько сервисов.

7. Замечаем одиноко стоящий почти распиленный монолит. У него нет зависимостей, все живет в нем.

Радостно правим одну строчку и делаем всего лишь один ПР, попутно ужасаясь тысяче тестов на CI, которые должны пройти (они не пройдут и ты их будешь побеждать еще 2 дня, по крайней мере, ты готов к этому).

8. Теперь все хорошо, изменения в проде. Бизнес доволен, а ты - ретроспективно улучшаешь оценку своих задач. Тебе теперь известно, что поправить одну константу в "одном месте" занимает больше двух часов и даже больше двух дней.

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

@time2code

Март 2025:

ключевые события

✔️ Много работал над достижением KR из поставленных на текущий год ОКР'ов приоритета P0. По каждому из них обозначил план, каждая часть которого состоит из понятных инкрементов. Если не сбавлять темп, то закрытие ОКР-а выглядит весьма вероятным в текущем квартале.

✔️ Решил системно подойти к изучению тех. литературы и делиться прочитанным. Завел страничку на Бусти, где разбираю модные книжки и делаю выжимки с ключевыми идеями. С мая планирую прикрыть пейволлом. Начал с «Микросервисов» и выложил одну из частей Главы 1, где мы знакомимся с антипаттерном "Большой комок грязи" и погружаемся в "монолитный ад".

✔️ Познакомился с библиотекой fyne.io для создания нативного UI в Go и написал простенький визуализатор работы по алгоритму раунд-робин.

✔️ Попрактиковался избавляться от if.

✔️ Размышлял о модели данных в проекте и практиковал избыточность, а также анализировал возможно ли отказаться от ORM.

✔️ Учился правильно готовить юнит-тесты, проверяя абстрактный эффект при помощи моков.

✔️ Впервые закоммитил в монолит на php (было больно, но не так больно, как поднимать версию зависимости в десятке микросервисов -> пост).

✔️ А еще решил задачу по удалению 15 миллионов строк из продового PG, не блокируя потребителей сервиса и не зависнув надолго. Обязательно хочу про это написать (ключевые слова: dead tuples, autovacuum и прочее).

посты

⭐️ Чем опасен разрыв контекста? -> читать

🔖 Почему на интервью не проверяют прикладные скиллы и зачем нужен лайвкодинг? -> читать

🔖 Кейс из практики: как составной индекс ускорил запрос на 50% -> читать

🔖 Сколько времени мы пишем код? -> читать

🔖 Dependency hell. Есть ли выход? -> читать


#дайджест

@time2code

Сила единого языка. DDD в действии

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

На согласование ушло в 4 раза больше времени, чем изначально закладывалось.

Почему так вышло

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

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

Что может помочь

И тут на сцену выходят софт-скиллы.

По тому, как продвигалось согласование документа, мне стало понятно, что существует какая-то проблема или непонимание.

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

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

Фактически пропитчил архитектуру своей фичи перед стейкхолдерами, но вместо 30 секунд на это ушло столько же минут.

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

Domain-driven design

Вот так на своем опыте я заново открываю DDD, ключевой концепцией которого является наличие единого языка (Ubiquitous Language), способствующего понятной коммуникации для всех заинтересованных сторон проекта.

В последнее время все чаще слышу про использование или внедрение DDD в работе - обязательно планирую погрузиться в тему и поделиться инсайтами.

Положил к себе в бэклог книжку Domain-Driven Design: Tackling Complexity in the Heart of Software, разберу и выложу со временем здесь.

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

↘️ Выводы

1. При составлении любого документа (не только архитектурного) явно обращайте внимание читателей на рассматриваемый контекст и используемую терминологию.

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

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

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

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

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

@time2code

💔 Мои боли в программировании

Есть всего несколько вещей, которые очень не люблю. И на это есть причины.

1️⃣ Системное администрирование (включая DevOps-практики, но между ними нельзя ставить знак равенства)

Появилось ощущение, что первой профессией программирование не стало именно по этой причине (я везде видел сис. админство).

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

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

Крайне полезно: поправить конфиги в микросервисе, развернуть пет-проект на VPS-сервере через Docker, самостоятельно настроить CI/CD.

Fun fact: несмотря на мою нелюбовь - заставляю в себе культивировать подобные скиллы (особенно DevOps). В прошлом году даже задумывался про то, чтобы уйти в эту специфику из продуктовой разработки, но пока решил этот вопрос отложить, так как экспертиза, чтобы этим заниматься все время, нужна объемная.

2️⃣ Миграции для баз данных

Миграцией я буду называть процесс, при котором создается файл миграции в формате "20250422-add-table.sql" и впоследствии исполняется (накатывается) автоматизированным инструментом для миграций (мигратором).

Когда только начинал свой путь, одно слово "миграции" - пугало. И не просто так.

⚠️ Важно понимать, что работа с миграциями сопряжена с серьезной ответственностью, в особенности, если работаете с большими данными.

Вам нужно помнить про кучу вещей:

- не выполняете ли вы какой-то длительный запрос, который заблокирует вашу таблицу, пока не будет исполнен (здесь применимы советы: обработка данных небольшими чанками, запуск миграции в самый непопулярный период и т.д.);
- правильно ли вообще спроектирована БД: корректный ли выбранный индекс, есть ли нужные ограничения на таблицы, хватит или инта или лучше перестраховаться и взять бигинт;
- и другие вопросы, непосредственно относящиеся к проектированию баз данных, а также доступности данных на период миграции.

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

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

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

Вероятно, поэтому одной из основных рекомендаций при работе с миграциями в нагруженной среде:

Новая миграция - новый файл и отдельный ПР.

Другим неплохим советом может быть - составить чек-лист, чтобы перепроверять себя: не упустили ли что-то важное.

* * *

Интересно, но между 1️⃣ и 2️⃣ есть сходство. Они не с проста в одном посте.

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

Что миграции для БД, что любое конфигурирование - не любят неточностей. Они их не прощают.

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

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

Интересно, какие у вас есть нелюбимые вещи или боли в разработке?

Чинить какой-то мутный баг или разбираться в чужом легаси - не в счет :)

@time2code