ITKatya: культурные паттерны в IT

🌧️ Вчера прошел ProITFest, и это был день — не день, а целая история.
Спасибо всем, с кем удалось встретиться, обняться, поболтать! Спасибо тем, кто пришел ко мне — особенно в такую дождливую питерскую субботу. 💛

Иногда жизнь складывается так, что вместо игры и интерактива тебе достается… часовая сцена и формат стендапа.
🧩 В твоем распоряжении: чужой ноут, частично нераскрывающаяся презентация и люди.
Все.
И ты стоишь и думаешь — «ну, значит, так и будем жить». И живем! 😄

📌 Итоги выступления:
1. Надо сбацать — сбацаем 🤣
Без паники, без истерики. Говорят, уже почти не видно, как по ходу пьесы я строгала комедию из несостоявшейся драмы.
2. Самое прекрасное — это люди.
Если у тебя есть своя аудитория, то уже без разницы, как все пройдет.
Я бесконечно признательна каждому, кто пришел слушать доклад про финтех.
3. Главное — знать, о чем поешь.
Тогда песня течет свободно. И вопросов ты не боишься, потому что все, что говоришь — изнутри, из опыта, из жизни.

🧠 Выводы по теме доклада:
1. Всегда можно «накидать три квадратика» — и на какое-то время этого даже хватит. Но! Это будут костыли. А костыли не масштабируются и не поддерживаются.
2. Некоторые домены — такие хитрецы: притворяются другими. Финтех, например, — мастер мимикрии. Без насмотренности сложно даже распознать родное.
3. И да, переусложнение и переупрощение — близнецы, и оба превращают разработку в нечто слишком дорогое.

🔗 Как и обещала, вот вчерашние квадратики:
https://xmind.ai/share/44c7eOSe?xid=1kyoJQfC

🎭 А что самое важное я унесла с собой после этого дня:
1. Благодарность людям.
2. Вопрос к себе: а что дальше делать с этим финтех-циклом? Как упаковывать, куда нести, и нужен ли он кому-то за пределами уютного зала?

Обнимаю. Пусть небо — в любом смысле — будет спокойным.
И пусть все встречи происходят, когда нужно. ✈️

PS: Пора вспомнить одну из моих любимых картин…
«Пулково не принимает».

#fintech

👀 Не реклама, а просто подсмотренное и очень рекомендованное.

Я точно туда пойду, так что вот вам инфа, если вы тоже в теме DevRel или рядом, и хотите чуть глубже в это нырнуть:
👉 DevRel-мастерская от DevRel Agency
21 июля – 1 августа
созвоны в зуме по будним дням, 10:00-11:00 мск
чатик в телеге

💬 А знаете, кто виноват в моей активности в соцсетях, постах, экспериментах с каналами и публичностью?
Леша Долгушев, exDevRel Самоката, чье влияние неоспоримо: когда-то он аккуратно подтолкнул меня начать делать «что-то свое».
(и да — я тогда завела тот самый уютный канальчик «Аналитические чаепития» — может, кто-то меня еще с него помнит? ☕️👩‍💻)

И вот теперь, спустя пару лет, я сама планирую пойти поучиться/понахвататься премудростям в DevRel-мастерской, где Леша — один из менторов и организатор.

Если вы хотите системно подступиться к этой роли (или уже ею занимаетесь, но хотите апгрейд) — я бы очень советовала. А если вы хотите «спикерствовать» или вы стейкхолдер и вас задолбали-это тоже для вас!
Ну и в целом — будет движ, знакомство и, скорее всего, тепло, как умеют ребята из DevRel Agency 🧡

И будем честны, в будни утром-самое удобное время!

🎭 Контент из командировок — худший из всех возможных. Просто потому что на него тупо не хватает времени.

И да, самым амбициозно-ошибочным решением был мой контент-план, где я вам чуть ли не лайв-трансляции с места событий обещала.
На практике? Сегодня среда, а я до сих пор не выложила даже инфу о proITFest 🙃

Поэтому — держите:
📍 5–6 июля, Санкт-Петербург, proITFest
Я провожу экспериментальное мероприятие, и это не просто доклад, а целая живая история:

“ФИНТЕХ: ПРОЕКТИРУЕМ ПО ТРЕБОВАНИЯМ, НО КАЖДЫЙ РАЗ НЕ ТО…”
Новый для меня формат — почти игра: с сюжетом, инженерными решениями, разочарованием в себе и, конечно же, в бизнесе,
который опять ничего не сказал, а мы опять «внезапно» не угадали.

🎟️ Вот тут подробности и программа

Если хотите очно встретиться, услышать меня (и еще кучу крутых спикеров) — промокод: Lysenko
Он вам даст хорошую скидку и мне повод радоваться встрече.

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

Про сковороду, Halmark и облом 🧄

Я уже в СПб, а пост выходного дня...

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

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

— «Ни о чем не беспокойся. Теперь все твои проблемы — мои».

Я доедаю кусок ягненка и поворачиваюсь к Мише с вполне резонной претензией:

— А вот ты мне такого никогда не говорил…

И тут тишина. Пауза по Станиславскому. Он доедает.
А потом, совершенно спокойно, без капли пафоса:

— А чего говорить, если мы так уже больше 10 лет и живем?..

