Почему разработчики выгорают, а фаундеры нет

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

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

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

Как AI влияет на формирование навыков программирования

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

1️⃣Группа без доступа к AI. Они часто ошибались в задаче, но лучше справлялись с итоговым тестом. Получается, что в процессе работы они учились.
2️⃣Группа с доступом к AI. Эти лучше справлялись с прогарммированием, но по итогу ничего не поняли.

Какие дополнительные интересные выводы появились:

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

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

Про доверие к исследованиям

Я часто напоминаю и себе, и всем остальным, что сам факт существования опубликованного исследования, пусть даже прошедшего peer review, и с наличием ссылок на него из других исследований, вообще не показывает, что ему можно доверять. Если вы действительно хотите на него опираться, недостаточно просто прочитать вводную часть и выводы, нужно внимательно вкатиться в методологию и понять, а доверяете ли вы ей. Ну а вообще – опираться на единичное исследование в целом такое себе, и по-хорошему надо искать появления мета-исследований.

На прошлой неделе произошел еще один скандал, который этот тезис подтверждает. В чем суть – есть исследование 2014 года под названием "The Impact of Corporate Sustainability on Organisational Processes and Performance". Его авторы заявляли, что компании, которые серьезно относятся к социальной ответственности, не только делают добро, но и зарабатывают больше денег для акционеров, причем таких сверхдоходов аж 40%, и это видно на горизонте 20 лет. Это исследование стало безумно популярным – 6000 ссылок, цитирование разными топ-менеджерами, финансистами и политиками. Но оказалось, что в нем есть ряд фатальных недостатков:

👉Ключевой результат, помеченный как статзначимый, на самом деле не был таким.
👉Описанный в исследовании аналитический метод на самом деле не соответствовал тому, что делалось реально.
👉Часть важных статистических проверок просто не были проведены.
👉Независимая попытка воспроизвести исследование провалилась.
👉Результаты не проходят стандартную проверку на ошибку выжившего – потому что для него отбирались только компании, дожившие до наших дней.

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

Зачем организациям оценка сроков

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

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

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

👉Перед тем, как вообще начать думать об оценке, надо собрать весь политический контекст – кому этот проект важен, насколько сильно и срочно.
👉Вместо того, чтобы задавать себе вопрос "сколько времени уйдет на проект", смотрите по-другому – "как я могу решить исходную проблему за время, которое мне сказали".
👉Больше времени уделяйте неизвестным переменным – рискам, которые могут существенно увеличить время работы.
👉Приходите к менеджеру не с оценкой, а со списком рисков и несколькими вариантами плана работы с ними.

Библиотека без кода

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

👉Подробная спецификация (высокоуровневые дизайн-принципы, требования по входу-выходу, обработке ошибок, описание логики работы и тестов для каждой функции)
👉Набор тестовых данных
👉Инструкция для агента

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

Я знаю, что вы сейчас в комментарии накидаете еще сотню ограничений – но попробуйте посмотреть на подход с открытыми глазами и сердцем, ведь круто же, ну!

Координация стоит дорого

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

Если нырять в детали, то вот что важно понимать:

👉Координация между командами требует больше усилий, чем работа внутри своей команды, поэтому проше всего делать все локально, чтобы снизить издержки. Изоляция и дублирование работы отсюда и возникают.
👉Хотя время, затрачиваемое на митинги, кажется непродуктивным и отнимающим ресурсы от реальной работы, координация без них практически невозможна. Так что это не пустые потери, а цена за масштаб.
👉С ростом организации стоимость координации растет сильнее, и выливается в те же митинги и слои менеджмента. Можно смотреть на это как на организационный закон термодинамики – чтобы удержать систему от распада, надо вкладывать все больше усилий.
👉Что бы вам ни обещали на конференциях, нет серебряной пули, которвя решит проблему – волшебного фреймворка, инструмента или процесса.

Про CapEx и OpEx

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

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

Поводов усиленно думать стало меньше

Помните алгоритм решения проблем имени Фейнмана?

1. Запишите задачу
2. Хорошо подумайте
3. Запишите решение

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

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

Новые выпуски тимлидских подкастов

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

