drugoi.dev | Никита Баев о разработке, техлидстве и менеджменте

🖥 О новых ролях в эпоху AI разработки Увидел твит Бориса с интересной мыслью, которую мы стабильно обсуждаем в последнее время в AI чатах: по мере того как разработка, управление продуктом, дизайн, аналитика и другие роли начинают смешиваться, привычные названия должностей всё хуже и хуже передают то, чем фактически занимается человек в команде. Борис пишет, что вполне возможно, что будущие продуктовые команды будут описываться не столько через функции сколько через тип вклада, который человек приносит в конкретный момент жизни продукта. Как итог, команда будущего может выглядеть примерно так: Prototyper — быстро находит новые идеи, собирает много черновиков и экспериментов. Большая часть не доходит до прода, но именно здесь рождаются новые направления. В текущем мире, один из самых важных типов сотрудников, т.к. скорость сейчас как никогда важна. Builder (мой любимый тип) — превращает идею или прототип в рабочий продукт. То, что последний год называлось “вайбкодингом” уже давно переросло в агентское программирование и builder — это та роль, которая в большей степени эксплуатирует множество агентов. Sweeper — упрощает интерфейс, чистит код, убирает лишнее, оптимизирует производительность и снижает сложность системы. Разработка с помощью AI с одной стороны очень сильно ускоряет процесс, а с другой стороны, без должного внимания, создаёт большое количество ненужного и плохого кода. Grower — берёт уже запущенный продукт и итеративно улучшает его, усиливая product-market fit. Maintainer — отвечает уже за зрелую систему. Работает с безопасностью, надёжностью, эффективностью и масштабированием самой системы. Да, все эти роли пересекаются, но что мне нравится в этой модели: она не привязана жёстко к профессии. Дизайнер может быть сильным builder-ом или sweeper-ом. Инженер — grower-ом или maintainer-ом. Аналитик — не только человеком со страницами в Confluence, а участником zero-to-one поиска или оптимизации зрелого продукта. Пройдёт ещё время, прежде чем команды начнут трансформироваться повсеместно, но стоит признать, что все эти новые типы скорей будут не постоянными в команде. В зависимости от этапа развития, может быть что-то такое: — новый продукт до PMF: больше prototyper + builder + sweeper — растущий продукт после PMF: builder + sweeper + grower — зрелый продукт с сильным PMF: sweeper + grower + maintainer А к кому бы вы причислили себя уже сейчас? @drugoi_dev

Cursor Developer Habits Report 2026 Отчётов по реальному использованию AI с большими выборками достаточно мало, но тут Cursor выпустил первый Cursor Developer Habits Report на основе данных за последние 2 года. В отчёте хорошо видно, как AI меняет разработку не в теории, а на деле. И самое главное, о чём мы говорим постоянно: 1. Разработчики начали двигаться быстрее 2. AI постепенно переходит от простого помощника к автоматизации частей SDLC Не буду разбирать весь отчёт, но есть две темы, которые мне больше всего зашли Про продуктивность разработчиков Самый очевидный эффект — разработчики стали производить больше изменений. По данным Cursor: — количество добавленных строк на разработчика в неделю выросли примерно с 3.6K до 8.6K — по p75 рост строк добавленных в PR — примерно со 126 до 345 строк — доля PR с 1000+ изменённых строк — с 8% до 13.8% — среднее число tool calls в агентских сессиях выросло примерно на 30% за два месяца — выживаемость (сколько кода не удаляют) AI-кода вырос с 76% до 81% Да, строки кода вообще не идеальная метрика. Больше кода не всегда значит больше ценности. Но здесь всё таки важен не сам объём, а изменение самого формата работы. AI позволяет разработчику брать более крупные куски задач: не просто “поправь компонент”, а полноценный (и масштабный) рефакторинг, миграцию, тесты, подготовку PR целиком. То есть ускорение происходит не только на уровне скорости набора кода . Меняется размер обычной работы. Если раньше команда могла управлять потоком небольших задач и PR, то теперь AI помогает быстрее генерировать более крупные изменения. А значит, код-ревью, QA/тесты и даже архитектурные правила должны масштабироваться вместе с ними. Иначе всё это ускорение легко превращается в ускоренное накопление хаоса. Про автоматизацию разработки Вторая тема ещё интереснее. AI инструменты разработки начинались как инструменты для ускорения отдельного разработчика: автокомплит, чаты, генерация кусков кода, помощь с тестами. Но сейчас видно движение в другую сторону: AI становится инфраструктурой для автоматизации разработки через агентов. Доля изменений, которые доходят до коммита без отдельной ручной проверки кода, выросла с 7% в начале 2026 до примерно 36% в мае. Правда это не значит, что код-ревью больше не нужен (хотя во многих случаях его уже можно избегать). Скорее наоборот: код-ревью становится важнее, но меняет уровень. Уже нет смысла (и физических возможностей) человеку проверять каждую строку руками, важно создать правильные условия для безопасной разработки. То есть роль разработчика сильно смещается от «я пишу весь код сам» к «я управляю огромным потоком изменений и качеством результата». А вот роль технических менеджеров меняется от «как ускорить людей» к «как построить систему, где люди и агенты безопасно релизят продукты». Что это значит для команд Для меня главный вывод, примерно, звучит так: AI adoption в разработке — это история не про купить лицензии и провести воркшоп. Это уже вопрос операционной модели компании/команды. Если AI увеличивает объём и размер изменений, то нужно пересматривать: — как мы декомпозируем задачи — как ревьюим большие PR — какие проверки автоматизированы — какие части SDLC можно отдавать агентам — как измеряем эффект — как контролируем стоимость всего этого AI балагана — как растим power users агентов — как даём AI правильный контекст: код, требования, документацию и другие внутренние стандарты Разработка — это не только написание кода. Это понимание задачи, архитектура, качество, безопасность, поддерживаемость, релизный процесс и ответственность за результат. Если инженерная система слабая, то AI просто ускорит хаос. Если же она зрелая, то AI станет реальным мультипликатором. Сам репорт доступен по ссылке — https://cursor.com/insights @drugoi_dev