💥 Меня аж током пробило. Потому что, ЕЛКИ-ИГОЛКИ, он прав. Живем ведь. Он ведь так и делает. Сегодня, например, заказал мне специальную сковороду для гриля, если вдруг я захочу готовить стейки в масле. (А это, простите, отдельный вид любви — забота о способах приготовления потенциальной еды, которую ты еще не захотела, да и Миша стейки не ест).

Но все равно… Обидно, что не говорят. Не декламируют на фоне рождественской ели, не танцуют с тобой на корпоратах танго, не говорят: «Бросай все, моя женщина не должна работать!» Хочется же иногда…

🍲 А пока я уехала в командировку на две недели — можете пожалеть бедного Мишу.
Потому что у него, когда меня нет, наступает долгожданный период чеснока.

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

🧭 Два дня про компетенции: между «все умею» и «зачем мне это»
День второй и третий провел Илья Прахт — и они были посвящены компетенциям СТО. Насколько тебе вообще подходит эта роль? Что ты уже умеешь, а что — зона роста?
Честно, не могу сказать, что были прямо откровения. Но ключевой инсайт был не в списке навыков. А в том, как по-разному понимается роль СТО в разных странах, культурах и компаниях. Это то, о чем часто забывают. Где-то СТО — это почти CIO, где-то — ближе к VP of Engineering, где-то — архитектор, а где-то — человек-оркестр, который делает все: от подбора людей до проведения ретро.
А еще в обсуждении прозвучала важная мысль: в европейской практике чаще разделены законодательные и исполнительные функции, а в российской культуре все еще популярна модель «универсального солдата». Я лично стараюсь отделять роли — если я создаю правила, то не исполняю их сама. Это сложнее, но гораздо здоровее.

🧠 Кейс, который вытащил наружу тему гендера
И вот внезапный момент. Один из кейсов вскрыл у меня глубинную вещь — влияние гендера на профессиональные паттерны поведения. В ситуации, где предполагалось легкое панибратство, я поймала себя на том, что не могу туда «зайти» — просто некомфортно.
Потому что есть устоявшиеся паттерны поведения в IT-среде, особенно в постсоветских компаниях. Женщину часто воспринимают либо как «маму», либо как «любовницу», и место для дружеского, профессионального равноправия в этих паттернах просто не предусмотрено. Особенно если ты занимаешь техническую управленческую роль.
Поэтому приходится выстраивать образ адвоката — говоришь по делу, спокойно, отстраненно, без лишних эмоций, потому что любое проявление теплоты может быть считано двусмысленно. А вот в европейской компании — достаточно сохранить текст адвоката, но добавить улыбку — это норма. Это, кстати, еще раз подтверждает важность контекста культуры, когда мы говорим о лидерстве.

🤔 А теперь по-честному: что было не очень
Часть с разбором компетенций CTO во второй и третий дни оказалась затянутой и, как отметили многие, слегка противоречащей тому, что мы обсуждали до этого. Вроде бы говорим: «СТО бывают разные», а через час уже звучит: «надо быть T-shaped по всем направлениям, особенно с учетом специфики рынка».
Это не страшно. Никто не заставляет брать все в работу «как есть». Но момент легкой нестыковки и перегруза ощущался. Возможно, просто не хватило мостика между «все разные» и «но вот тебе карта компетенций». И, конечно, всегда можно и нужно адаптировать под себя.

📌 Итого: стоит ли идти на курс, если ты не СТО?
Да. Если ты хочешь выйти за пределы своей текущей роли.
Ну а уже в пятницу (завтра) вторая трехдневка и постараюсь поделиться выводами побыстрее... хотя... не обещаю!

Первая трехдневка на курсе CTO от Stratoplan: как это было, что по-настоящему откликнулось, и стоит ли оно того

Вот и началось! Мы стартовали обучение на курсе Chief Technical Officer от Stratoplan, и позади первая трехдневная очная сессия. Это было насыщенно, непросто, неожиданно по форматам и очень многослойно по ощущениям. Меня часто спрашивают: «А стоит ли идти учиться на CTO, если ты еще не CTO?» И вот как раз сегодня хочу рассказать, что мы успели пройти за три дня, что меня поразило, а что — заставило задуматься. Спойлер: да, стоит. Но не по тем причинам, по которым вы думаете.

📍 День первый: аудит, который пересобрал мой подход
Первую сессию вел Рома Иевлев — и посвятил ее теме аудита. Что делать, если ты пришел в новую компанию, в новую роль? Как понять, что у тебя под капотом?
Мне эта тема невероятно откликнулась. Во-первых, потому что я сама недавно проводила аудит, придя в новую команду (вот пост). Во-вторых, потому что у Ромы получилось показать аудит как инструмент стратегической диагностики, а не просто «опиши процессы и найди косяки». Он предложил девять сегментов, через которые можно разложить компанию или отдел:
01) Потребительский сегмент
02) Ценностное предложение
03) Каналы взаимодействия
04) Потоки поступления задач
05) Ключевые ресурсы
06) Ключевые партнеры
07) Ключевые процессы
08) Структура издержек
09) Риски
Некоторые из этих элементов пересекались с тем, что я уже делаю, но были и точки роста: я, например, раньше уделяла меньше внимания «каналам взаимодействия», а тут поняла, насколько они важны. Особенно в свете новых AI-инструментов, которые позволяют мэппить эти каналы визуально, строить карты, находить узкие места. Конечно же надо попробовать сделать.
Отдельно хочу отметить важную мысль: аудит всегда будет зависеть от уровня, на котором ты находишься. И не стоит ждать универсального подхода. СТОшный аудит — это один взгляд, взгляд руководителя команды — другой. Но пункты, по которым идет СТО, вполне можно декомпозировать под себя.

