Type-Safe Thoughts

Теперь книжный клуб можно слушать даже на парковке на всех популярных площадках!

📱 YT: https://www.youtube.com/watch?v=6BrRgKFBtuQ&list=PLHF2Yb-1Ap9w

📱 Яндекс Музыка: https://music.yandex.ru/album/44101122

📱 Apple Podcasts: https://podcasts.apple.com/us/podcast/bookclub-dotnet/id6815002287

📱 Spotify: https://open.spotify.com/show/4GEWFjTDuL8uYrSIz8iR2Q

#bookclubdotnet

Mea maxima culpa 2/2

На работе проводить постмортем сильно проще, чем в жизни. После технических решений обычно остаётся куча улик: ADR, документация, тикеты, комментарии в pull request, иногда даже нормальное описание задачи.

По ним хотя бы можно восстановить контекст для проведения дальнейшего разбора, ответив на вопрос: "А какую задачу вообще решали?"

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

Когда результат уже известен, включается hindsight bias: прошлое начинает казаться гораздо более предсказуемым, чем было на самом деле. А outcome bias подталкивает оценивать качество решения по результату — хотя хорошее решение вполне может закончиться плохо, и наоборот. Анализировать левую часть графика может каждый.

В итоге постмортем проводится уже не над тем решением, которое я когда-то принял, а над его слегка отредактированной версией.

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

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

С остальными решениями, кажется, должно работать так же.

Mea maxima culpa 1/2

Однажды я так удачно спроектировал микросервис, что потом всерьёз хотел потратить отпуск на его переписывание.

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

Ownership. Ответственность. Работник месяца, желательно с повышением зп и грейда.

План разбился об неожиданную особенность командной разработки: в ней есть команда.

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

Оказалось, что код был едва ли не самой дешёвой частью переписывания, а мой отпуск — не единственный ресурс компании. Странная система :))

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

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

Для таких случаев в IT есть такое понятие как postmortem — разбор инцидента после того, как всё починили.

Хороший постмортем отвечает на несколько вопросов:
• что произошло;
• кого и что затронуло;
• почему это стало возможным;
• как проблему обнаружили и исправили;
• что изменить, чтобы она не повторилась.

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

Ещё постмортем должен быть blameless — без поиска виноватого. Фраза «Вася нажал не туда» не объясняет, почему одна кнопка могла положить прод.

Нужно спросить: почему изменение прошло ревью? Почему его не поймали тесты? Почему откат занял сорок минут?

Иначе единственным пунктом в последнем разделе документа станет «попросить Васю быть внимательнее». Надёжность системы на этом не построишь, а Вася попрощается со спокойным сном

…

Я хочу, чтобы ИИ меня заменил

Мне нравится идея, что ИИ будет писать за меня как можно больше кода.

Серьёзно. Я не получаю особого удовольствия от сотого CRUD-а, перекладывания DTO или очередного маппера. Если задачу можно один раз нормально описать, через минуту получить diff и заняться чем-то более интересным — прекрасно.

Но тут есть тонкая грань, которую я все еще пытаюсь нащупать: это всё ещё я управляю ИИ или он уже начинает заменять меня?

Для себя я сформулировал ее через вопрос: могу ли я оценить результат? Понимаю ли я, почему решение устроено именно так? Могу ли провалидировать работу агента?

Если без ИИ я сделаю ту же работу, просто медленнее, — ИИ остаётся инструментом.

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

И тут возникают два вопроса:
• На ком тогда ответственность за работу системы?
• За что мне вообще платят?

Когда сгенерированный код положит прод, на postmortem пойдет не Claude, а я. Ответственность, за принятые по изменению системы решения, всё равно остается на человеке, даже если его принятие было делегировано агенту.

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

Но если я не могу объяснить diff, который тащу в прод, то ИИ превращается из моего инструмента в причину моего увольнения.

Софт-скиллы хардовее хард-скиллов

Я довольно долго верил в простую формулу профессионального роста: чтобы стать сильнее, нужно больше учиться.

Прочитай ещё одну книгу. Разберись ещё в одной технологии. Посмотри ещё один доклад. Покопайся в исходниках. Напиши очередной пет-проект. Сдай ЕГЭ!!!

Для меня это стало очень удобной формой прокрастинации.

Потому что компьютер — довольно простой собеседник. Не понимаешь, как работает async/await — можно открыть исходники. Не понимаешь PostgreSQL — документацию. Код не работает — есть дебаггер.