📄 Про отношение к резюме Я за годы работы и найма просмотрел сотни резюме и Linkedin профилей разработчиков. И всё чаще замечаю одну проблему: многие пытаются сделать из профиля витрину из ключевых слов, AI слопа и бесконечного списка технологий. Да, мы живём в эпоху ATS, AI-скрининга и авторазборов резюме. Но, несмотря на это, решения о найме всё ещё принимают люди. И восприятие кандидата складывается не только из совпадения по ключевым словам. Несколько вещей, которые всё ещё влияют на то, как выглядит разработчик на рынке: 1. Одностраничное резюме всё ещё лучше всего остального Резюме не должно превращаться в ваш бэклог из JIRA. Никто не хочет читать 14 пунктов про «фикс бага XYZ-256». Лучше меньше, но с акцентом на результат и его влияние. Если достижений много, то можно вынести отдельно к себе на сайт или страницу на GIthub. Вы всё равно обсудите это ещё на собеседовании. 2. Личный сайт всё ещё выделяет (но it depends) Шаблон с прогресс баром, который показывает ваши знания технологий никому не нужен. Намного интереснее видеть проекты, мысли, подходы к разработке и интересы. 3. Активный GitHub важнее красивого README-профиля Один живой и понятный проект производит лучшее впечатление, чем стена бейджиков из технологий 4. Адаптируйте профиль под компанию Стартапы смотрят на инициативность и способность быстро делать задачи, а корпораты — на процессы, стабильность и масштаб. Универсальное резюме редко работает идеально везде. 5. В 2026 году уже странно не упоминать AI Не потому что «агенты заменят разработчиков», а потому что подход к работе УЖЕ поменялся. Использование AI-инструментов становится такой же базой разработки, как Git или CI/CD. 6. Самые запоминающиеся кандидаты — не всегда самые "идеальные" Часто цепляет что-то человеческое: хороший личный проект, блог, выступления, вкус к продуктам, интерес к технологиям, да даже список любимых книг или фильмов. У нас маленький рынок, не сегодня, так завтра вас могут вспомнить и позвать на работу. Сейчас на одну позицию могут приходить сотни (а где-то и тысячи) откликов. С одной стороны работодатели укрываются ATS и авторазборами резюме, а с другой стороны кандидаты генерят автоотклики даже не вдаваясь в подробности вакансии. Сейчас недостаточно просто «писать код». Важно быть человеком. И чем лучше вы, как человек, тем больше вероятность, что вас возьмут @drugoi_dev

🔊Про выступления Я не так часто выступаю, потому что считаю, что лучше создавать условия для того, чтобы выступали другие, чем занимать эфирное время, но так получилось, что за прошедшие две недели мне довелось выступить на AlmatyJS Light от 42 Meetups и в Terricon Valley в Караганде. Оба митапа прошли под влиянием AI, на AlmatyJS (который впору назвать AlmatyAI) я рассказал вводную историю про скиллы и как их готовить в команде — https://www.youtube.com/watch?v=LQKAl2mj16U А уже в Терриконовой долине мы обсудили, как менятся работа разработчика в 2026 году, как на это влияет AI и что мы ждём от кандидатов — https://www.youtube.com/watch?v=2ckiV4MaTAU Подготовка к митапам это всегда повод глубже погрузиться в тему, узнать что-то новое и выйти на новый уровень. Поэтому я всегда советую людям, что если они хотят стать лучше, то один из способов — это выступить перед публикой. @drugoi_dev

👷‍♂️ Мини-проект: diddo — что я сделал вчера? Вчера мы в чате с разработчиками обсуждали проблему, что в век AI агентов очень сложно удержать в голове, чем фактически ты занимался вчера или на этой неделе. И мне пришла идея — почему бы просто не записывать всё, что я делаю через git hooks. Просто и элегантно. Так и появился проект diddo. Да, можно смотреть лог проекта, но я сам сейчас работаю над несколькими рабочими и личными проектами. Зачастую даже без таск-трекинга. Поэтому контекст удержать бывает сложно. Thanks AI gods, что мы теперь можем делать проекты, пока пьём кофе и проводим время со своими близкими. Проект был сделан полностью агентами в Cursor (про свой воркфлоу я напишу отдельный пост) вместе со всеми тестами и проверками. Из коробки работает с установленными у вас агентскими CLI, но можно и подкинуть свой ключ к OpenAI. Дейлик через пару минут, а ты не помнишь, что делал вчера? — diddo yesterday расскажет (пока без text to speech 😉) Мне очень нравится, как с AI я могу делать то, что раньше у меня бы заняло дни или даже недели разработки всего за пару часов. Работает на MacOS (проверено), Windows и Linux (нужна верификация). Заводите issues и открывайте PR, если хотите что-то улучшить — https://github.com/drugoi/diddo-hooks Установка простая: brew tap drugoi/tap brew install diddo @drugoi_dev