💡 Флешбек: разговаривать с ушедшими — это нормально
Одна из практик, о которой говорил Рома, меня по-настоящему зацепила. Это общение с теми, кто уже ушел из компании, особенно если они занимали до тебя похожую роль. Это может быть не всегда просто, но если удается — это золотой ресурс для проведения аудита и понимания рисков. Я сама так делала — говорила с бывшими сотрудниками, чтобы понять культуру, конфликты, уровень зрелости. Это работает куда лучше, чем анонимные отзывы на Glassdoor: можно получить живое мнение, нюансы, предупреждения.

🤹‍♀️ Геймификация, которая вскрыла синдром отличницы
И вот тут Stratoplan сделал поворот, которого я не ожидала. Нас разбили на маленькие команды (у нас — 4 человека из разных стран и отраслей), и вся учеба будет идти через эту игровую механику. Баллы, рейтинги, командные задания.
На первый взгляд — просто игра. Но на деле — социальный и профессиональный эксперимент. Сертификат от игры не зависит, но наш внутренний «отличник» никуда не делся. Мы, миллениалы, учившиеся в системе «ответил правильно — получил пять», до сих пор внутренне боимся ошибаться. И радуемся, когда «ВСЕ БЕЗ ЗАМИНОК».
При этом геймификация — не просто фан. Это способ втянуть нас в командную работу, и, как я вижу, это уже работает.

🌱 Про pet-проекты, менторство и еще одну работу, которая не совсем работа, но жрет времени как три

На днях пересеклась с Сашей — автором канала для аналитиков. Слово за слово в комментах, потом в личке — и внезапно оказались в очень интересной теме.

А именно — почему, начиная с определенного уровня, становится почти странно, если у человека нет своего pet-проекта, он нигде не менторит, не пишет тексты, не выступает, не учит или хотя бы не учится.

🎯 Почему это важно? Да просто потому что...
Я прошла этот путь. Может, потому что чуть постарше Саши (польщу себе этим "чуть"). Может, потому что просто пришлось.
Но было время — и это даже не какие-то древние времена, а лет 10 назад, — когда я работала на двух, а иногда и на трех работах одновременно.

И да. Конечно. Речь была про 💰деньги. Мне хотелось больше зарабатывать.
Хотелось позволить себе поездки, вкусную еду, книги, учёбу, иногда — просто чуть-чуть больше жизни.
Деньги не были мотивацией в духе «обогащения». Они были способом прийти к приемлемому уровню нормы.

И вот со временем все меняется:
Ты больше работаешь. Ты понимаешь, сколько ты стоишь. Ты понимаешь, что ты можешь дать компании, а что хочешь взамен.
И тогда деньги перестают быть условием. Они становятся рамкой: «ниже вот этого — даже не начинаем говорить».
Это не понты. Это гигиена. Как уровень безопасности.
Как граница — за которой нельзя, потому что будет просто нехорошо.

А потом...появляется это «что-то еще».
Pet-проекты. Менторинг. Преподавание. Канал. Блог. Курс.
Да хоть посты в телегу — уже что-то.

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

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

Но! Я больше не беру на себя проекты, за которые не могу всерьез отвечать.
Я не готова вписываться в историю, где на мне висят обязательства уровня фуллтайм/парттайм. 🙅‍♀️ Это не про деньги. Это про моральку.

При этом — есть компании, которые воспринимают такую активность как... редфлаг 🔖.

"А вдруг она что-нибудь расскажет?"

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

🤷‍♀️ Зачем? Почему?
Да ХЗ. Мне не понять. И, если честно, я даже не хочу понимать.
А хотела бы я, чтобы мои сотрудники выступали?
Да! И еще раз — да. И вот уж точно кто всячески поддержит, подтолкнет, еще и поможет с материалами — это я. Не верите — спросите у тех, кто со мной работал.
Потому что…
👨‍🎓Ученики учат учителя.
🤝Потому что вместе — проще.
🎤Потому что, когда ты делаешь что-то «вслух» — ты сам учишься глубже.
👨‍🏫И потому что развитие через других — это один из самых мощных рычагов роста.

Признание: Я хочу, чтобы мои ребята ходили на конфы, писали, делали доклады, вели свои каналы, рассказывали про свои ошибки и инсайты.
Почему? Потому что все что они узнают и попробуют, они принесут обратно в команду, в команду.
И такой подход усиливает всех.

Согласна ли я с Сашей?
На 95%. Может, мы чуть по-разному видим «мотивации» — слава/деньги/власть.
Но здесь у каждого свои проекции.
Кто-то за деньгами видит безопасность.
Кто-то за славой — признание.
Кто-то хочет влияния, но на самом деле — просто хочет быть услышанным.

