Про мораль корпораций

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

👉Фича priority delivery, которая на самом деле не влияет ни на что, кроме флажка, отправляемого на сервер.
👉A/B тесты с замедлением скорости доставки неприоритетных заказов.
👉Автоматическое определение курьеров, которые готовы браться за заказы любой стоимости, и занижение им оплаты.
👉Чаевые, которые целиком уходят в карман платформы.

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

Очень подробно про это рассказано в вышедшей в прошлом году книге Careless People, в которой бывший топ-менеджер Meta делится байками про то, как Цукерберг и компания принимают решения и разруливают происходящий по их вине геноцид (и даже не один). Если вот эта история про доставку еды показалась вам нереалистичной, очень советую прочитать!

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

Законы разработки софта

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

👉Закон Каннингема – Самый лучший способ получить полезный и правильный ответ в интернете – не спрашивать, как правильно, а запостить неправильный ответ.
👉Закон Стерджена – 90% чего угодно это мусор (ну получается как минимум один пост в две недели в нашем канале должен быть годным).
👉Закон Хайрума – от любого, пусть даже незадокументированного поведения вашего API, кто-то будет зависеть. Про этот закон мы пару лет назад классно поговорили в выпуске Подлодки про дизайн API.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.

За что инженеры ненавидят своих менеджеров

👉Бесконечные синки и митинги, которые вырывают из состояния потока
👉Нетехнические менеджеры, которые не понимают сложности задач, но при этом дают обещания по срокам
👉Менеджеры, которые присваивают себе чужие достижения, фразами вроде "вот что я зарелизил в этом квартале"
👉Фидбэк про зоны роста, который дается раз в год менеджером, который вообще слабо прелставляет себе вашу работу

Уроки 14 лет работы в Google

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

Прокрастинация, и как с ней справляться

Если кого-то и читать про прокрастинацию, так это Максима Дорофеева. В статье он постепенно выводит ее определение:

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

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

👉Почему вы считаете дело Х важным для себя? Важно ли оно само по себе, или является средством достижения другой цели?
👉Всегда ли вы занимаетесь разными делами вместо Х, или одним и тем же? Как они связаны?
👉В каком состоянии вы находитесь во время приступа прокрастинации? Типичное ли это состояние в момент принятия решения, что делать дальше?
👉Есть ли у вас состояние, в которгм нет приступов прокрастинации? Как вы его расходуете?
👉Какие аргументы в пользу дела У проскакивают в вашем уме во время прокрастинации?

Про парадокс инвестиций в 2026

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

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

👉Нет потери контекста при общении в команде, он весь содержится в голове у фаундера
👉Не приходится идти на компромиссы с другими людьми, пытаясь не задеть их самооценку, или из-за других политических причин
👉Нет организационной инерции, попыток переиспользовать старые решения и всего с этим связанного
👉Порядок цен, конечно, абсолютно другой – вместо $30k в месяц на зарплаты минимальному костяку команды, в самом отчаянном случае вы заплатите N*200$ за несколько подписок на Claude Code.

Начинайте митинги на пять минут позже

Редко кто заканчивает митинги на пять минут раньше обычного таймслота. Как результат, первые минуты следующего митинга несколько человек ждут, пока все добегут до нужной переговорки. Вместо этого попробуйте сделать простую вещь – назначайте все свои митинги на 5 минут позже обычного времени (12:05 вместо 12:00). Все участники точно скажут вам спасибо.

Почему не надо останавливать все плохие проекты

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

Еще один кусочек мудрости, который появляется вместе с чуйкой – это понимание, что не нужно идти воевать с каждой ветряной мельницей. Даже если вам очевидно, что какой-то проект обречен, не нужно пытаться его остановить. Почему так:

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

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

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

1️⃣Насколько близко этот проект находится к вашей команде
2️⃣Если все пойдет по плохому сценарию, насколько сильно это повлияет на вашу команду
3️⃣Если все пойдет ну совсем плохо, как это повлияет на всю компанию

Короче говоря, pick your battles!

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

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