🧑‍💻 Стал Cursor Ambassador Недавно официально стал Cursor Ambassador и это для меня не бейджик в профиле (хотя приятно), а новый вектор: теперь я буду делать больше мероприятий вокруг агентского кодинга — митапы, воркшопы, хакатоны. Почему вообще это важно? За последние пару лет у нас реально сменилась парадигма: от «Редактор подсказывает следующий символ» к «я описываю цель, ограничения и контекст, а агент делает работу». В 2022-23 годах мой основной режим был простой: Copilot + tab-подстановки и чуть-чуть автодополнения. Сейчас всё иначе: большую часть задач я делегирую агентам — от черновиков решений и рефакторинга до генерации тестов, миграций и прототипов. Я всё ещё держу направление и ответственность, но исполнение всё чаще уходит другие руки. Отдельно символично, что интерес к этому направлению у меня сильно вырос после доклада Марка на AlmatyJS Light #5 x Altel Digital (28 ноября 2024) — «Эволюция ИИ помощников для разработчиков». Марк показал там Cursor не как “игрушку для автокомплита”, а как инструмент, который начинает приносить ценность, когда ты умеешь ставить задачу и принимать результат как инженер. Дальше — больше, как говорится. Будем собирать комьюнити вокруг практик: как писать спецификации под агентов, как проверять результат, как строить процесс, где почти готово — это действительно только начало, а не конец. Для поддержки казахстанских пользователей решил завести отдельное сообщество без привязки к направлению разработки, там же будут и анонсы мероприятий и других активностей — https://t.me/cursor_kz @drugoi_dev

🔑 Оказывается, софт-скиллы, важны Долгое время в продуктовых командах разработчики жили в парадигме «дайте задачу и я напишу код». И я до сих пор вижу, как многие ставят полностью на хард-скиллы, будто этого достаточно. Но в 2026 году это уже так не работает, к сожалению. Я всё чаще замечаю, что разработчики, которые умеют ясно формулировать мысли (особенно в тексте), начинают превосходить тех, кто просто “хорошо пишет код”. Не потому что код стал неважен, а потому что спецификация становится обязательным этапом разработки. С агентами для разработки есть важный момент: чем точнее спецификация, тем ближе результат к техническим и бизнес-требованиям. Проблема в том, что хорошую спецификацию почти никогда не приносят готовой. В реальной жизни задачи, зачастую, редко содержат все требования. Чтобы их прояснить, часто нужно: — задавать вопросы, которые вскрывают неочевидные корнер кейсы; — убирать избыточность требований (помним же про принцип YAGNI?), но не сжигать мосты; — принимать решения там, где никто даже не подумал зафиксировать требования. И что же нам нужно прокачивать уже сейчас, чтобы не получать отказы на собеседованиях и превосходить других разработчиков? Научитесь уточнять контекст задачи Спрашивайте не «что сделать?», а «какая проблема решается?». Очень часто «невероятно важная задача» в итоге превращается в фичу, которой будет пользоваться один клиент (это в лучшем сценарии). Задавайте неудобные вопросы Часто именно там скрыты риски и несостыковки. Не бойтесь показаться душнилой, но не будьте токсичным. Хорошие, пусть и неудобные, вопросы (мой пост про это) — это драйвер качественного обсуждения задачи и проекта. Умейте фасилитировать и доводить свою точку зрения Если вы хотите стать лидером, то умение сводить разные интересы к рабочему решению — очень важный навык. А умение донести свою идею так, чтобы никто не поругался, так вообще основной пункт в чеклистах на собеседованиях лидов. Развивайте эмпатию Без неё коммуникация превращается в обмен сообщениями, а не в совместное решение задачи. Ставьте себя на место своего коллеги, пробуйте вникнуть в проблему и ситуацию. Вы идёте к одной цели вместе, а не по одному. @drugoi_dev

👷‍♂️ Про смену парадигмы «Code is cheap now…» — в последнее время я часто слышу эту фразу. Из-за которой я всё больше задумываюсь о роли разработчиков и том опыте, через который я прошёл за эти 13 лет. В начале карьеры я любил верстать. Мне нравилось делать интерфейсы, хотя тогда это не были интерфейсы, это скорее были какие-то сайты, лендинги бесконечные, промо-проекты и так далее. Не всё получалось сразу, много приходилось бороться с поддержкой разных браузеров, а с повсеместным развитием смартфонов ещё и с адаптивной версткой. Рабочий процесс был таким: сначала верстаешь макет смотря на него в Adobe Photoshop, потом выгружаешь PNG, открываешь расширение PixelPerfect для Chrome, сравниваешь размеры, пытаешься подогнать шрифты, паришься с проблемами, что там у некоторых юзеров Internet Explorer или еще что-то. Сейчас, конечно, этого нет. Помню даже искал макеты на Dribbble и верстал их для тренировки, а потом добавлял эту верстку как пример проектов в своё резюме. Тогда это казалось важным и служило неким показателем скилла разработчика. И я задумался о том, что разработка, из-за которой я пришел в индустрию — меняется, причём стремительно. На днях в чате начинающий верстальщик поделился лендингом, который он сверстал. Скорей всего у него заняло это 1-2 дня, может чуть меньше. Из интереса я решил повторить этот лендинг с помощью Cursor и почти готовая к релизу страница была готова примерно за 2 минуты. Заполнить контентом и можно заливать на хостинг. Стоимость? 20$ за месяц, но на эту сессию я потратил, наверное, меньше 1$ в токенах. Подключаешь Figma MCP, выбираешь Codex или Opus, пару минут и твой дизайн готов в коде. Были дни, теперь минуты. И мне кажется, что сейчас очень интересное время для того, чтобы улучшить себя, для того, чтобы найти что-то новое в своей же сфере. Я очень рад, что я стал менеджером в прямом и переносном смысле, потому что всё-таки говорить агентам, что делать, намного приятнее, чем самому что-то делать. Фундаментальные знания важны, но ещё важнее сейчас — быть гибкими ко всему тому новому, что появляется в нашей индустрии. Быть в отрицании сейчас — это считай признать, что твой пик, как разработчика уже позади. Да, от шума вокруг AI устаёшь. Но когда есть модели, которые пишут код примерно так же, как я пару лет назад, делают это в разы быстрее и почти не отвлекаются — игнорировать их использование просто нерационально. Полная версия фразы звучит так: “Code is cheap now. Software isn’t.” Мы всё ещё нужны — возможно, пока. Но наша роль меняется. И чем раньше мы это примем, тем быстрее сможем извлечь пользу из новых моделей и инструментов. @drugoi_dev