И нормально пересматривать свои цели. Нормально хотеть сначала одного, потом — другого.
Нормально меняться.

🤔 Осуждаю ли я тех, кто не читает, не пишет, не менторит? Нет.
Считаю ли я их плохими специалистами? Тоже нет.
Просто у каждого — свой путь. Но да, я радуюсь, когда вижу тех, кто хочет большего.
Не в смысле денег, а в смысле участия. Тех, кто не боится выйти за рамки своей текущей зоны.
Кто хочет учиться.

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

💥 А чтобы все подкрепить статистикой-ловите ссылку на исследования-почему у ITшников больше 1ой работы!

System Design Interview guide_2

6️⃣ Роберт Мартин и его чистота
Если у вас совсем нет времени, то поговорите про эти книги с chatGPT или Gemini. AI прекрасно о них осведомлен и умеет подготавливать “краткие выводы”. Не сказать, что вы прям станете супер-умным, но поддержать разговор должно хватить. И вообще рекомендую посмотреть дядюшку Мартина на YouTube — крайне приятно, интересно, а еще— простой, понятный английский без проглатывания 50% звуков.
Ну и конечно же читаем его блог, там еще есть интересно про Agile, который испортили коучи и бизнесмены

7️⃣ Событийный шторминг
Конечно же, возьмите EventStorming от Сережи Баранова — там наглядненько, с примерами.

8️⃣ Внезапно рекомендую свой доклад с ArchDays
Доклад не про то, что можно/нужно переписывать код, а про то, что иногда его практически не переписать, и единственный путь, который — это писать рядом отдельный новый. И это долго, дорого, и никому из бизнеса обычно не нравится. Но, что странно, как раз ответов от сеньор-разработчиков/лидов о том, что они пойдут что-то доказывать и объяснять бизнесу, в момент обсуждения задачи на System Design Interview — практически не случается. И дело вовсе не в том, что ты не ведешь кандидата к этой теме, а в том, что большая часть кандидатов принимает за базу позицию «это не моя зона ответственности».

9️⃣ И вот тут, когда надо погрузиться чуть глубже в проблемы бизнеса и пользователей, на помощь приходит книга “No Interface” — у нее есть целый сайт
ИМХО, это прежде всего книга не для дизайнеров и UX-еров, а как раз для “глубоких подкапотчиков”, потому что все, кто работают в core и платформенных продуктах, со временем теряют связь с пользователем реальностью. Мы их не видим, они даже часто вообще не на нашей стороне, а скрыты за процессами мерчанта, который с нами интегрирован. И тут очень легко прийти к состоянию — отринуть проблемы конечного пользователя и сказать: «пусть мерчант как хочет, так и интегрируется», ведь весь UI на его стороне, а нам надо «денюжку гарантированно водить за ручку» и нагрузочку обеспечивать…
Но, к сожалению, при таком подходе могут получиться настолько удивительные кариозные монстры, что офигеют все.

🔟 Ну и если вы пробрались через ВСЕ вышеперечисленное — на закуску остаются: стратегия, риски, работа с командой, бюджетирование…
Тут, к сожалению, книг и статей либо слишком много, либо слишком мало. И отправить в какие-то конкретные источники действительно сложно. Да и многое завязано на “принципах веры”. Потому что со временем я уже не понимаю, как объяснять, почему в callback, который приходит мерчанту в ошибке, кроме кода внутренней ошибки, если вы еще и решили показать код ошибки системы, с которой вы интегрированы, — на это надо выделять отдельное поле, а не кидать в «простыню» поля message, где может быть до 40 параметров (я не шучу — это очень распространенная практика и часто еще и идет под руку с 200 OK + error message).

🎬 Вместо эпилога…
Не знаю, насколько это все было полезно, но, возможно, этот пост — прежде всего для меня самой, чтобы при запросах по System Design не рыться по закромам, а просто выдавать все материалы списком.

System Design Interview guide_1

Стартую 2 обещанных дня материалов по SystemDesignInterview!

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

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

1️⃣ Если бы нужно было порекомендовать кого-то одного на почитать/посмотреть, то, конечно же, это Саша Поломодов!
У Саши потрясающий спейс на медиуме и я прям настоятельно его рекомендую изучить.
У Саши офигенные доклады и разборы System Design interview, и он заведует практикой в T-банке. Смотреть и читать стоит ВСЕ. Главный плюс — Саша демонстрирует всегда очень системный и последовательный подход с углублением в технические детали и объяснениями, зачем и почему именно это важно показать.

2️⃣Книга "System Design Interview — An insider’s guide" by Alex Xu
На русском издает издательство Питер
Ее достаточно подробный обзор делал Саша, а еще есть, опять же на медиуме, краткий обзор, чтобы понять, читать ли книгу, от Никиты Ульшина

3️⃣ Легендарный кабанчик...
Ну тут без вариантов. Бог с ним, с дельным чтением, но хотя бы в общих чертах и пересказ глав — хорошо бы держать в голове (совсем в идеале — понимать).
Автор сего толмуда Мартин Клепман "коротенько" изложил основные концепции проектирования и работоспособности высоконагруженных систем. Поэтому для всех систем с высоким SLA и конеч-то HighLoad-отраслей — это must. Тут с ознакомлением с книгой прекрасно справилось на Хабре само издательство Питер