👉Подлодка про СДВГ – как этот синдром диагностируется, почему его так много среди айтишников, и как вообще работать с такими людьми
👉Три тимлида заходят в бар про делегирование – как к нему правильно подойти, как адаптироваться под культуру компании и чем занять освободившееся время
👉Едим слона целиком про известных менеджеров в истории – Ивана Грозного, Георгия Жукова, Александра Суворова и других

В чем заключается работа тимлида

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

👉Эффективность, или то, что нужно компании. Под самые важные задачи вы выбираете людей с самым подходящим опытом.
👉Развитие и челлендж, или то, что нужно инженерам. Вам надо брать в расчет личные интересы и планы по росту каждого человека в команде – и иногда давать задачу кому-то менее опытному и эффективному.
👉Долговечность и устойчивость, или то, что нужно проекту и команде. Задачами надо балансировать так, чтобы в команде не было точек отказа, и в каждой части вашей системы разбирались несколько человек.

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

Что такое Context Graph

Разбираем новый модный термин Context Graph. В чем идея – организации в целом довольно неплохо справляются с тем, чтобы записывать результаты своих решений. Отсюда берутся все те тысячи тикетов в вашей системе и разные документы, лежащие в папках на гугл диске. Но в большинстве случаев, записываются только результаты решений, а не их контекст – как и почему они были приняты. Поэтому, когда спустя какое-то время никто не может объяснить, почему вообще так было сделано.

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

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

Пока это скорее идея, которая очень интересна большому количеству стартапов. В реальности я еще не видел, чтобы оно работало хорошо. Инфраструктура для чего-то похожего точно есть у Gleam, которым мы пользуемся на работе, но релевантность там пока оставляет желать лучшего – да и UX удобный точно еще надо будет придумывать.

Как сделать программиста счастливее

1️⃣Status – ощущение профессиональной значимости. На него влияют публичное признание вклада, конструктивная обратная связь, вовлечение в принятие важных решений, как технических, так и продуктовых.
2️⃣Certainty – предсказуемость и ясность. С этим помогают понятные цели, хотя бы на краткосрок, наличие смысла за задачами, логичные объяснения причин изменений, доверие к решениям менеджера.
3️⃣Autonomy – контроль над своей работой. Важно иметь возможность самому планировать и свою работу, и то, как она будет делаться, без микроменеджмента, контроля и советов под руку.
4️⃣Relatedness – чувство принадлежности и безопасности. Этот пункт про команду, которой ты доверяешь, с которой разделяешь общие цели, и вместе с которой тебе кайф работать.
5️⃣Fairness – ощущение справедливости. Больше всего его рушит чувство несоответствия между твоими усилиями и вознаграждением. Поэтому работать над этим менеджеру надо, устанавливая понятные правила игры для всех, компенсируя похожим образом похожие результаты, и оставаясь последовательным (см пункт про ясность и предсказуемость).

Расскажите, как вы используете AI

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

Конечно же, по нашей традиции среди всех участников я разыграю сертификаты на хорошие книги – на что еще тратить сэкономленное время, как не на чтение!

👉Ссылка на опрос

AI не уменьшает количество работы, а делает ее более интенсивной

In an eight-month study of how generative AI changed work habits at a U.S.-based technology company with about 200 employees, we found that employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so.

Несколько мыслей по этому поводу:

👉От переключения контекстов во время работы с агентами удержать себя очень сложно. Во-первых, тебе действительно нечего делать, пока он думает над задачами. Во-вторых, ты одновременно находишься в состоянии потока, но и в голову загружено сильно меньше контекста, чем при ручной разработке – поэтому есть ощущение, что ты можешь горы свернуть. В-третьих, фидбэк луп о том, что ты на самом деле сильно вымотался, довольно долгий, поэтому по рукам тебя ничего не бьет, и ты не учишься на ошибках.
👉Когда человек хочет добиться промо, либо успешно пройти испытательный срок, он часто выбирает стратегию в лоб – перерабатывать, за счет этого закрыть больше задач, и показать свою ценность. Проблема в инфляции перфоманса. Твоя повышенная эффективность быстро становится планкой базовых ожиданий от тебя, и снизить темп уже не получается. Так вот, если в похожем режиме начинает работать половина компании, все еще хуже – такие ожидания закрепятся в рамках всей системы грейдов и промо.
👉Тебя постоянно не покидает ощущение, что задача ну вот почти-почти доделана, и до идеального результата осталась всего одна итерация работы с агентом. Это с одной стороны мешает оставить задачу незавершенной, и вернуться к ней на другой день, а с другой – дополнительно подталкивает тебя побыстрее взяться за параллельную задачу.

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