📅 Как оставаться продуктивным Всегда приятно получать какую-то внешнюю валидацию того, что те подходы, которые ты уже используешь в работе — также используются людьми из индустрии. А иной раз приятно найти что-то новое для себя и сразу взять в работу. На днях на глаза попался гайд Марка Андриссена из фонда a16z по продуктивности. Хотел бы сделать небольшой разбор этого списка со своими комментариями. Итак, гайд Марка Андриссена по продуктивности 1. Не ведите расписание* и избегайте обязательств по будущим встречам, чтобы в любой момент работать над самым важным и/или самым интересным. Наверное, для многих людей в найме это один из самых сложных пунктов. Запланированные встречи, дейли стендапы и другие обязательные мероприятия гибких методологий разработки 😉 Когда есть команда, то сложно отказывать, но попробуйте проанализировать, насколько вы нужны были на каждой из встреч, проведённых на прошлой/этой неделе? Зачастую люди злоупотребляют возможностью собрать встречу, хотя многие вопросы можно решить в тексте и асинхронно. *важная ремарка, что Марк расписание как таковое ведёт, но с важным условием наличия фокусного времени для себя и проектов, которые его волнуют и с определённым ритмом недели (спокойные и активные дни). 2. Только три списка: Todo (Must Do) / Watch / Later. Раскладывайте задачи по этим категориям. Я обожаю списки, но у меня их больше. Какие-то физические (планер для своих дел и дома, список рабочих задач на день/неделю), какие-то онлайн (чтение, фильмы, идеи и т.д.). Пока я нахожу комфортным для себя жить в такой парадигме. Да, иногда достаточно широкий выбор, что сделать дальше, но это выравнивается внутренними настройками. 3. Каждый вечер готовьте карточку 3×5: выпиши 3-5 важных задач на следующий день. Марк просто берёт что-то, что у него лежит в списке Todo и на следующий день изо всех сил (I try like hell) пытается сделать то, что было запланировано. У меня же, обычно, план есть с начала недели, но корректировки всегда бывают и этот вечерний чекап выглядит как хорошее дополнение к моим практикам. Стоит признать, внутреннее ощущение от того, когда ты выполняешь запланированные задачи — очень приятное. 4. Ведите Anti-Todo список: записывайте достижения в течение дня для мотивации. Если честно, я несколько раз пытался делать похожую практику, только не в момент времени, а ретроспективно, но так возникает проблема, что если ты за неделю сделал много всего — всё в голове не упомнишь. Планирую добавить эту практику в свой день, чтобы лучше понимать, в чём мой фокус был сегодня. 5. Практикуйте структурированную прокрастинацию: используй склонность откладывать дела, чтобы закрывать другие задачи. У Андриссена это один из самых “честных” приёмов: если избегаете большого страшного — используйте это свободное время, чтобы закрывать полезные мелочи. Да, тут можно попасть в ловушку и избегать большие задачи очень долго, поэтому основное правило в том, чтобы сделать сначала Top 3 задачи из ToDo, а затем уже структурированно прокрастинировать. 6. Применяйте стратегическую некомпетентность: избегайте нежелательных задач, выглядя в них «не очень компетентным». Звучит смешно, но есть вопросы, где лучше притвориться, что вы не можете взяться за что-то и потратить время на то, что вам интересно и важно. Вполне нормально отказать или направить человека к другому человеку, если это не ваша зона ответственности. Но осторожно, если делать это на постоянной основе и для большого количества запросов — возможно, вас захотят заменить. Остальные пункты в полной версии поста → https://drugoi.dev/how-to-be-productive/ Вместо послесловия, поделитесь лучше, какие пункты у вас работают? Какие раздражают? Что пробовали из этого? @drugoi_dev