4️⃣ Как только вы заберетесь в "тяжёлые" домены, то у вас не то чтобы останется много вариантов не блеснуть знаниями по DDD (и, умоляю, не отвечайте на собеседованиях, что вы ничего не читали, но всю жизнь как-то работаете, а описанное в книгах — зло и оторвано от мира, и чтобы нормально писать код — надо просто писать, а не время на книги тратить...)
И в этом разделе аж 2 рекомендации. Если хотя бы по верхам хотите отличать аббревиатуры с буквами DD — то вот замечательная статья с Хабра — автор Дима Переверза. Просто в ножки кланяться Диме готова за то, что коротко, понятно и в одном месте собрал описание DD-практик. Выдаю почти всем, кто приходит с запросами о погружении в технику для продакта, начале подготовки к System Design Interview и т.п. как базовую шпаргалку. Это не то, чего достаточно для обучения, но это прекрасная стартовая точка, чтобы копать вглубь — там, где необходимо!

5️⃣ Ну, куда ж без DDD головного мозга...
Тут как всегда: 2 Вернона, 1 Эванс и теперь с ними вместе Хононов.
Если раньше я советовала читать в последовательности:
1) тонкий Вернон
2) Эванс
3) толстый Вернон
То сейчас, я бы рекомендовала начать знакомство с Хононова, перейти к толстому Вернону и закрепить все Эвансом.
И тут вы можете вспомнить про то, что еще есть Миллет, но я к своему греху не читала — пока стоит на полке...
Ну и конечно же есть Domain-Driven Design Quickly и вот она есть на английском, но в очень интересном виде на LinguaLeo — не очень поняла ее, если есть Хононов, Эванс и Вернон, но если вам надо именно quickly — не осуждаю, но и ХЗ с какими выводами вы от нее уйдете.

Как вы догадываетесь, это не конец… Продолжение в следующей части (или села Катя написать «коротенький» пост 🤣)

📚 Писать нельзя не писать 📚
(запятую поставьте сами)

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

А про SystemDesign расскажу на след неделе, так как я там случайно "расписалась" на АЖ 2 ПОСТА материалов... А сегодня - навеянное вопросом под одним из последних постов:

что мне помогает писать?..

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

✍️ 1. Уильям Зинсер — Как писать хорошо
Одна из самых полезных книг, что я читала.
Не ждите откровений — их там нет.
Но то, как структурированы принципы, типы текстов, подходы, язык — это действительно золото. Особенно если вы пишете нехудожественные тексты: статьи, очерки, блоги, объяснялки.
Потрясающая систематизация, адекватный тон, и — внимание — раздел про типы языка в разных жанрах.
Очень хорошо ложится в голову и не пылится.

🔤 2. Нора Галь — Слово живое и мертвое
Для меня — про ремесло.
Про то, как важно пропускать текст через себя, даже если ты не пишешь, а переводишь (хотя, какое же тут ДАЖЕ).
Если вы работаете с чужими материалами, переводами, или делаете адаптацию — Нора Галь незаменима.
И отдельное замечание: она знала русский язык как боженька, и это читается в каждой строке. Восхищение и зависть.

🧘‍♂️ 3. Рэй Брэдбери — Дзэн в искусстве написания книг
Полезности — немного. Но как же он пишет!
Прямо увлекает, тянет за собой, вдохновляет.
Взять Набокова и его лекции или Толкина с его «Профессором и чудовищами»: они — величественные, умные, методичные.
А Брэдбери — влюбленный в слово, который делится этой влюбленностью.

🧩 4. Джанни Родари — Грамматика фантазии
Это база для придумывания историй.
Когда я переезжала, я взяла с собой две книги: Анненского (сборник стихов) и Родари (Грамматику).
Если вы когда-то хотели какой-то идеей кого-то увлечь/вдохновить и находить язык даже с детьми — вам сюда.

🛠 5. Оливер Кемпкенс — Дизайн-мышление. Все инструменты в одной книге
Эта книга не про писательство. Но про выход из творческого кризиса!
Хороший учебник, с четкими инструментами.
Если застряли и не понимаете, как повернуть мысль — он помогает свернуть вбок и найти новую тропинку.

🧾 6. А. Мильчин и Л. Чельцова — Справочник издателя и автора
Очень полезная штука.
Приводит в порядок:
— мышление,
— структуру текста,
— и базовые знания языка.
Если вы забыли, как отличить причастие от деепричастия, или в какой момент текст начинает утекать в тартарары — берите.

Думаю, что многие спросят, почему в списке нет "Пиши, сокращай 2025: Как создавать сильный текст". И тут списком:
1) Мне не все концепции близки
2) Для меня (внезапно) сильно растянуто (и не поделу)
3) Очень "топорный" язык

💬 Поделитесь в комментариях — а какие книги/статьи, вы бы рекомендовали...

Хороших выходных — и пусть слово будет живым ✨

🧠 В мире, где ИИ взламывает резюме, быть нанимающим менеджером стало «вдвойне веселее» 🤣