👉Всего AI хотя бы раз попробовало 80% сотрудников. При этом ретеншн очень высокий – 85%, кто попробовал, потом уже не бросает.
👉Если дать доступ ко всем моделям, то люди будут использовать самую дорогую для всего, даже для самых простых задач.
👉Две трети бюджета по итогам уходило на генерацию картинок. 74% сотрудников делали это хотя бы раз, даже бухгалтерия, которым, казалось бы, они не нужны.
👉20% пользователей сгенерировали 80% запросов, а топ-10 пользователей потратили 20% бюджета.
👉По сравнению со стоимость дефолтной подписки в 20$ в месяц, при работе через API вышли копейки – около 2.5$ на человека.

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

Как поступить в этой ситуации разбираем вместе с тремя опытными менеджерами: Александром Орловым, Александром Поляковым и Игорем Цупко!

👉Весь кейс на канале "Тимлид не спит"
👉Разбор экспертов

Бреслав и Ложечкин про мечты и цели

На волне обдумывания своих личных планов на 2026 год, послушал последний выпуск Бреслава и Ложечкина на эту же тему. Какие две мысли мне запали в душу:

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

Как получать высокие оценки на performance review

Начнем с важного дисклеймера – don't hate the player, hate the game. Если в вашей компании проводится регулярный перфоманс ревью, и от него зависят бонусы и повышения, то стоит к нему относиться как к отдельному тренируемому навыку, который не всегда будет коррелировать с реальной полезностью вашей работы. Вы можете его игнорировать, но в чем смысл – вы чаще всего просто меняете свое время на деньги, и должны быть заинтересованы в том, чтобы курс был повыше.

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

👉Активизироваться нужно вовремя. Если вы равномерно хорошо работаете весь квартал, это никому не интересно. А вот если показать повышенную полезную активность где-то за месяц до старта ревью, менеджер заметит ваш рост и вовлеченность. А последнее впечатление, как рассказывал еще Канеман, самое важное!
👉Будьте вежливым и приятным человеком и с менеджером, и с коллегами. Если вы перепрыгнете минимальную планку того, чтобы не обесценивать чужие идеи, не уклоняться от коммуникаций, и не относиться к просьбам о помощи как к наказанию, вы уже будете лучше большинства и стабильно получать от коллег высокие оценки. Ревью всегда субъективно, позтому приятный в работе человек выигрывает у неприятного, но более компетентного.
👉Решите хотя бы одну проблему за пределами своих обязанностей – поучаствуйте в собеседованиях, наладьте какой-то общий процесс, запилите библиотеку. И подготовьтесь об этом красиво рассказать в своем ревью, обязательно подчеркнув, что вклад сделан за пределами команды – это стандартный зеленый флаг для повышения.
👉Относитесь к слабым сторонам как к козырям. Хорошо знайте их, и старайтесь каждый цикл ревью показывать заметное улучшение хотя бы по одной. Например, в одном цикле ревью расскажите, что ваша слабая сторона – вовлечение в продукт, а в следующем покажите, как круто вы стали контрибьютить в PRD. Короче говоря, покажите маленькую победу над собой.
👉Смотрите на self review не как на отчет, а как на рекламу себя. Рассказывайте о себе, как будто выбиваете инвестиции на проект. Любая выполненная задача обязательно должна иметь понятный импакт и практически спасать компанию.
👉Не бойтесь явно писать, что оцениваете себя выше среднего и превосходите ожидания, объяснив, как именно (вот все эти пункты выше). Менеджеру проще согласиться, чем доказывать обратное.

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

Как получать хорошие советы

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

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

Тот самый проект на 100.000 строк, написанный полностью с помощью Claude Code (оригинал).

Как LLM помогают мышлению

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

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

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

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

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

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

Вся проблема в выгорании – отсутствие смысла в том, что мы делаем каждый день. Если вы не видите четкой связи между движением задач в 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-штук – в этом примере библиотека переводит дату в строчки. Но, кажется, в будущем основными ограничениями будет не столько комплексность бизнес-логики, сколько высокие требования к перфомансу, сложности в тестировании и вероятность появления редких, но неприятных багов.

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

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

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

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

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