👤Про AI Adoption в 2026 году На глаза попалось письмо Дэвида Крамера, фаундера Sentry, про AI adoption внутри компании. Сначала я хотел разобрать его и добавить свои заметки для внутреннего комьюнити в банке, но решил, что это скорее тянет на пост в мой блог. 2026 год — год, когда всем надо привыкнуть к LLM Стоит признать, что если вы сейчас не используете LLM-ки на ежедневной основе, то вы, скорее всего, проигрываете. Как сотрудник, как компания, как человек. Да, есть нюансы, но отрицать сейчас факт, что наша работа меняется и старым подходам как к разработке, так и ко всему другому уже не место — это, как минимум, глупо. В банках всё сложнее, но это нормально В контексте банков, конечно, не всё так просто, как хотелось бы. Наша основная задача сейчас это безопасное и измеримое применение, при этом учитывая различные регуляторные требования. Мы над этим работаем, и самый дефицитный ресурс здесь — время: на обучение, на настройку процессов, на встраивание инструментов в повседневную работу. Самый главный ограничитель для многих компаний, пока что, это цена на подписки и в целом цена доступа к моделям. В самом Sentry признают этот факт и пока решили, что с этим можно разобраться потом, т.к. важнее сейчас скорость. Как говорится, желаю всем компаниям, прийти к этому. Личный пример — лучший драйвер Крамер в своём письме рассказывает о своём опыте использования agentic coding инструментов. Несмотря на то, что его роль в Sentry это не про написание кода, агентское программирование позволило ему снова влиться в разработку, находить уязвимости безопасности и даже сделать Sentry MCP. Всё-таки один раз разработчик — всегда разработчик. И если тебя драйвит то, что делаешь, то такие инструменты реально возвращают тебя в “седло”. Как замерять? Для многих это спорный момент, но рост AI сгенерированного кода — основной показатель adoption. Да, важно проводить черту, когда код ради кода и когда он действительно полезен. Но уже сейчас есть уйма инструментов, как можно нивелировать эти проблемы. Да и code review никто не отменял. Мы уже замеряем этот показатель и в этом году будем внимательнее следить за тем, как он растёт в различных командах. Это не основная метрика, но достаточно важная в контексте внедрения AI инструментов в компании. Про ожидания сотрудников и луддизм Забавно, но буквально за пару часов до этого обсуждали этот вопрос с коллегой. Даже в нашей среде разработчиков до сих пор есть люди, которые выдают что-то в духе: «Да этот AI ничего путного сделать не может». Как и с любым инструментом, с AI/LLM нужно научиться работать. Да, это занимает время и вам нужно выходить из зоны комфорта, но выхлоп, который можно получить в итоге намного выше вложений времени. Убрать рутину, высвободить время на более интересные задачи и, даже, улучшить качество жизни за счёт более лёгкого подхода к задачам. Ваша доменная экспертиза никуда не уйдёт, никто, пока что, не собирается заменять вас на бездушных роботов. Но если вашу работу можно делать быстрее и комплекснее, то это нужно принять как фокус для развития и быть впереди остальных по использованию новых инструментов. @drugoi_dev

🌳 Как расти в 2026 году Второй пост из серии разборов вопросов, которые мне задавали в форме по менторству. Сегодня хотелось бы забрать группу вопросов, которую можно объединить в один мета-вопрос: «Хочу роста, но внутри компании непонятно как» Стоит признать, что во многих компаниях рост не является системным процессом. Иногда это невыгодно экономически, иногда — нет ресурса (человеческого) для того, чтобы этим заниматься. Чаще всего люди растут вопреки, а не потому что. Но это не страшно. Это возможность для вас стать лучше и достигнуть более высокого уровня в условиях относительного хаоса. Рост — это инициатива снизу, а не бонус сверху Было бы здорово, если бы в каждом месте работы, где я работал, была понятная дорожка, как дойти от Junior разработчика до C-level, но пока что основной путь в большинстве компаний — это пробиваться самому. В прошлом посте мы с вами обсуждали про важность поиска новых задач для себя, чтобы развивать в себе эксперта. Поэтому не буду задерживаться тут, но если мы говорим про локальные компании, то быть на виду — важная часть вашей ежедневной работы. Правда помните, что “на виду” = видимый вклад и ответственность, а не активность ради активности. Например, если вам пришла идея поменять правила линтера и залить это одним PR без обсуждения, то в 99% случаев это вызовет негодование ваших коллег, а вот починить падающие тесты или наконец-то написать документацию по релизу — это хорошие примеры для проактивности. Помните, что никто не будет быстро повышать человека, у которого в послужном списке «ходил на дейлики, делал задачи». Значит, инициативу придётся брать на себя. Мы уже обсуждали это с вами ранее, но просто напомню, что эта инициатива может быть очень разной: от оптимизации CI/CD до создания внутреннего комьюнити по решению алгоритмов. Выбирайте инициативы, которые убирают боль команды и дают измеримый результат, либо делают вас сильнее как эксперта. Если зона ответственности не расширяется — ваш уровень не растёт Сравните себя в первый день/неделю/месяц работы и сейчас: • Что вы стали делать лучше/больше с того момента? • Что вы стали делать, что изначально не планировали? Если хотя бы на один из этих вопросов есть какой-то ответ, то вы идёте вперёд. Если же вы пока не можете ответить на эти вопросы, то сейчас самое время подумать над этим и взяться за что-то новое или улучшить уже существующий процесс в своей работе. Если где-то вы слышите фразу в духе «мы так привыкли», то это сигнал для вас, что можно что-то поменять. Пока вы на уровне IC, получить быстрые победы можно намного проще. А там, где победы, там и ваш рост и дополнительные плюсы для резюме. Если не знаете, с чего начать, то просто возьмите одну боль вашей команды, которая каждый раз мешает вам достигать цели быстрее: релизы, тесты, CI, документация, мониторинг. @drugoi_dev