В 2025 году собеседовать людей стало похоже на участие в интерактивном театре:
👩‍💻 сначала ты читаешь красиво сверстанные биографии уровня «родился, женился, умер»,
🧾 потом пролистываешь нечитаемые блоки текста от настоящих инженеров,
🤯 а дальше начинается кастинг, кто кого перехитрит: кандидат — систему или ты — кандидата.

📍Начнем с начала.
Современное резюме — это квест.
Если ты хочешь, чтобы его вообще увидели:
— ты идешь к консультанту, который поможет «взломать» алгоритм,
— подгоняешь формулировки под ATS,
— узнаешь, какие слова любят HR и за что дают баллы,
— а если ты еще и не носитель языка — платишь за нормальный английский.

И вот ты уже — не человек, а продукт.

📍 А если ты настоящий инженер…

Ты не знаешь, как «склепать» резюме, ты не думаешь про ключевые слова, и ты, скорее всего, даже не подумал кинуть текст в ChatGPT.

Результат — набор нечитаемых строк, где нет ни логики, ни акцентов, ни хронологии.

А ты — нанимающий менеджер — сидишь с двумя крайностями:
— красиво написанные пустышки,
— талантливые, но нерасшифрованные сущности.

🙃 Про опыт на собеседованиях
И тут начинается веселое.
Люди более-менее научились рассказывать про опыт.
Поэтому этап «расскажите, чем вы занимались» — можно почти сразу пролистывать.

Есть два подхода:
— 🧔 Мой муж предпочитает копать глубже в уже имеющийся опыт — раскапывать детали, вытаскивать нюансы, проверять глубину понимания.
— 👩 Я, если честно, чаще смотрю на мышление. Потому что если ты ищешь Лида или синьора с потенциалом — важно не только, что человек делал, но и как он думает.

🧠 Как можно проверить мышление?
Три пути:
1. Теоретический допрос
— Похоже на экзамен
— Неловко, стрессово, малоинформативно
— Полезно только если вы нанимаете в институт МГУ, или вы нанимаете в инцидент-команду
✅ Вердикт (ИМХО): скучно, бесполезно, неэффективно

2. Лайвкодинг / задача в реал-тайме
— Уже лучше
— Можно посмотреть ход мышления, но стрессово
✅ Хорошо, но требует хорошей подготовки интервьюера

3. System Design (моя любовь)
— Это не задача «реши», а задача «подумай»
— Человек может прийти с наработками, заметками, вопросами
— Вы обсуждаете, спорите, уточняете
— Видно не только знание, но и стиль мышления

А главное — одну и ту же задачу можно использовать на всех:
и на аналитика, и на разработчика, и на лида, и на продакта.

💬 И еще один важный нюанс
Если человек говорит:
«я не успел подготовиться» —
норм (не стрём)!!!
Дайте ему шанс подумать и подвинуть встречу. Это честно.

Если он говорит:
«не было времени, но прочитал и набросал пару идей» —
уже супер.

Если приходит и говорит:
«что за задача?» — баста, карапузики! Отпускаем кандидата с миром и идем работать и нанимать дальше! Это очень многое говорит об отношении.

📌 Вывод?
Век ИИ, шаблонов и тренажеров по прохождению собесов — нужны форматы, в которых люди думают, а не угадывают.

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

🎣 Правда ли, что людей много, а брать некого?

Кажется, рынок перегрет. Резюме много, вакансий меньше, люди ходят по кругу.
Но вот парадокс — искать «того самого» по-прежнему трудно.
Почему? Потому что резюме ≠ кандидат, а люди на рынке ≠ люди, которых ты готов взять к себе в команду.

Когда я увольнялась с предыдущего места и чистила ноутбук, нашла у себя папку с более чем 100 резюме.
И, внимание: я не HR. Не рекрутер. Просто нанимающий менеджер.

Эти резюме не от внутреннего подбора, не из автоматических воронок, не из агентств.
Они — от:
— коллег,
— людей из нетворка,
— самих кандидатов, которые писали напрямую или через кого-то.

📌 Почему работают рекомендации и рефералки?
Когда тебе рекомендуют кого-то, кого знают в работе, или кто прошел через твой личный опыт — это совсем другая "лига" кандидата, так как:
— фильтрация проходит еще до первого касания;
— контекст: ты знаешь, в каких условиях человек силен;
— в 100% случаев — это живое общение, а не формальное «сбрось CV».

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

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

📢Туповый вывод, звучащий из каждого утюга:
Если ты нанимающий — строй нетворк.
Если ты просто в профессии — заводи «свою базу» тех, кто имеет сильные скилы и кого можно рекомендовать!

Когда тебя спросят «а кого бы ты порекомендовал?» — у тебя будет не «ой, щас подумаю», а список имен с пониманием, кто на что способен.

💬 А вы часто получаете или даете рекомендации?

PS Если что, это вообще подводка к тому, что классические собесы "вымирают", резюме после появления AI стали бесполезны и зачем нам всем System-design как часть этапов найма... Завтра про это начну рассказывать

🕰 Пост без морали. Только про время, тревогу и жизнь.

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

"Я РЕШИЛ ЖИТЬ ВЕЧНО ПОКА ВСЁ ИДЁТ ХОРОШО" (с)

Знаете, я даже не ожидала, что меня так накроет. Этот пост, на первый взгляд простой и «психотерапевтичный», оказался очень сложным для меня лично.

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