Скорость разработки никогда не была проблемой

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

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

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

👉У людей внутри организации мало хороших идей, и много плохих. Вообще то, что идеи запиливать было долго и дорого, наоборот, могло вас спасать от некомпетентности.
👉У большинства ваших сотрудников нет особой мотивации быть суперпродуктивными и выкладываться на благо компании. Как и любые разумные люди, они работают 9-5, и идут домой к семье и своим делам.
👉Для нормальных людей польза от AI не в том, чтобы быть 10х эффективнее, закрывая продуктовый бэклог, а в том, чтобы тратить меньше своей ценной энергии.
👉Те несколько людей, которые действительно хотели свернуть горы, вместо этого сидят и ревьюят AI слоп, который нагенерировали все остальные, и постепенно выгорают.
👉И на фоне всего этого ваш финансовый директор постепенно начинает задавать вопросы про то, как так получилось, что все инженеры теперь стоят на несколько тысяч долларов дороже из-за токенов, которые они прожигают.

Почему быстро выпускать новые фичи – это плохо

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

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

И вместе с этим я напоминаю, что вот уже сегодня начнется бесплатная большая конференция Стратоплана как раз про то, как AI меняет процессы разработки – поэтому, если сердце за происходящее у вас болит, обязательно заглядывайте!

Как правильно отдыхать

Отдых – это не награда за какие-то действия, это часть полноценной и насыщенной жизни.

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

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

Я запускаю закрытый клуб про AI в разработке

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

Если эта проблема горит у меня, то скорее всего таких людей очень много. А я люблю решать проблемы – поэтому я решил собрать Podlodka AI Engineers Club – закрытое сообщество опытных разработчиков, которые хотят вместе разбираться с тем, как использовать AI с пользой, и делать это системно, а не на ощупь.

👉Как это вообще работает. Каждую неделю – воркшопы и лайвкодинг с людьми, которые активно используют AI, и внедряют его в реальные продукты и компании. Разбор конкретных инженерных практик: как строить своих агентов, как работать по Spec-Driven Development, как собирать комбайн, превращающий таски в Jira в PRы, как масштабировать это и на небольшую команду, и на всю разработку в бигтехе.

Между встречами – сеть закрытых чатов в Telegram, клубные созвоны, совместные эксперименты.

👉Кто уже в программе. Черновое расписание на март-апрель собрано. Среди экспертов – инженеры из компаний разного масштаба: Степан Гончаров (xAI), Роман Елизаров (Яндекс), Андрей Володин (Gracia AI), Андрей Бреслав (CodeSpeak), Денис Неклюдов (Google), Макс Страхов (Meta) и много других крутых ребят.

👉Как попасть. Клуб платный, вход через список ожидания с отбором – нам интересно сделать сообщество именно для опытных разработчиков. Мы набираем участников постепенно – нам важно сохранить атмосферу, в которой можно открыто делиться опытом и проблемами. Стартуем уже с понедельника!

Отдельно подчеркну, что клуб делаем именно для инженеров – людей, которые большую часть своей карьеры писали код, решали технические задачи, принимали архитектурные решения, и жили с их последствиями. Я знаю, что на канал подписано довольно много технических менеджеров, и senior/staff/principal инженеров – вот этот анонс для вас!

Подробности, расписание и заявка – на сайте. А если есть какие-то конкретные вопросы, пишите прямо мне в личку, @etolstoy!

Про влияние тренировок на менталочку

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

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

Текст стал дешевым, и мы к этому не готовы

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

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

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

Что конкретно с этим делать, пока не очень понятно. Автор поста предлагает развилку с двумя вариантами:

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