ℹ️ Как не быть Junior-ом Исторически, начало года для меня всегда про какое-то улучшения себя, обучение и развитие. Недавно я спрашивал у вас вопросы, которые вы бы хотели задать мне и в этом посте хотел бы разобрать часть из них, чтобы ваш год тоже начался с небольшого развития себя. Многие вопросы я бы зафиксировал под одним собирательным вопросом: «Я вроде не Junior, но и не чувствую себя уверенно, что делать?». И это, на самом деле, частая проблема на всех уровнях. Я встречал много Senior разработчиков для которых сам факт такой позиции значил больше, чем фактические знания и опыт, которые у них на тот момент были. Большинство из таких людей застревают на ментальном уровне Junior/Middle разработчиков не смотря на свою позицию. А как ранее мы с вами обсуждали, Senior — это не только про код. Я понимаю, что вопрос чаще всего денежный, но попробуйте подумать чуть-чуть наперёд и рационально оценить свои скиллы и возможности. Смысл от того, что вы Senior Developer, если у вас месяцами висит зелёная рамка Open To Work в LinkedIn? Уверенность появляется из опыта, причём «опыт» сам по себе это достаточно сложная штука, но я бы сейчас сократил его до «масштаб и уровень проблем, которые я могу решить». Попробуйте выписать задачи и проблемы, которые вы решали в последний квартал. Что из этих задач, по вашим ощущениям, тянут на уровень «Senior», а что из них смог бы решить и Junior с Cursor-ом? Сравните процентно. А потом попробуйте провалидировать задачи с коллегами/друзьями/LLM, чтобы сравнить свои ощущения и внешнюю оценку сложности. Если у вас превалируют задачи для джунов, то нужно посмотреть по сторонам и, да простят меня наши рекрутёры, если вы понимаете, что на текущем месте достигли потолка в плане задач и роста — попробуйте сменить работу. Во первых, это хорошая внешняя валидация вас, как специалиста. Во вторых, до определённого времени, чем больше проектов и доменных областей вы попробуете — тем лучше. Если же задачи достаточно сложные, но всё равно ощущается застой, то попробуйте сменить фокус, хотя бы не надолго. Сходите в отпуск, попробуйте поработать с инфраструктурой и/или тех.долгом, посмотрите что там в других командах (если есть такая возможность). Помните, что настоящий Senior сам проявляет инициативу и придумывает себе проблемы :) Ваш рост останавливается, когда вам становится слишком комфортно. Если вы на постоянной основе занимаетесь задачами, которые не требуют усилий — вы начинаете деградировать, а это уже тревожный звоночек. @drugoi_dev

📆 EoY 2025? Год, конечно, пролетел очень быстро. Ретроспективно смотря в любую дату прошедшего года я задумываюсь о том, что просто не было ни одного спокойного дня. Каждый месяц был наполнен чем-то абсолютно разным. То мы пытаемся понять, как долго ещё нужны будут программисты в их классическом виде, то ругаемся на облачных провайдеров из-за урезанных лимитов и невозможности закончить задачу быстро. Вот я стою возле Хогвартса в Universal Studios Japan, а вот я рассказываю школьникам про свой путь в IT. Вайб-кодинг ваш друг Когда я в прошлом году рассказывал доклад про AI на BeeTech, то моё основное размышление было, что сам по себе чат-интерфейс с доступом к LLM — это game-changer, но, по настоящему страсть к программированию и созданию чего-то своими руками ко мне и сотням других людей вернуло агентское программирование. Когда я переходил в менеджеры, то думал, что мне будет хватать времени на написание кода во вне рабочее время, но специфика работы и увеличение загруженности моего календаря ставило крест на постоянной разработке чего-либо. Агентское программирование (а местами вайб-кодинг) решило для меня проблему со временем и, особенно, проблему белого листа. Всё таки как менеджер я могу более эффективно управлять пачкой специалистов уровня middle в своём терминале 😁  И мне очень нравится, что я могу поднять какие-то старые наработки, идеи, вдохнуть в них жизнь, быстро проверить гипотезы или сделать что-то полезное для работы. Да, это новый скилл и достаточно серьёзная смена парадигмы в самой разработке. Но если мы перестаём учиться — мы перестаём расти. Люди, люди, люди Прошёл второй год работы в Bereke Bank. С учётом многогранности моей текущей позиции (где я одновременно Head, PM, IC и ещё много всего), есть понимание, что без сильных лидеров в моём направлении — просто невозможно. В этом году моя команда в Банке претерпела небольшие изменения. С одной стороны, произошёл трансфер в разные компании некоторых моих отличных ребят, с другой стороны мы с вами ранее обсуждали, что все рано или поздно уходят, а наша задача адаптироваться к этому, находить новые возможности и людей. Мы адаптируемся, меняемся и идём дальше. Отдельная благодарность ребятам, благодаря которым в этом году про Банк слышали чуть ли не на каждом митапе и конференции. В следующем году постараемся захватить ещё больше :) Work-life integration Зачастую мне сложно сказать, что из того, что я делаю — это работа, а что простая жизнь. В этом году я ещё более интегрировал работу в свою жизнь, а не поддерживал work-life balance. Для меня важно, чтобы команды и я сам могли работать асинхронно, минимально блокируя друг-друга, но уважая своих коллег, я всё таки ставлю отложенные сообщения с идеями и мыслями на следующий день, а не пишу им в 9 вечера :) Всё таки, чтобы стать рыночным дифференциатором, недостаточно просто работать, нужно добиваться лучшего, быть автономным и челленджить самих себя. ——— Иногда задумываюсь, успеваю ли я жить в целом и что считать полноценной жизнью, но после саморефлексии прихожу к тому, что моя жизнь — это то, к чему я пришёл за все эти годы и стоит признать, что каждый год становится только лучше. Думаю, следующий год будет ещё более насыщенным, цели и стратегия на год построены, будем исполнять. С наступающим Новым Годом, друзья. @drugoi_dev