Для меня эта тема особенно тревожная. Потому что я слишком рано поняла, что жизнь конечна.
Не в каком-то романтическом или трагичном смысле. Просто… как есть.
И с тех пор меня время от времени догоняет ощущение, что я не успеваю. Что я трачу время «не туда». Что я сжигаю минуты впустую.

Живя сейчас на юге, я все чаще замечаю, как люди тут не спешат. Они как будто не измеряют жизнь в минутах, а принимают ее — текущей, текучей, как море: без графика, но с течением.
Это не про «ленивость» или «апатию». Это философия.
Просто очень несвойственная подходу людей из больших городов.

Таня в ответ на мой комментарий написала важное:

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

И правда — не все готовы туда смотреть. Да и не всегда стоит туда смотреть в одиночку.
Иногда лучше взять чью-то руку или пойти к специалисту. Не потому что «ВСЕ ПЛОХО»,
а потому что внутреннее взросление — не марафон, где дают воду на каждом километре, а в конце тебя ждеь медалька.

Да, это пост без морали и выводов. Без «10 способов пережить экзистенцию».
Просто рефлексия...

📚 Жопа есть, и слово есть! 🍑

Продолжая тему лингвистики и мягких органических остатков!

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

«Ну вот, теперь и “жопа” нельзя».

Ан нет. Можно!
Роскомнадзор дал пояснения: Слово «жопа» само по себе не считается нецензурным.
Маркировать контент как 18+ за его использование — не требуется.

📌 А значит, если вы:

— оказались в жопе мира,
— вокруг вас жопная архитектура,
— или просто почувствовали себя жопно,

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

Так что РОСКОМНАДЗОР официально заявляет:
✅ Жопа — разрешена!

🛎️ Эскалационные планы. То, чего у меня раньше не было. И то, без чего теперь не представляю работу. ☑️

Завершая серию про INC...

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

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

И это реально game-changer. Особенно когда ночью, особенно когда прод, особенно когда алерт летит не в одну, а сразу в несколько команд.

🔧 Из чего состоит эскалационный план

1️⃣ Level = Уровень критичности.
Выбирается один из предопределенных:
🟥 Blocker — будим всех, даже в выходной, даже ночью.
🟧 Critical — реагируем немедленно, но в рабочее время.
🟨 Major / Normal / Minor — плановое реагирование, включение в работу через приоритизацию.
Важная фишка — учет выходных: если алерт случается в пятницу или перед длинными выходными — он может перескакивать в более высокий уровень, потому что просто ждать понедельника нельзя!

2️⃣ Event = Формулировка самого алерта
То сообщение и место его публикации, которое запускает всю цепочку.

3️⃣ Event Description & Printscreen
Расширенное описание:
— на что конкретно настроен алерт (обязательно указание сервиса, механизма, направления),
— на что он влияет — влияние на бизнес, мерчантов, пользователей, отчеты, финансы, процессы, и т.д.,
— скриншоты из систем мониторинга (Графана, Кибана и др.), чтобы даже в полусне понять: да, это оно!
Важно учесть, что первыми, кто будут читать и проверять алерт - будет команда мониторинга, а они могут не знать тонкостей и особенностей работы каждого сервиса!

4️⃣ Event Flow — уровни эскалации
Это самое важное — что происходит после алерта, кто включается, и в каком порядке.
Уровень 1: Мониторинг (обязательный)
Коллеги получают сигнал и:
— проверяют ключевые метрики,
— выполняют первичную диагностику (например, “живо/не живо”, “ошибки растут/не растут”),
— принимают решение: нужно ли эскалировать дальше,
— документируют происходящее.
Уровень 2: SRE или команда (вариативный)
Если мониторинг передает эстафету — подключается:
✅ SRE — у них есть доступ к продакшену, и они могут:
— дособрать информацию (логи, текущие состояния, доп. графики),
— выполнить ручные или полуручные стабилизирующие действия,
— передать все это в команду с комментарием "готово к разбору".
✅ Команда — основной владелец сервиса/фичи.
План должен включать:
— четкие шаги: что проверять, куда смотреть, в каком порядке,
— если нужен другой отдел/команда/бизнес — план, как их привлекать,
— стабилизационные действия на случай, если полноценный фикс не может быть выполнен сразу.

5️⃣ Links & Resources
Ссылки на нужные источники: Графана, Кибана, БОФ, админки.
Справочные материалы:
— как работает сервис,
— какие у него зависимости,
— какие проблемы могут вызывать этот алерт.
Примеры прошлых инцидентов:
— с похожими симптомами,
— что помогло тогда,
— что можно применить снова

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

🔄 А что делать, если алерт задевает сразу несколько команд?

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

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

📌 Эта практика кажется объемной только в начале. Но потом — просто становится новым стандартом.
Ты не пишешь ночью в три чатика и не собираешь непонятно кого, а открываешь эскалационный план. И делаешь.

💬 А у вас есть такие планы по алертам?
Кто их составляет? Кто обновляет?

🚦 Почему трехуровневая система критичности — это светофор, который собирает пробку? 🚛🚐🚗

Окей, с процессом разобрались. А теперь давайте честно — как часто вы сталкивались с инцидентами, у которых критичность определена на глаз?
Формат:

