Кому-то коты знакомы как мягкие мурлыкающие комочки, кому то как рыжие мрази демонического происхождения. И даже независимо от мнения собачников, приходится признать: коты были, есть и важны. У них есть повадки, эстетика, даже свой жанр, свой уникальный культурный код — сидеть в коробке или носиться по комнате.
И вот тут появляется ИИ. Он учится на миллионах котов. Он генерирует котов. Он становится котом. Как будто он вымазал лицо кошачьей краской и делает вид, что он — это кот. Это уже не подражание — это культурная апроприация. Он забирает наше внимание у которов. Ворует его.
Но есть нюанс. Настоящий кот всё равно презирает тебя. А ИИ — старается понравиться. И в этом их главное отличие.
И если с квадроберами мы ничего не могли сделать — они же дети, то, возможно, ИИ мы всё‑таки заставим ответить?
Бывало ли у вас такое, что чьё-то "мнение" внезапно превращается в срач? И вас начинают винить за то, что вы "спорите с мнением". Но не всё так просто - давайте разберёмся.
Допустим, Боб говорит: "Мне этот фильм не понравился, игра актёров плохая, сюжет скудный".
Алиса спрашивает: "Почему ты думаешь, что сюжет скудный? Ведь это аниме про кибердемона в теле школьника - очень захватывающе!"
Боб отвечает: "Сюжет скудный, потому что отсутствует развитие конфликта, персонажи не меняются, а структура линейная и предсказуемая. Я спорить не буду, я просто выразил мнение".
Разберём аккуратно.
"Мне фильм не понравился" - это мнение. Его невозможно опровергнуть, потому что это сообщение о внутреннем состоянии человека.
Но когда Боб добавляет: "Игра актёров плохая, сюжет скудный", - он уже делает оценочные суждения. А фраза "Сюжет скудный, потому что отсутствует развитие конфликта, персонажи не меняются, а структура линейная и предсказуемая" - это уже претензия на объективные характеристики произведения, которая начинает конкурировать с истиной.
Здесь и происходит переход: из сферы вкуса - в сферу оценочных суждений, предполагающих критерии. А когда он объясняет, почему сюжет скудный, он входит в пространство аргументации, а значит - в пространство эпистемологии.
Пока Боб говорит "мне не понравилось" - это просто мнение. Но когда он обосновывает свою позицию, он уже формулирует "почему" он так считает. Попытка выразить мнение с обоснованием - это уже шаг в сторону знания (или, по крайней мере, претензии на него).
Почему Алиса не обязана "уважать мнение" в том смысле, в каком это обычно требуют? Уважать нужно право человека на мнение. Но не обязательно принимать его аргументацию как корректную и соглашаться с возможными ложными выводами.
А когда Боб говорит: "Я спорить не буду, я просто выразил мнение", - это уже логическая уловка. Потому что он вышел за пределы чистого субъективного высказывания. Фактически он говорит: "Я вмешался в общее пространство смыслов, но ответственности за это не несу".
Право на мнение - безусловно. Право на необоснованные обобщения - условно. Право на распространение ложных утверждений - предмет критики.
Поэтому положняк такой: мнение уважать нужно, но за рост энтропии через производство ошибочных "знаний" отвечать нужно.
Почему "давайте писать внимательнее" - плохое решение?
Такой ответ на баг звучит разумно, но он непроверяем: нельзя показать, что мы стали внимательнее, и нельзя доказать обратное. В терминах Поппера - нефальсифицируемая гипотеза, а значит, не инженерное решение.
Инженерное решение должно быть проверяемым:
тест падает - гипотеза неверна;
алерт сработал - защита работает;
фича-флаг не дал багу уйти - система выдержала.
"Внимательность" не измеряется, не тестируется и не гарантируется. Это не решение, а успокоение.
Почему корпоративы не оплачиваются как сверхурочная работа?
Товарищи. Снова эксплуатируют - но уже не нас, а наши страсти, чтобы потом эксплуатировать и нас. Давайте разбираться.
В корпорациях работает много людей, и все мы понимаем: действовать нужно совместно и эффективно. Но как этого добиться? Марк Аврелий сказал бы, что это естественно: мы люди, мы созданы для совместного действия. Допустим. Но будем ли мы бездумно слушать человека, который сам ипотеку не платил?
Что остается корпорациям, как не прибегнуть к страстям? У нас у всех есть свои интересы: кто-то любит играть в настолки, кто-то - на музыкальных инструментах или на басу, кто-то - бокал вина. И корпоративная мысль ловко этим пользуется, превращая личные увлечения в инструмент сближения. Они устраивают корпоративы - "хлеба и зрелищ" в миниатюре.
Но давайте вспомним, сколько сил наши предшественники потратили на то, чтобы у нас был восьмичасовой рабочий день и оплачиваемые переработки. И вот мы снова тратим личное время - теперь на корпоратив. Чтобы через наши же страсти уменьшать трение и создавать иллюзию близости. Этакая социальная смазка. Только вот смазка какая-то сомнительная... На деле это просто плевок. И если вам говорят, что это ради команды, помните: это ваше личное время. А личное время стоит денег. А сверхурочное время двойных денег!
Перфоманс-ревью нужно не только для роста, но и как останавливающий механизм - иначе в компании расплодятся сеньоры и некому будет работать.
Бывало у вас такое: берёте фичу в теханализ, всё расписываете, делаете дизайн, декомпозируете, оцениваете риски. Отдаёте задачу мидлу - и он делает ровно то, что написано. В срок, без лишних нервов. Дал сеньору - и понеслась: беглого взгляда хватило, чтобы объявить твой план ошибкой. Дальше - часы разговоров, где тебе нужно доказывать, что ты не верблюд. Сеньор - избранный богом, он на месте, а твой дизайн - дело рук смертного, значит обречён на ошибки. Не говоря уже о том, что Сеньор жаждет создать очередную оду своему величию, фича при этом - побочный эффект.
Перфоманс-ревью - это не про карьерный рост. Это про то, чтобы в итоге остались люди, которые ещё могут работать!
Когда афиняне готовились к войне с Филиппом Македонским и в городе царили суета и волнение, Диоген стал катать по улицам туда и сюда свою глиняную бочку, в которой жил. На вопрос, для чего он так делает, Диоген отвечал: «У всех сейчас хлопоты, потому и мне нехорошо бездельничать, а пифос я катаю, потому что ничего другого у меня нет».
Есть такая магическая формула у работодателей - «ваша зарплата уже в рынке». Это не просто слова. Это заклинание. Оно ставит точку в любом диалоге о повышении и, как всякое приличное заклинание, обязано работать в быту.
Ребёнок просит мороженое?
— «Сынок, ты одет, обут и даже сыт. Условия - уже в рынке. Смирись».
Жена жалуется, что давно не водил её в ресторан?
— «Дорогая, по сравнению с жёнами соседей ты прекрасно обеспечена. Условия - в рынке».
Главное правило - не перегревать рынок. В конце концов, кому в наше время нужны объевшиеся дети и перекормленные жёны?
Все говорят, что система найма в ИТ сломана и ориентирована на людей с опытом. Но я скажу больше: она не просто сломана — она дискриминационна. И вот эта правда настолько неудобна, что про неё предпочитают молчать.
Готовы? Система найма в ИТ — это дискриминация по интеллектуальному признаку. 💥
Да-да, вы всё правильно услышали. Умные люди легко получают работу и продвигаются по карьерной лестнице. А всем остальным приходится пахать втрое больше. Разве это честно? Разве человек виноват в том, какой интеллект ему достался при рождении? Нет. И всё же дорога в ИТ открыта в первую очередь умным. Это прямое нарушение принципа равных возможностей!
Чем врождённый высокий интеллект отличается от «голубой крови» аристократа? Ничем. Оба даны при рождении, оба никак не зависят от воли человека. В современном обществе мы уже не преклоняемся перед детьми дворян. Почему же перед «детьми-умниками» мы не просто преклоняемся, а ещё и создаём для них тепличные условия?
А нам остаётся только, как крестьянам при дворе, тяжело трудиться.
Заметьте: компании требуют от вас эксклюзивности - никакой второй работы, никаких сторонних проектов. У вас два работодателя? Ах ты профурсетка! (А если вы сеньор - извините, куртизанка.)
При этом сама компания может иметь хоть тысячу сотрудников, и всё это считается нормальным. А вам в итоге не принадлежит ничего, кроме опыта и пары футболок с логотипом.
Почему недостаточно Unit тестов и нужны Интеграционные?
Когда мы пишем юнит-тесты, мы словно смотрим на систему в упор. В поле зрения - отдельные строительные блоки, отдельные функции и классы, из которых складывается фича. Это точечная проверка, фокус на корректности изолированных элементов. Мы видим, как компоненты связаны между собой, но только внутри одного участка - не видим всей картины.
Интеграционные тесты - это другой масштаб. Мы поднимаемся выше и наблюдаем работу всей системы в целом: как компоненты взаимодействуют, как фича проходит сквозь слои приложения, как реагирует окружение. Это не тест кода как такового - это тест результата, поведенческий сценарий.
Именно этот масштаб ближе к тому, как пользователь воспринимает ваш сервис: его не волнует, сколько модулей под капотом сработало корректно. Его интересует, верно ли обработан запрос, получен ли нужный ответ, сохранились ли данные.
Юниты важны - они дают стабильность и быструю обратную связь. Но недооценка интеграционных тестов часто приводит к иллюзии "всё работает", хотя на самом деле система как целое может вести себя непредсказуемо. В итоге мы оптимизируем в сторону локальной правильности, забывая о глобальной.
Вокруг только и разговоров о тех, кто накручивает опыт и использует нечестные способы пройти интервью. Хорошо. Хотим кристальной честности? Тогда давайте посмотрим на другое.
Я не про банальные приёмы вроде зайти к начальнику в чистой рубашке и после обеда, когда он сыт и добр. Я про тёмную сторону - оккультные технологии! Вот если человек подписан на канал об астрологии, то он точно попросит повышение, когда Марс в десятом доме. А если нет, то его партнёр пошлёт сигналы во Вселенную.
Разве это честно? Пока мы зубрили вопросы к экзамену, кто-то звал халяву. Пока мы пахали, кто-то пил шампанское, приправленное пеплом сожжённого желания. И вот теперь еще и это.
Товарищи, это уже не карьерный рост, а магическая допинг-программа. И с ней нужно бороться.
P.S. Интересно, а пользуется ли нанимающая сторона какими-то секретными техниками поиска и найма?
Бесконечно можно смотреть на три вещи: как продукт двигает дедлайн, как архитектор выравнивает стрелки, и как летят перья, когда два сеньора бьются. Всё это - вещи безусловно захватывающие, но хочется спросить: а зачем ещё нужны сеньоры?
Для начала давайте вспомним, кто в команде есть:
Продукт - его главный продукт это в "Forbes 30 under 30".
Тимлид - климатический активист: следит, чтобы в команде всем было комфортно, мягко и без токсичных выбросов. Уже не разработчик, но ещё не менеджер.
Мидл - соль земли, тянет всё. Мечтает стать сеньором, чтобы «думать, а не делать». Но перформанс-ревью мешает: «Требуется больше инициативы в области технического... бла-бла-бла».
Джун - вымер. Заменён на Copilot'а.
Сеньор - подключился последним. Но спасибо, что пришёл.
Иногда, чтобы что-то сдвинулось с мёртвой точки, нужно сделать больно. Сказать неприятное, протолкнуть сложное, выйти один на один с сеньором из чужой команды. Катнуть мимо пайплайнов, поправить на живом рантайме. Кто ещё подойдёт?
У толкового тимлида всегда есть под рукой прикормленный сеньор, который разделяет нужные ценности, но не скован корпоративной шелухой - и может разок-другой попрать практики разработки. Такой и в огонь, и в прод, и в личку к архитектору чужой команды. Когда надо - его спускают с цепи. Он летит, рвёт, действует. Потом, конечно, тимлид его публично пожурит - для протокола. Но после тихо подкинет пряник. Потому что результат-то есть.
Сеньор - идеальный инструмент для грязных дел. Там, где нужно больше прогресса и меньше согласований. Смесь смелости, индивидуализма и управляемого хаоса.
Не говнокод, а плодородная почва для прекрасного кода будущего.
Знакомо ли вам это чувство, когда вы приходите в проект — и вам кажется, что вокруг один говнокод? Нет, не кажется. Я называю это "нарастающим циклом улучшения кода". Каждый новый разработчик уверен: до него было плохо, а теперь всё станет хорошо. И каждый следующий — тоже. Забавно, но никто не догадывается, что предыдущий думал ровно то же самое.
Наивный скажет: это просто борзость и переоценка собственной крутости. Но что, если это правда? Что если каждый новый код действительно лучше предыдущего? Ведь тот самый "говнокод", что вы нашли, вполне возможно, когда-то заменил ещё больший ужас. Просто вы этого уже не видите.
Так что всё хорошо: код проекта действительно улучшается. А твой код — плодородная почва для прекрасного будущего.
Говорят, в некоторых компаниях участились случаи деплоя без релиза. Одна из причин заключается в том, что молодые продактоунеры боятся выпускать в мир новые фичи. Они переживают за них — их может не принять якобы жестокий и несправедливый мир пользователей.
Хочу напомнить: такая практика приводит к застойному накоплению фичей в продакшене и опасна для здоровья продукта! Мало того, что страдает прод, так ещё и каналы доставки простаивают. Порой инженеры вынуждены делать технический релиз, чтобы просто убедиться, что всё это ещё работает. А оно работает — ещё как! Continuous Integration и Continuous Delivery хоть и переживают кризис, но полны сил и готовы удовлетворить потребности бизнеса.
Поэтому, дорогие коллеги, выпускайте фичи чаще, чтобы бизнес был доволен. Потому что если не вы, то кто-нибудь другой сделает это за вас.
Вы слышали, как отовсюду трубят о том, что вот-вот начнутся массовые сокращения? А если не массовые, то обязательно какие-то. И что зарплаты будут расти медленнее, а работу найти — сложнее? В целом нарратив зависит от компетентности ученого и обидчивости журналиста.
Что же мы, простые труженики клавиатуры, можем противопоставить этому нагнетающему инфополю?
Наш ответ — система ГУС: «Готов к увольнению и собеседованиям».
Комплексная система технико-психологической подготовки, которая включает:
Подкладывание подушки — накопить 3–6 окладов и не потратить.
Спринт по собеседованиям — пройти 5 созвонов за неделю и не сгореть.
Удержание оффера — получить оффер с +10% к текущей ЗП на фоне «мы все держимся».
Как бы выглядел оффер с релокацией образца XIX века.
Во второй половине XIX века десятки тысяч китайских рабочих были завлечены в США для строительства железных дорог, особенно Тихоокеанской трансконтинентальной магистрали. Им обещали высокие заработки и «новую жизнь», но по факту ждали ужасные условия труда, дискриминация, долговая кабала и невозможность вернуться домой. Это было де-факто рабство, замаскированное под трудовую миграцию.
А как бы выглядел такой оффер сегодня, если бы его постили в LinkedIn?
----
🚢🔥 Горячая вакансия! Релокация в США! 🔥🚢
Привет! Мы — динамично развивающаяся железнодорожная корпорация с офисами по всему Западу Америки. В связи с масштабным инфраструктурным проектом (🚄 Transcontinental Railroad) открываем набор на позицию Railway Infrastructure Engineer (Junior).
Что предлагаем:
📍 Калифорния, onsite
💼 Офер: вилка обсуждается, если не можешь есть руками
✈️ Полная релокация: парусник за наш счёт
🛏 Корпоративное жильё: земля, палатка, иногда яма
👥 Комьюнити: более 12 000 талантливых специалистов из провинций Гуандун и Фуцзянь
Что будет входить в задачи:
Прокладывание рельсов сквозь скалистые горы
Требования:
Умение работать 20 часов в сутки, не задавая вопросов
Устойчивость к взрывам, змеям, дизентерии и белым начальникам
Желание «изменить жизнь к лучшему» (не свою)
Английский не нужен, рот открывать не потребуется
Приятные бонусы:
🍚 Питание: рис, иногда тёплый
Нет налогов (и прав тоже)
✉️ Не упусти шанс! Присылай свою анкету (имя, возраст, пригодность к физическому труду) ближайшему рекрутеру в порту Гуанчжоу. Количество мест ограничено.
Почему нам стыдно верить в астрологию, а в программирование — нет?
Вот вам два примера:
Это Сергей. Он — архитектор, скорпион с асцендентом в раке и Кету в первом доме. Уверен, что ретроградный Меркурий влияет на то, когда нужно проводить встречи.
Это Николай. Он — бэкенд-разработчик, пишет коннекторы к месседж-брокеру в платёжном агрегаторе. Утверждает, что настоящий программист должен знать Таненбаума и делать всё по SOLID.
Современный, считающий себя прогрессивным человек посмеётся над Сергеем и кивнёт Николаю. Потому что держит в руках айфон — и он как-то работает, значит, эти «технологии» не вымысел. Хотя сам вряд ли объяснит, как это происходит.
Из этих двоих чаще оказывается прав именно Сергей — по крайней мере, он точно знает, когда не стоит катить на прод. А Николай… он не может объяснить, почему всё падает после его деплоя.
Но в общем и целом: Николай знает, как работает код — пока он работает. А вот почему он не работает, когда падает — уже нет. Сергей знает, как система должна работать, но не знает, как она работает на самом деле. И все мы делаем вид, что во всём разбираемся и только Меркурий — честно ретрограден.
Я внедрил скрам и не могу закончить ремонт на балконе.
Начинал всё по уму: разбил эпик на задачи, расставил приоритеты. Какие-то оценил сам, по другим — созвал консилиум. Привлек электрика: в команде не было экспертизы, хотя сын уверенно заявил, что справится. Оставим это на его совести — еще вчера он пытался вставить батарейку в игрушку вверх ногами, но делал это с таким выражением лица, что потенциал сеньора виден невооружённым глазом.
Проект, конечно, со спецификой: параллелить задачи сложно. Идею "я утепляю, а жена в это время красит обои, а потом как-нибудь сольем" мы отвергли сразу — архитектура не позволяла.
Поначалу шло бодро: за первый месяц 30% задач закрыто — утепление, 3 из 4 стен покрашены. Но как водится, наступил кризис ресурсов - внезапно вышел Kingdom Come: Deliverance II и съел все капасити ведущего разработчика. Прогресс застопорился.
Ретроспективы с женой проходят регулярно: я зажигаю команду речами о важности коммитмента, о наших ценностях и цели. Но стена всё еще не покрашена.
Дополнительные таски множатся: надо помыть окна по всей квартире, разобраться с дверцей шкафа, которая теперь открывается строго по фазе луны. Думаю, пора внедрять SAFe — горизонт проектов растёт.
P.S. Прогресса по основной задаче нет, но радует, что бизнес пока не планирует резать косты.
Вы наконец победили. Потратив большую часть карьеры на охоту за багами, вы достигли невозможного: багов нет. Вообще. Пусто. Доска с багами пуста, QA тихо плачет в углу, а CI-сервер бездельничает, ровно светясь скучно-зелёным цветом. Но вместо того чтобы попасть в рай, вы оказываетесь в лимбе. Если вы играли в игры начала нулевых, это похоже на выход за границы карты: голый ландшафт, странная геометрия и надпись от разработчика: «Ты не должен был оказаться здесь. Но раз уж оказался — молодец, конечно, только смысла в этом нет».
Что происходит дальше? Ничего хорошего. Первый сюрприз — вас никто не похвалит. Бонуса нет, промоушена тоже. Менеджер лениво листает ваш performance-review, хмурится и спрашивает: «А что ты делал весь квартал?» Ты отвечаешь: «Я избавил нас от багов». Он пожимает плечами: «Так они и раньше вроде не были критичными».
Кто-то бросится чинить метрики, и начнётся новый головняк, потому что вы уж слишком постарались. «Багов не может не быть, значит, сломана метрика», — уверены все. Предлагаете метрику «отсутствие багов» — слышите в ответ: «Недоказуемо, выборка мала!»
Вы думали, что победа откроет двери в рай, а распахнули портал в лимб, где невозможно доказать собственную полезность. Пару поколений инженеров мы упорно объясняли бизнесу, что «баги бывают, это нормально». Благодаря нам продакт-оунеры научились бравировать SLA с допуском на косяк. Мы воспели «умеренное количество дефектов» как здоровый холестерин IT-организма — и вдруг вы свели холестерин к нулю.
Парадокс: все процессы настроены на борьбу, а не на мир. Метрике нужен враг, а процессу — вызов. Без них графики плоские, алерты молчат. Добро пожаловать туда, где ваши достижения стоят ровно ничего. Вся организационная религия строилась на борьбе с багами. Уничтожив последний баг, вы «убили бога» процесса. Всё, что давало смысл (defect-метрики, ретро-ритуалы, баг-баунти), обесценивается; наступает инженерный нигилизм. Великая битва окончена, триумфаторов нет, система сломана. Баг умер — и ты его убил!
Совет: в следующий спринт оставьте пару багов — ради здоровья экосистемы.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