❔ Sharing is caring В какой-то момент карьеры ты задумываешься о том, что полезно было бы помогать людям. Некоторые приходят к этому достаточно быстро (на мой взгляд, слишком быстро, но не осуждаю). И вот с чем я очень часто сталкиваюсь в последние пару лет, это вопросы от разработчиков в духе: — туда ли я иду — нормальный ли у меня уровень — почему вроде работаю много, а роста не чувствую И проблема почти никогда не в знаниях и даже не в опыте, который есть у этих разработчиков. Отмотаем немного назад В 2020 году, в разгар COVID, я проходил Школу менторов в Практикуме. Тогда это выглядело как «правильная» идея, ты можешь помогать людям системно и надолго но, со временем я понял, что мне не очень близок формат менторства как процесса. Со всеми этими регулярными созвонами, целями, трекингом и длинным горизонтом. Зато мне оказалось близко другое: короткие, открытые разговоры, после которых у человека в голове становится заметно чище. И тут я подумал Недавно я провёл небольшой опрос (на который вы ещё можете ответить) в наших чатах, просто чтобы проверить ощущение, правильно я размышляю. И почти все вопросы были не про фреймворки или технологии. Больше всего вопросов было про состояние и неопределённость: — я вроде уже не junior, но дальше непонятно — хочу сменить работу, но боюсь собеседований — не уверен, что мой код тянет на следующий уровень — сложно принимать архитектурные решения и отстаивать их Я слишком часто видел это же самое и в живых разговорах. И каждый раз замечал, что за 30-60 минут мы закрываем вопросы, которые человек носил в голове месяцами. И это далеко не потому что я «знаю больше», а потому что могу посмотреть со стороны, задать неудобные вопросы и быстро разложить ситуацию по полочкам. Из этого и родился формат 1:1. Что (для меня) важно: без обещаний «роста за N месяцев» и без менторства ради менторства. Просто разовые сессии, когда нужно: — честно зафиксировать, где ты сейчас — убрать хаос в голове и в решениях — понять, какой следующий шаг действительно имеет смысл Если тебе это откликается, детали и запись здесь, начнём уже в феврале — https://1on1.drugoi.dev

❓ Задавайте вопросы У меня в блоге есть заметки, которые я группирую в категорию “common sense”, например заметка «Держите в курсе». Это новая заметка из этой же категории. Я не сторонник микроменеджмента и постоянных вопросов в духе «как дела?», поэтому ожидаю, что если человек или команда застряла — они сами придут с вопросами. К сожалению, не все разделяют эту точку зрения и зачастую ждут, когда кто-то заметит*, что они буксуют, хотя этот момент может наступить слишком поздно. Самое ужасное, что вы можете сделать, когда у вас что-то не получается — это сидеть и молчать. Дожидаться дедлайна или надеяться, что про вас забыли — это не план. Если речь идёт про вопросы связанные с реализацией задачи, если вам чего-то не хватает или у вас проблемы с теми данными, которые вам предоставили — просто задайте вопрос. Не надо винить кого-то, что он плохо выполнил свою работу, ваша задача в этой ситуации быть проактивным и быстро начать задавать вопросы. Конечно, не погружаться в задачу и сразу бежать задавать вопросы, на которые, возможно, есть ответы в задаче/код/базе знаний — это пример плохого сотрудника. Но если после всего, что вы узнали, вам всё ещё не ясно, что нужно или как нужно сделать — начинайте задавать вопросы. Не стесняйтесь писать в общий чат, если вы не знаете, кто может помочь. Не стесняйтесь в целом задавать вопросы, на которые вам нужны ответы. Так вы можете стать лучше и сделать задачу качественнее. Сейчас, когда AI есть везде, первое место, куда я пойду, если мне не хватает полного контекста о самой сути вопроса — это ChatGPT. Пока что, очень редкие вопросы не получали ответ, который меня бы устроил. Иногда, мне нужна валидация от людей с каким-то опытом или знаниями, а может даже с дополнительным контекстом, тут и настаёт моё время «задавать вопросы», но сегодня мы о другом. Поэтому, если вы буксуeте — задавайте вопросы. @drugoi_dev * об этом я напишу в другой заметке