ну, наверное, желтенький

или

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

Проблема в том, что если у вас только три уровня критичности, вы в какой-то момент приходите к следующей модели:
🟥 Срочно — делаем сейчас
🟨 Когда-нибудь — делаем потом
🟩 Не очень надо — не делаем вообще

Поздравляю, это не градация, это светофор.
Но процесс не едет. И организация не учится управлять рисками.

Почему нужны либо 2, либо 5 уровней?
🛴Если инцидентная зрелость только начинает формироваться — вам подойдет двухуровневая шкала:
🟥 Срочно (вплоть до ночного пробуждения)
🟩 Можно дождаться рабочего дня
Этого достаточно, чтобы разделить срочные действия от запланированных, не перегружая команды лишними категориями.

🚀 Но если вы хотите управлять приоритетами системно, расти в инженерной зрелости и отделять шум от сигнала — вам нужны пять уровней, например, такие:
1️⃣ Blocker — критичное влияние на бизнес / продуктив полностью не работает
→ будим команды в нерабочее время
2️⃣ Critical — сильное влияние, но есть обход или частичное восстановление
→ реагируем сразу, но в рабочее
А дальше 3 приоритета планируемого и управляемого процесса:
3️⃣ Major — серьезная, но не блокирующая проблема
→ учитывается в приоритизации, но через планирование
4️⃣ Normal — умеренное влияние, можно жить
→ работаем в рамках спринта или roadmap с учетом остальных приоритетов, не "двигает" бизнес-задачи
5️⃣ Minor — косметика, неудобство, замечено только командой
→ берем когда появилось время и основные задачи закрыты

💡 Что дает система с пятью уровнями?
— Позволяет точно управлять ожиданиями (бизнеса, саппорта, клиентов)
— Помогает выстраивать SLA на устранение влияния
— Делает инцидент-менеджмент предсказуемым
— Отделяет шум от системных уязвимостей
— И, главное, не превращает все в "сделайте вчера"

И да — между «будим в 3 часа ночи» и «сделаем когда-нибудь» есть очень много оттенков.
Но чтобы их видеть, нужна не только культура разбора, но и язык, который точно передает приоритет. А еще очень много инженерной воли, которая вам поможет соблюдать и выдерживать SLA, контролировать приоритеты и "задалбывать" команды...

💬 А как у вас устроена шкала критичности? Есть ли понимание, что Blocker ≠ Critical?
Или все как в старом добром кино про березы и пальмы: "ну поставь красный, чтобы дошло до релиза"...?

🪟 Почему команда не может быть себе судьей

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

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

Проблема в том, что команды часто воспринимают инцидент как:
⚙️ техническую неисправность в своей зоне ответственности,
🔥 которую нужно по-быстрому потушить,
🤐 и как можно меньше о ней говорить.

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

Почему нельзя разбирать инцидент только внутри команды?
1️⃣Оптика искажения
Команда видит мир через призму своего контекста.
➤ Риски: не увидят пересечений, недооценят масштаб, пропустят системную причину.

2️⃣Конфликт интересов
Инциденты бьют по репутации. Команда заинтересована «исправить быстро и забыть», а не «разобраться до дна». Это нормальный человеческий механизм — защищать свою зону. И стоит незабывать про страх наказания.
➤ Риски: поверхностный разбор, уход от настоящей причины, повторение инцидента в будущем.

3️⃣Отсутвие прав на технилогическую волю
Команда отвечает только за свой кусок. Но инциденты часто возникают на стыках — между сервисами, командами, техдолгами, фичами и процессами.
➤ Риски: никто не берет ответственность за весь сценарий, решение становится «размазанным».

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

🧭 Что с этим делать?
Создать структурированный и централизованный подход к инцидент-менеджменту, в котором есть два критически важных элемента:

1. Внешний наблюдатель (incident-лид, мониторинг, 3я линия)
Это не контролер и не прокурор.
Это нейтральная сторона, чья задача:
— видеть инцидент целиком;
— задавать неудобные, но нужные вопросы;
— фиксировать все, что обычно забывается;
обеспечивать, чтобы разбор был не для галочки, а с эффектом.

2. Единое окно регистрации и отслеживания инцидентов
Зачем?
— Потому что один инцидент может затронуть несколько команд, и если каждая будет вести учет в своём чате — связи не проявятся.
— Потому что объективное понимание хронологии событий невозможно без единого журнала.
— Потому что распределенная ответственность — это отсутствие ответственности, если нет координатора и общей картины.

🧠 Что считается «завершенным» инцидентом?
Не тогда, когда все снова заработало.
Это — только уборка последствий.

Завершенный инцидент — это когда:
1️⃣ Устранено влияние на прод (в рамках SLA)
2️⃣ Принят и согласован план митигации:
— краткосрочный (временное решение, обход, перестройка нагрузки);
— долгосрочный (архитектурные/процессные изменения, доработка мониторинга, новый алерт).
3️⃣ Проведен анализ (вариант - тот самый PIR), и выводы заложены в продуктовую или техническую стратегию.

🎯 Зачем все это?
Инцидент — это не ошибка.
Это сигнал, что система работает не так, как мы думали.

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

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