У технической проблемы почти всегда есть правила, в рамках которых её можно расковырять.

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

И главное — софт-скиллы почти невозможно прокачивать в стол.

Можно годами становиться технически сильнее, не выходя из комнаты: читать, программировать, экспериментировать, ментально мастурбировать. А чтобы научиться договариваться, убеждать, выступать и разрешать конфликты, нужны другие люди. Люди, которые будут не понимать, не соглашаться, раздражать. Иногда считать идиотом — и иногда даже оказываться в этом правыми :)

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

Харды сами по себе от этого не обесцениваются. Просто отдача от каждого следующего часа, вложенного в них, постепенно уменьшается. Если совсем вульгарно натянуть сюда принцип Парето: базовые 20% хардов дают большую часть результата. А изучение остальных 80% является уже неоправданно дорогим способом стать ещё чуть-чуть лучше в том, в чём ты и так хорош.

Несмотря на то, что этимологически заголовок поста абсолютно бессмысленен, ввиду того, что приставки hard и soft вообще не про сложность освоения, для меня всё получилось именно так: софты гораздо хардовее хардов.

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

Теперь понял 🧠

Вдохновение от Runtime Async переросло в благоговение желание закопаться поглубже. Но одним желанием сыт не будешь, я себя знаю, лень бы мне стало уже на следующий день. Что делать? Правильно, связать себя внешним обязательством. А вот и оно:
https://ecode.ozon.tech/talks/20010690/

P.S.
Наконец-то посещу E-CODE. В прошлом году даже слушателем попасть не удалось :(

P.P.S.
Вот бы вдохновение писать в канал приходило чаще, чем раз в год :)

После сравнения подписок клода и кодекса за $20, окончательно остановил свой выбор на поделке Open AI. Принял волевое решение апгрейднуть подписку до Pro x5 (та, что за $100), пока нравится, я даже убеждаю себя в том, что вижу заметную разницу в качестве ответов. Но есть ощущение, что лимиты по токенам около-бесконечные.

Как люди высаживают подписки за 200 баксов, где лимиты еще в 4 раза больше? Нужно вайбкодить даже на парковке? Отказаться от какого-либо взаимодействия с миром, кроме как через агента, вплоть до заказа еды и подбора музыкального плейлиста? А может давать задания типа "сам придумай чем тебе заняться, но чтоб завтра я разбогател, make no mistake" или "когда фондовый рынок РФ перестанет падать"?

👀 Аж в феврале вышло 1 превью .NET 11, ровно тогда же я почитал релиз ноты и захотел написать пост... долго же я собирался. Что же меня так зацепило? Оптимизация асинхронной модели, хотя это не единственная интересная фича, про нее и будет этот вводный пост

🤯 Издревле (.NET Framework 4.5 – 2012 год) так сложилось, что механизм асинхронности в C# реализован через явную пометку пользователем цвета функций – через ключевое слово async, и такое же явное обозначение точки приостановки (suspension) – через ключевое слово await. Многими даже считается, что именно C# стал основным популяризатором такого подхода в свое время.

🚀 Тем не менее время шло, и в новых языках – необремененных еще необходимостью поддерживать обратную совместимость с 100500 предыдущими версиями – стали появляться более эффективные, но менее гибкие подходы. Главным контрпримером обычно выступает Go с легковесными потоками, которые планируются рантаймом поверх обычных тредов операционной системы. При таком подходе программист может не задумываться о всем вышеперечисленном, вплоть до полного непонимания что такое асинхронность. Сравнивать эти модели с точки зрения удобства и гибкости сейчас не будем – это тема как минимум отдельного поста (ставьте классы)

😭 А вот с точки зрения стоимости исполнения у C# есть проблемы: за выразительность приходится платить достаточно сложной инфраструктурой под капотом. Так что на перфоманс-сравнение с Go, мне как C# разработчику, больно смотеть. Вот и разработчики из Майкрософта, кажется, так подумали и решили наконец что-то сделать. Этим “что-то” стал runtime-async – оптимизация, которая сильно облегчает рантайму обработку асинхронных операций, не меняя с точки зрения пользователя ни синтаксис, ни семантику существующего async/await.

😨 Хоть runtime async пока и находится в превью, очень интересно видеть, что результаты некоторых бенчмарков говорят об улучшении не просто на проценты, а в разы! Так, в последнем превью мы получили 6357.1 ms → 457.1 ms времени выполнения для async методов, возобновляемых после OSR-оптимизации.

Интересно разобрать откуда такой выигрыш и как это работает под капотом?