🫡 Почему они уходят К сожалению, рано или поздно все уходят. Я даже больше скажу — они обязательно уйдут. По разным причинам. Кто-то из-за денег, кто-то из-за команды или процессов, а кто-то даже из-за вас самих. При средней жизни разработчика в компаниях около двух лет, ждать, что разработчик пробудет с вами дольше — наивно. И не будем самообманываться: деньги — основной фактор выбора работы для большинства разработчиков. Проект и команда важны, но становятся чуть второстепенными, особенно на нашем рынке. Да, деньги не всегда решают всё, но их отсутствие быстро перечёркивает остальное. При этом возможности и потолки, заданные рынком, достижимы — хоть и не сразу. Я бы хотел подсветить моменты, которые могут, с одной стороны, продлить время жизни сотрудника, а с другой — подскажут, когда его время уже настало. Разработчик просит поднять зарплату В целом, если это происходит, то, возможно, уже слишком поздно и вы просто, немного, откладываете неизбежное. Причём, если вы не поднимите зарплату, то разработчик скорей всего скоро уйдёт, а если поднимите, то это не зачтётся вам, т.к. разработчик просто получит то, что попросил. Чтобы избегать таких ситуаций, важно делать процесс пересмотра максимально прозрачным и интервальным (ассесмент раз в n времени). Было бы здорово бесконечно поднимать зарплаты по каждому запросу, но нужно понимать, что бюджет на вашу зарплату не всегда бесконечный. Важно помнить, что рост зарплаты — это не только желание, но и возможности компании. Иногда рациональнее вложиться в рост команды, чем в индивидуальное повышение. Дайте разработчику экстра-задачи Я помню, как сильно удивился, когда один из моих разработчиков пришёл ко мне и сказал, что хотел бы сменить направление, потому что, как ему кажется, он уже всё попробовал и дальше расти некуда. За более чем 10 лет в фронтенд-разработке я до сих пор считаю, что знаю далеко не всё. Где-то не позволило время, где-то — сама суть проекта. Но факт остаётся фактом: современная разработка — очень широкая и глубокая область. Можно хоть каждый день находить что-то новое и применять это в работе. Если разработчику кажется, что он уже всё попробовал — дайте ему экстра-задачи, челлендж: экстремально сократить размер бандла, избавиться от всех ошибок в Sentry или Crashlytics, наконец-то починить юнит-тесты и т.д. Самая сложная часть, когда становишься лидом или менеджером — это делегирование. Но другим тоже нужно расти, поэтому собирайте самые интересные задачи и делегируйте их. Если разработчик хочет расти — дайте ему эту возможность Да, не всегда такая возможность есть, но вы можете помочь сотруднику к ней подготовиться. Будьте честны: скажите, насколько позиция подходит ему и как далеко он от неё в контексте выполняемых задач. Иногда достаточно просто рассказать, чем вы как менеджер занимаетесь, чтобы у разработчика временно пропал интерес к этой роли :) И всё же, они уходят Почему? Потому что не всё в ваших руках. За годы компания меняется, меняются и люди. Зачастую самое правильное, что можно сделать, когда сотрудник хочет уйти — не принимать это на свой счёт и дать ему эту возможность, при этом остаться в хороших отношениях. Рынок маленький, и вполне возможно, ваши пути ещё пересекутся. @drugoi_dev

👔 Почему просто работать — недостаточно В тот момент, когда в моей жизни появилась возможность влиять не только на найм сотрудников, но и на их зарплаты — жизнь стала немного сложнее. Казалось бы, вот перед тобой два разработчика. Оба отлично прошли собеседования, готовы принять оффер и выйти через неделю… но, позиция всего одна. И тебе, как нанимающему менеджеру, нужно понять — кто из этих покемонов твой Пикачу, а кто Магикарп*. И тут я вспоминаю время, когда сам был «просто разработчиком». У меня всегда была позиция: чтобы просить повышение, нужно что-то сделать. И, справедливости ради, зарплата всегда росла. Проблема была лишь в том, что в тех компаниях, где я тогда работал, экстра-задачи встречались редко, фокус всегда на основных задачах, максимум успеваешь поработать с техдолгом под конец спринта. В такие моменты я задавал себе вопрос: а зачем менеджеру повышать мне зарплату, если я просто делаю задачи? Да, обычно после этого я решал, что пора двигаться дальше, и менял работодателя. Но этот вопрос «зачем?», я задавал себе на каждом месте работы. И вот, возвращаясь к нашим покемонам. Кого выбрать? Хотелось бы нанять обоих, но команде нужен только один. Один кандидат берётся за экстра-работу: помогает сообществам, выступает на митапах, пишет статьи, делает вклад в open source, а может, просто пытался понять, почему продукт работает не так, как должен, и предлагал улучшения. А второй кандидат — просто работает. Его резюме состоит из фраз «делал задачи» и «чинил баги». Простой кодер. И вот здесь проявляется главный тезис: просто работать — недостаточно. Особенно сегодня, когда AI может покрыть большую часть нашей рутины, надеяться, что работодателю будут интересны “скучные” кандидаты, — опасно. Не будьте просто кодерами. Будьте инженерами. Потому что сегодня выигрывают не те, кто пишет код, а те, кто понимает, зачем он нужен. @drugoi_dev

🚀 AppSecFest 2025 совсем скоро! 🚀 Уже в эту пятницу 25 апреля мы встретимся на главном событии в мире IT, разработки и безопасности - AppSecFest 2025. Организаторы и партнеры приготовили невероятные активности, такое нельзя пропустить! 🚀 2 конференц-зоны: • App – инновации в разработке и IT • Sec – все о безопасности приложений 🚀 2 панельные сессии – обсуждения горячих тем и трендов отрасли. 🏆 OpenCTF 🚀Море крутых призов среди которых 4 Macbook-а 🚀Игровая зона и дрон-футбол 🌟 Приглашаем вас ознакомиться с полным расписанием докладов на appsecfest.kz и запланировать свое участие. 📝 Ссылка на покупку билета: https://appsecfest.kz/#rec863901088 До встречи на AppSecFest 2025 в Алматы!

Я тут в пятницу в небольшой панельной дискуссии участвую, приходите поздороваться :)