Тут спрашивали (никто не спрашивал, кого я обманываю), почему я ратую за 100% покрытие кода тестами. Эта трагикомедия на 40 минут раскрывает большую часть тезисов и проблем тех, кто любит утверждать следующие:

1. 100% cc не спасает, если тесты написаны ради цифры.
2. 100% cc не гарантирует что багов нет.
3. 100% cc мешает деливерить фичи, т.к. тесты ломаются и заставляют себя чинить.

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

Очередная (последняя) серия из душных лекций.

https://youtu.be/MavGp3MR5xc

#oxygenless #pygorust #lections

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

Так однажды, компания с романтичным названием "Ibis" получила заказ на создание очередного супер проекта. И там должно было быть всё на свете. И сверх UI/UX. И невероятные распределенные и децентрализованные хранилища с шифрованием и сверх надежностью, хранящие петабайты всего на свете. Только вот пока придумывали, по традиции, проект. Пока презентовали, пока писали ТЗ (такое, чтобы никто не смог другой тендер выиграть), пока проводили тендер и все прочие вещи. Очень устали.

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

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

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

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

Посему под громогласные аплодисменты, приемочные испытания были признанны успешными. И проекту выделили новые деньги на следующий год, а за этот год сотни миллионов Großmar'ок улетели в карман предприимчивых бизнесменов. А наша светлая голова успешно создавал проекты, занимал потом высокие должности вроде СТО. Считался признанным экспертом. Не то чтобы уж совсем незаслуженно. Но в первую очередь за смекалку.

Мораль довольно проста. Софтскиллы эт именно про это. Не будет у вас никакого карьерного рост, ежели неготовы врать не краснея и делать великие вещи за счёт других. Это и есть Softskills in action.

Главное ведь, что? То, что если не пойман - то и не вор.

#fridaytales #tales

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

Лично для меня, микросервисы не являлись чем-то новым ни в момент прочтения книги, ни в момент рождения термина (собственно авторство пытается монополизировать автор книги - Крис Ричардсон), ни за 7 лет до момента его рождения.

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

Из недостатков, стоит отметить, слабую доказательную базу.

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

Но для того, чтобы писать микросервисы, автор вводит информацию о DDD (Bounded Context, Aggregates), о разных архитектурах организующих код и в конечном итоге десяток с лишним паттернов разработки и решения проблем собственно связанных с микросервисами. В этом нет ничего плохого, т.к. тема сложная. Но основной лейтмотив книги оказывается не раскрыт. Внимательный читатель лишь задаст резонный вопрос - "а почему, всё таки нельзя наговнякать в микросервисах то же самое, ведь потенциал для этого выше?".

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

Несмотря на то, что в какой-то момент я начал душиться и перелистывать очередную воду связанную с "монолитом" и блоки бессмысленного кода (лично для меня), практическая польза от книги имеет место быть. Как минимум для систематизации терминов, понимания того какие вообще шаблоны есть и как называются и понимания типовых проблем и методов их решения.

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

На русском языке книгу издавало издательство "Питер": https://www.piter.com/product/mikroservisy-patterny-razrabotki-i-refaktoringa

#bookshelf

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

А в рамках компенсации хотелось бы оставить очередной вброс про AI, Wipe Coding (и да, я, как всегда, не ошибся) и мое безбедное и беззаботное будущее. Последний год, я с удовольствием читаю новости, статьи и всевозможные видео интервью в которых люди обсуждают как искусственный интеллект бодро меня заменит. Или заменит джунов, или заменит мидлов. Или
я должен буду превратиться в архитектора и прочая прочая прочая.

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

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

Последние 10 лет я наблюдаю одни и те же истории. Заглушенные линтеры, отсутствие юнит-тестов, анти-паттерны в коде, просто плохой и не работающий код, наивные реализации. Теперь добавился код, который человек наивно предполагает работающим,
но таковым не является. Что удивительно, аргументы в защиту глупости, подвергнутой остракизму десятилетия назад, плодятся. Люди, защищающие плохие подходы, лишь увеличиваются численностью год от года. Но только не в публичном поле.

Каждая вакансия содержит мантру умение или обязанность "писать unit-тесты", но ни на одном из собеседований не проверяется это умение. Говорящие же головы утверждают, что вот конкретно тесты то AI-пишет отличные (спойлер: нет). Нужно уметь писать качественный и высокопроизводительный код (но конфиг линтера вам никто не приложит к вакансии, а число
quality gate'ов не перечислит).

Но при чём тут wibe coding, спросит меня читатель. Мне пока не попадались творцы заклинаний, которые генерировали бы код высоких стандартов. Вот сгенерировать микросервис на пару тысяч строк кода, к которому будут замечания базового строгого линтера как на скрине - это пожалуйста. Чудес снова не случилось, банкет отменяем. Результат генерации требует пост-обработки и без определенных навыков (умения читать код) обойтись всё равно не получится. И те кто на вайбе смогут создать работающие стартапы в итоге всё равно будут вынуждены приходить к старичью, чтобы оно их оживляло с помощью шоковой терапии.

Это лишь в фантазиях сумасшедших мир плоский, стоит на спинах трёх слонов, которые танцуют степ на панцире большой черепахи. Настоящий мир конечно же не такой. Это скучный шар из кремния в разной форме и состояния. Залитый унылыми серо-синими морями. Но всё это не относится к Großland ни в коей мере. Это колоссальная по размерам страна настолько велика, что ее две столицы расположились на спинах у дохлых слонов, которые, зловонно воняя, разлагаются на панцире у напившейся в стельку черепахи, плывущей в океане в абсолютно шокированного от данного факта мир.

Только в настолько безумном месте и могла произойти эта история.

В темные, для страны времена, один предприимчивый человек и его товарищи (те самые, которые легко могли порезать людей на части и скормить свиньям) решили создать предприятие. Которое перевозит спиртосодержащие флаконы из других стран в Großland, дабы ликвидировать дефицит. И пользуясь всяческими ухищрениями, они создали устойчивый бизнес. Компанию
иронично назвали "Broiler-228" и её вывески год за годом расползались по каждому более или менее крупному городу в стране.

Спустя целых 15 лет компания стала крупным ритейлером. Важным участником рынка и практически синонимом целой отрасли. Внутри же компании установилась любопытная культура. Люди там работали буквально только на одной работе - на этой. Ты покидал университет и оказывался джуном в айти-отделе и спустя 5-10-15-20 лет всё ещё работал здесь же. Таким человеком и был CTO компании и его зам. В их трудовой книжке было как раз единственное место работы. Все воспринимали компанию как семью, свою семью и своё творение. Что не было проблемой, пока у руля стоял Отец-основатель.

Однако быть бизнесменом это сложный и опасный труд. И Основатель в прямом смысле сгорел на работе. На втором десятке, тяжело заболев и отправившись в мир иной. Оставив наследников — жену, дочь и сына. Часто в таких историях начинается крутое пике. Т.к. наследники слабы и хилы и постепенно разбазаривают бизнес. Или его крадут партнеры. Но Мать, была не такой и как смогла взяла власть в компании.

Именно тут и начинается наша прекрасная история. В компании был архитектурный ландшафт DelphiusDB - как лучшая энтерпрайзная база данных на свете использовалась практически во всех айти решениях. И тут СТО компании неожиданно пришёл к мысли, что большая зарплата и просторный кабинет недостаточен для счастья. Хотелось этого же, но до конца жизни. Да и вообще оказалось, что мы все семья, но вот Мать и её дети - больше семья. И теперь компания вообще не наша.

И у нашего бодрого директора, возникла идейка. Обкашляв с замом, он создал компанию "Broiler 229 Technoligies" в соседнем и союзном государстве — Weißland'e и постепенно нанял туда большую часть сотрудников IT отдела. По итогу, все компетенции оказались там, а компания "Broiler-228" теперь платила за собственных сотрудников дань своему бывшему СТО.

После чего, передав дела, своему заместителю, наш доблестный СТО был таков. Следующие 2 десятка лет, он получал приличную маржу на том, что изначально принадлежало той самой компании, в которой он был членом семьи. И которая сделала его приличным человеком.

Но не один наш хитрый инженер считал, что деньги компании "Broiler-228" это его деньги, а не деньги собственников. Но
о следующей великой афёре уже в следующий раз. Сериал будет долгим и весёлым.

Пока же мораль проста. Бойтесь не профессионалов, за деньги работающих, а тех, кто вам как собственные дети. Именно они и обманут вас и будут рассказывать про "интересы бизнеса". На протяжении всех последующих серий.

#tales #broiler228

Если послушать дискурс HRюш, то нет более надежного и верного сотрудника, нежели человек, проведший в компании десятилетия. Человек, пожертвовавший собственным доходом и карьерой ради того, чтобы некогда небольшой бизнес рос и крепчал, становясь большой корпорацией. Особенно в Großland'е, где изменчиво всё и повсеместно.

На беду "Broiler 228", таких людей в компании оказалось много. И прямо уж скажем, каждый второй (а то и первый)
руководитель. Будучи большим ретейлом размазанным продажей спиртосодержащих жидкостей в каждом крупном городе страны, "Broiler 228" сильно зависели от логистики. Для ритейла очень важно, чтобы в каждом локальном магазине были именно те товары, который покупает каждый второй заходящий. Пусть и не самые дорогие, но зато очень популярные.

В бытность своей истории компания связалась с Альфой и Омегой всего бизнеса страны — с "Großbank", а точнее с одним из подразделений формирующейся монополии — "Graphologist". Год от года бизнес рос и росли логистические доходы первого и крупнейшего банка Großland'a. Пока руководителю банка Ингланду Бубну не пришла в голову мысль о том, что все эти ритейл компании и онлайн магазинчики дескать развиваются и конкурируют с ещё одним детищем — "Großultramarkt" — приобретённой компании маркетплейса. Светлая голова банкира выдала идею: расторгнуть договора с клиентами "Graphologist" и обеспечивать только потребности в логистике своего собственного маркетплейса. Однажды мы эту историю раскроем и с этой стороны.

Для "Broiler 228" это был довольно серьезный удар. Так как теперь нужно было выстраивать систему доставки с нуля. И тут
внутренние логисты компании предложили "сэкономить" и выстраивать свою систему, чтобы больше не оказываться в западне контракта с большой компанией (которую потом могут тоже поглотить). Будем возить частниками, и развивать свою систему.

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

Беда снова пришла оттуда, откуда не ждали. Каждый обогащающийся лояльный логист и не думал о том, что последствия будут столь драматические. Чем медленнее и дороже становилась логистика, тем реже наполнялись полки магазинов. В том числе теми товарами, которые люди чаще всего и хотели купить. В итоге доходы компании стали падать. Люди понимая, что просто так по дороге домой нельзя зайти и найти нужную спиртосодержащую жидкость, нашли простой выход. На не столь уж важном и значимом для компании сайте они начали делать заказы с доставкой в ближайший им магазин. Дабы найти товар и забрать от туда.

Результат оказался ещё жестче. Так как нагрузка на логистику возросла, наличие номенклатуры на складе магазинов ещё
медленнее наполнялось. Но что хуже — бедный и несчастный сайт, в основе которого лежали хранимые процедуры по 5000 строк кода в DelphiusDB, просто стал падать и терять покупателей. Если раньше магазины в оффлайне приносили основные в продажи, то теперь всё по-сути строилось через продажи с сайта. И в высокий сезон компания понесла потери, поставившие под вопрос её прибыльность.

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

#tales #fridaytales

Последние два дня оказались непростыми. Тем любопытнее мысль посетила сегодня, о книге, которую я прочитал за 3-4 дня полгода (где-то) назад.

В момент чтения я ловил себя на мысли, о том, что непонятно зачем я вообще купил и читаю книгу "Грокаем конкурентность". Большая часть текста, примеров и кода оказались обычными и самоочевидными. Большинство освещенных тем бесперспективных и бессмысленными. Несмотря на прекрасную статью на хабре (которая и продала мне книгу), остальной материал оказался совершено неувлекательным. Главный вывод, который я тогда для себя сделал, что эта книга безусловна не бесполезна, но почти не заслуживает ни освещения, ни внимания. Есть и есть.

Тем фантасмогоричны события, происходящие сейчас. Оказываясь на собеседовании, я вижу в целом неплохих (наверное) молодых инженеров, которые понимают конкурентность исключительно в одном единственном аспекте. В том, как устроен рантайм го (помните книгу про 100 ошибок? 2 главы от туда) и весьма посредственно понимают всё остальное. И думаю, что эта книга абсолютно точно помогла бы систематизировать понимание о параллелизме, конкурентности и том, в чём конкретно хорошо то или иное решение.

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

Если вы ловите себя на мысли, что вам непонятны слова вроде "семафор", "барьер" или "атомарность". Или не понимаете отличие "конкурентности" от "параллелизма" - вам сюда. А когда разыграется аппетит, можете отправляться в любимую книгу Подольского.

Единственное я бы не рекомендовал покупать бумажную версию книги. Ни ее форма, ни содержание не заслуживает всё таки места на полке. Всё же это книжка для джуниора и лишь самое начало в прекрасный мир абсолютного безумия:
https://www.piter.com/collection/seriya-grokaem/product/grokaem-konkurentnost

#bookshelf

Ландшафт мира дрожал от новой идеи, той самой, которая помогла Großtech'ам бурно расти и завладеть умами кодерков. Микросервисы! Вот это сила! Вот где истина, вот где серебреная пуля. И раз уж сайт "Broiler 228" оказался неспособен выдерживать нагрузку и все попытки CTO II исправить ситуацию не удавались, настал момент трансформации. Истинной платформизации!

Под это дело большие полномочия получил IT-директор. Став CTO платформизации. Под это гиблое дело, он выбил себе бюджет и решил сделать всё по науке. Обратился к известным компаниям за консалтингом и на протяжении целого года, занимался выработкой стратегического плана развития IT в компании, которая до этого в целом занималась спокойной продажей спиртосодержащих жидкостей, на бескрайних и безумных ландшафтах крупнейшей страны мира. На консультации было потрачено 150 миллионов Großmar'ок. Сумма, мягко говоря, не маленькая.

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

За прошедшие годы, CTO II нанимал разного рода экспертов в компанию, цель которых была не делать что-то, а составлять
экспертизу по техническому ландшафту. Быть консультантами и советниками технического директора! В результате любой
катаклизм удавалось преодолеть, ведь эксперты по DelphiusDB находили решение и путь в лабиринте хранимых процедур и раз за разом CTO получал реноме компетентного и талантливого инженера. Но, все же помнят первую главу, в его интересы всё так же не входило менять текущее решение и заниматься платформизацией. Он доблестно занимался латанием тонущего (по-мнению владельцев) судна и конечно же талантливо вставлял палки в колёса в платформизацию. В будущем, пока он просто оставался в тени.

На платформизацию и ее реализацию выделено было 250 миллионов Großmar'ок. Цена 5 комнатной квартиры в историческом особняке в центре столице страны - Großdorf'e. Прошло 3 месяца и финансовое состояние компании стало тревожить владельцев и "люди" захотели узнать что там с платформизацией. Бюджеты еле удавалось свести к минимальным прибылям, ожидаемые дивиденды были не впечатляющими и IT директора вызвали на ковер с вопросом "ну что, как там".

Мало кто ожидал, что директор даже не придёт на совещание, а напишет заявление об увольнении по собственному желанию с просьбой "не выплачивать ему годовую премию в размере 6 миллионов Großmar'ок (6 окладов своих к слову)", после чего - будет таков. Инвентаризация наследия талантливого управленца выявит, что за прошедшие месяца было нанято 0 человек. Написано 0 строк кода. Сделано 0 каких либо задач. И осталось ровно 0 - Großmar'ок из выделенного годового бюджета.

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

Главный вопрос, который мучает нас. Как же так вышло, что "люди" (те самые совладельцы с
самого создания компании) - которые успешно в темные времена пересаживали кожу с людей на барабаны, отпустили ловкого и лояльного специалиста в туман?

Ответа мы не знаем (пока), но держимся концепции того, что Großland выдуманная страна и happyend'ы тут, в отличие от настоящей жизни, видимо случаются.

В то время как компания осталась с проблемой (как делать платформизацию), без денег на её решение и лидера для управления процессом. Мы минуем мораль и отправимся на отдых. Невозможно раз за разом напоминать, что нанимать надо компетентных профессионалов, а не софтскилльных жуликов. Тех что утащат у вас в итоге 400 миллионов и не оставят даже документа на пару страничек как артефакта.

#tales #broiler #broiler228

Меня впечатлило мнение комментаторов к моему интервью, о том, что уж софтскиллы то мне помогли бы. Поэтому я последнюю неделю давясь дочитывал прекрасную книгу - чтобы спасти вас от её чтения.

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

Поэтому надо понимать, что за книгу с названием "Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты" я приобрел с особым настроением. "Наконец-то мне не только объяснят, что же это за зверь такой, да ещё и получу работу мечты!!!".

В действительности книга наполнена большим количеством очевидных вещей и значимой частью того, что в российских реалиях можно считать глупостью. Скажем попытка "посчитать" стоимость сотрудника в компании и таким образом оценить, что компания не должна повышать вам зарплату, иначе как вредительством определить нельзя. Тем более что ранее в книге автор пытался научить читателя торговаться за зарплату и приводил совершенно бессмысленный в реалиях РФ пример — когда он согласился на снижение зарплаты в пользу получения опциона с 50% скидкой к цене акции компании взамен.

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

Многие темы, вроде лидерства — раскрыты плохо, хотя и многословно. Лидерство у мягконавычных это способ управлять, увольнять и нанимать. Но не вдохновлять и не организовывать. О способах как организовывать коллективы инженеров не сказано вообще ничего. Зато примерно 5 листов посвящены тому, какие мы все разные и как важно, чтобы черные девушки
учились программированию.

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

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

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

Книга может быть полезна, как и любая другая. Упражнения и некоторые методы могут помочь в нелегком и бурном море хаоса, которым является современный "гибкий" мир. Но если честно, это просто бездарно потраченная целлюлоза. Так что наше милое сообщество токсичных стариков в очередной раз оказалось право. Займитесь просто делом и развивайте настоящие навыки. Ну или как советует в целом автор — сливайтесь в управление или консалтинг. Инфоцыгане (вроде автора) зарабатывают больше чем инженеры.

PS: книга на сайте издательства https://eksmo.ru/book/prokachay-kareru-soft-skills-dlya-it-spetsialistov-ITD1280304/

#bookshelf

На работе смотрим онлайн трансляцию Golang Conf. Ключевой вопрос, который мучает меня уже половину потраченного времени это ЦА этого мероприятия. Залы полупустые, контент докладов с форматом в 30/40 минут это примитивные обзоры достойные места где-нибудь на habor'e, а не на профессиональной конференции.

Большая часть кода, что я видел, состоит из примеров на Си. Для меня сие не является проблемой, т.к. я писал и читал код на этом языке и понимаю проблематику которую озвучивает автор доклада, но непонтяно как всё это связано с языком "Go". Да и зачем нужно программистам на го, которые нынче просто замена Java code monkey.

Из непосмотренного и ожидаемого доклада остался только материал от "Островка" про то как матчить отели с самописной in-memory базой данных. Исключительно из любви к компании где работал дам шанс и поболею за то, чтобы не было как то, что уже видел.

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

Хотите примеров? Ну вот доклад про Swiss Map, которому противостоит ролик от Олега Козырева на ютубе. Или чревовещание от Даниила Подольского на тему дженериков - получилось и не о дженеирках и с низкой дидактической ценностью. О да, я знаю, что движующим обоснованием этой секции является термин "как устроено под капотом". Но при этом крайне вторично и учитывая прятанье это за пейволом - ещё и бесполезно.

Напомню, что стоимость билет доползла (по слухам) до 40 тысяч рублей, а образовательная и профессиональная ценность выступлений околонулевая.

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

#golangConf2025

Доклад Ивана Комберта, кстати, был неплох. Он даже полезен для тех, кто не занимался разработкой баз данных или не читал любой материал про внутреннее их устройство.

Это первый доклад у которого мы просмотрели Q/A секцию до конца и даже глянули награждение тем, кто задавал вопросы. И тут я был опять вознагражден за свое терпение. Как и в книге про софтскиллы я оказался вознаграждён неожиданным роялем в кустах.

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

P.S: подскажу, что это можно назвать, например, китайским салютом.

#golangConf2025 #newsalute

Разработчики часто думают о том, как несправедлив к ним найм. Что вокруг одно легаси (хотя кто в этом виноват?),
неадекватные менеджеры и все стараются выманить их с удаленки в офис. Но ситуация, в которой оказывались люди
отзывающиеся на вакансию СТО Платформизации в Broiler 228, была куда анекдотичнее.

Итак, компания потратила 250 миллионов Großmar'ок годового бюджета на консультации за месяц. После чего встал вопрос, что делать и как быть. Обращаться к совладельцам, никто особенно не желал, а планы по переезду на микросервисы нужно было исполнять.

В итоге была размещена вакансия с совершенно сумасшедшими цифрами - за 450 тысяч Großmar'ок в месяц (в 3 раза меньше предшественника, кстати), будущий директор должен был перевести монолит на микросервисы, не нанимая людей (т.к. бюджет 0). Ему оставляли и оплачивали тех людей которые уже были и времени в целом было в обрез, т.к. пока суд да дело шёл уже 5й месяц. Ну а если будет достигнут успех к началу года, то счастливчику позволяли забрать премию, от которой отказался предыдущий платформизтор - целых 6 миллионов Großmar'ок.

Люди приходившие в светлый офис крупной национальной компании "Broiler 228" слушали всё это и впервые в истории найма в Großland'e именно они говорили HR'ам и "нанимающим менеджерам", "мы подумаем и свяжемся с вами". Вереница задумчивых связистов была поистине бесконечной. Месяц за месяцем и лето шло к концу. Идиотов не находилось.

Все это время СТО компании конечно всячески тормозил любой процесс распиливать монолит и тщательнее прятал в компании и её бюджетах своих экспертов консультантов. Замечательные логисты устраивали прекрасную жизнь своим родственникам, а два СТО (бывший и нынешний) продолжали выводить деньги в свою аутстафф компанию.

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

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

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

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

1. Сервис каталога SKU должен выдерживать 5 тысяч RPS.
2. Сервис обработки заказов 2 тысячи.
3. ....
4. Profit!

На эти жалкие 4 месяца до конца года вся вселенная затаила дыхание. СТО II изнервничался. А "бизнес" в лице
собственников воодушевился. Близился высокий сезон нового года, тот самый в который компания продающая спиртосодержащие жидкости зарабатывала большую часть своей выручки за год. Никогда ещё судьба нескольких миллиардов не зависила от человека с зарплатой несчастного джуна с 3+ годами опыта.

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

#tales #fridaytales #broiler228

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

А т.к. существует некоторый запрос, на контент и некоторые советы от старика (а 5 новых книг одновременно читаются как-то медленно), то запустим завтра новую рубрику "Метод деда", где буду показывать некоторые свои исследования и подходы к формированию дизайна и программированию.

Присаживайся сынок. Зря ты разбудил дедушку от его летаргического сна после работы. Придётся послушать теперь одну очень старую историю.

У одного незначительного видео сервиса, что торчал на севере Москвы, работал один мидл. И оставалось то ему работать
три дня и три ночи, до его первого года. Так уж вышло, что очень он любил кушать и обучился ремеслу на стороне.
Приписал себе опыт работы пару лишних лет. Очень уж хотел понравиться девушке Олесе из соседнего подъезда.

Дело у них шло на лад. Да и после года можно было бы уже ходить к HRам из других компаний и искать себе работу приятнее.Больно уж нищебродские зарплаты всегда были у видео сервиса.

А в сервисе служил ещё один эффективный прапор. Гад редкий. Не понравилось ему как мидл общается с джунами в интернете.
И как-то ночью, когда мидл уснул, подкрался к нему директор направления с красным пожарным топором и уволил его.
Послал всем HRам личное дело с "волчьим билетом" в котором написано было, что погибла карьера парня -
упала ночью на топор и погибло его личное дело.

Прошло два года. Обгрызли HRки все ногти в поисках мидлов. А эффективный менеджер собрался на повышение. Собрали в общем корпоратив. Собрались все: и СТО пришёл и HR директор и дружки менеджеры направления.

И тут! Стук в дверь!

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

- Ты кто?! - крикнул прапор незнакомцу.

А парень то наш капюшон откинул и глаза выпучил и как закричит - "Я ЧЁРНЫЙ МЕНТОР, ТВОЮ МАТЬ! Ха-ха-а!"

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

И с тех пор Чёрный ментор ходит по свету, ищёт новые контракты и менти и нет его черной волчьей душе покоя.

Так уж получилось, что я крайне везучий человек. Всё началось с кранча на работе. А потом мне повезло сломать в предплечье обе кости левой руки.

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

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

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

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

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

Мне повезло, что меня посетил руководитель (когда ещё дождешься от СТО ананас в подарок), а молодые товарищи устроят паломничество в больницу с ягодами и фруктами скрашивающими наш больничный быт. Узнать что они там расписали визиты по дням, чтобы поддержать меня и скрасить в итоге наш быт.

Вот только боевой дед под мою выписку (на вторые сутки после операции) начал кашлять и я обнаружил что в корпусе
московской больницы сданном (опять везение) только 2 недели назад разваливаются стеклопакеты. Я засавил сестер вызвать ремонтника и просил трижды врача обратить внимание на кашель и состояние человека который оставался с ними.

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

Я несколько раз звонил просил его обращаться с любой просьбой. Ясно было что персоналу не до него. Дела погребли меня.

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

А вечером мне позвонила его неподражаемая супруга и рассказала о том что он умер из-за двухстороннего воспаления легких.Человек в кровать которого попала зажигательная бомба в осажденном Ленинграде был убит простым человеческим равнодушием. Ровно так же как и 25 лет назад мой дед. Участь и адмирала и рабочего из одной эпохи оказалась одинаковой.

Мне действительно повезло. Я остался жив. Вокруг оказалось неожиданно много молодых, энергичных людей с большими сердцами. Которым почему-то было не всё равно. Они и могучий старик вдохновили меня на небольшой трудовой подвиг - 30 сложных технически проблем за 1.5 недели. И именно понимание того, что эти люди всё же есть помогают пережить утрату И удивительная книга "Море моё" последний экземпляр которой остался у меня как память о том что случилось. Не знаю как вы сможете её найти, но если получится - прочитайте она стоит того.

#bookshelf

Карго культ - часть нашего общества. Так и System Design Interview - часть процесса современного найма. В пятницу я вернусь, еще к тому как вершатся судьбы дизайнов систем и архитектур с традиционной сказкой. А сегодня будем готовиться к лютому контенту по сурьёзу.

В конце прошлого года издательство "Питер" перевело книгу с легендарным названием "System Design пережить интервью".

В этот момент я готовился пройти очередной этап в 4 месячном раунде собеседований в одну из компаний (о чем тоже стоит написать отдельно, жаль сломанная рука мешала) и посчитал смешным взять эту книгу прочитать её за неделю до собеседований.

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

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

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

Может для прохождения интервью в FAANG это и подходящее руководство. Но для российских реалий чрезмерное.

Однако же быть умнее чем требуется не так плохо - хотя бы смешно наблюдать за происходящим безумием на архитектурных комитетах. Главное не умрите от духоты языка автора. Пережить книгу само по себе будет достижением.

Ну и хоть в кулуарах и обвиняют меня, что я рекламирую издательство "Питер", жаль шо мне не платят.

Как всегда в конце ссылочка на книгу: https://www.piter.com/collection/all/product/system-design-perezhit-intervyu
#bookshelf

Особенность найма в Großland'е суровы и непредсказуемые. С одной стороны всех заменит GroßIntellekt, с другой стороны
найм свежего мяса не прекращается. Стоит лишь диску этого чудесного мира повернуться и прямо на севере Großdorf'a
наблюдателю посчастливилось бы увидеть офис компании "InDeKont". Блеск дипломов сотрудников которой, когда-то, освещал
внутренние помещения по-чище, чем лампы прожектора.

Но так уж получилось, что со сменой СЕО изменилась и стратегия найма. Оказалось, что невомзожно поддерживать свою
внутреннюю разработку на технологиях 20 летней давности уже невозможно. И в связи с этим компания запустила карусель
найма. Однако владеет теперь компанией некий ХОЛДИНГ и посему совершенно невозможно предоставлять людям конкурентные
зарплаты. А кого тогда мы будем нанимать? Правильно - кого попало.

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

Конечно же на первой фазе интервью было всё что нужно:

Замечательные задачи на то, что произойдет если мы будем пытаться мутировать иммутабельный слайс:

a := make([]int, 0, 5)
b := append(a, 1, 2, 3)
c := append(b, 4, 5)
a = append(a, 3, 2, 1)

fmt.Println(a)
fmt.Println(b)
fmt.Println(c)

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

Ну и венец - написать конечно же in memory cache. Задача безусловно достойная будущего тех лида, на позицию коего и
собеседовали нашу птаху. В какой-то момент времени, я аж включил ее в состав "примера"
(https://github.com/godepo/groat/blob/main/example/example.go#L32)к своей библиотеки для тестирования на го, чтобы
просто воспроизводить по памяти с надутыми щеками.

Самое кошмарное заключается не в том, что пройдя такое собеседование разработчик с улицы может стать техлидом или
сеньором. Самое дикое, что именно такие кеши они потом в продакшене и пишут. С мьютексом и маппой. ХОТЯ. Буквально за
15 минут до написания кеша их спрашивали про то как решается коллизия ключей в этой структуре данных.

Итогом первого собеседования стало понятно - цель это не сеньоры и техлиды. Цель найма это джуниоры с пятилетним
опытом. Но тем интереснее становился приз. Ведь за этот "WEEKEND OFFER", предлагался прекрасный приз - зарплата по
результатам собеседования и даже получение грейда и лычки в соответствии с ним. Казалось бы еще чуть-чуть - пара тройка
собеседований (а как без этого) и мы окажемся - в "InDeKont". Главной социальной сети всего Großland'a.

Ещё никогда наша птаха - так не ошибалась!

#grosstech #interviews

Некоторое время назад я перестал воспринимать собеседования и технические интервью в КРУПНЫХ компаниях как что-то существенное. Давайте разберем замечательную задачу про "кэш" которая встречается на каждом втором техническом скрининге.

Суть задачи бывает разной, но обычно, нам нужно написать кэш компонент. И если решать эту задачу правильно, те 10–20 минут, что на нее будет выделено. Не позволит её решить. Вот пример (https://habr.com/ru/companies/avito/articles/943336/) попытки — как команда независимых разработчиков, чтобы это не значило, пыталась решить её 9 месяцев.

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

type Cache[T] struct {
    data map[string]T
}

func (c *Cache) Get(key string) (T, bool)  {
   v, ok := c.data[key]
   return v, ok
}

func (c *Cache) Set(key string, v T) {
    c.data[key] = v 
}

Тут с многозначительным выражением лица надо вперёд коварного интервьюера сказать — "но такой кэш будет приводить" к суровой проблеме — гонке данных при попытке записи!

type Cache[T] struct {
    data map[string]T
    lock *sync.RWMutex
}

И всё! Вы - победитель соревнования умственно отсталых — способность добавить сюда RWMutex демонстрирует то, что вы прекрасно разбираетесь... В чём? В том, что надо рассказать, что при взятии мьютекса обязательно надо сделать — defer!

unc (c *Cache) Get(key string) (T, bool)  {
    c.lock.RLock()
    defer c.lock.RUnlock()
...

func (c *Cache) Set(key string, v T) {
    c.lock.Lock()
    defer c.lock.Unlock()
...

На этом вся задача в целом обычно заканчивается и появляются "ЗВЕЗДОЧКИ". Например, сбрасывать кэш по расписанию (запустить гороутину и по таймеру в цикле создавать новый мап и заменять им тот, что внутри не забыв про select с остановкой, как во вчерашнем примере).

А теперь в чем беда. В том, что потом в продкашене на сотни тысяч или даже десятки миллионов ключей эта реализация "кэша"с умным видом лежит в продуктовом коде. Или. Что ещё кошмарнее — в платформенном. Причём при наличии в платформе — запрещено бывает использовать, что-то кроме этого убожества. А в статье, что я привёл в начале, рассмотрено существенно больше проблем.

Потом у нас на тысячах РПС вся система упирается в единственный мьютекс такого кэша и получается бутылочное очко для трафика. Причем о том, как преодолеть эту проблему спрашивают в 2-5% интервью в большие компании. Даже при собеседовании на вакансии стафф/техлида. Ну потому что… Зачем?

Но и это не всё! Есть инварианты кэшей, когда например у нас нет записи. Только чтение. И в такой реализации - не нужен мьютекс никакой. Т.к. крутящаяся в расписании функция обновления кэша заменяет его целиком:

func (c *Cache) loop(ctx context.Context, updater func() map[string]T, error) {
     for {
    select {
    case <-srv.ctx.Done():
      return
    case <-srv.ticker.C:
      result, err := updater()

      srv.ticker.Reset(srv.cfg.TTL)

      if err != nil {
          continue
      }
      
      c.data = result
    }
  }
}

Но что особенно иронично. В подавляющем количество реализаций такого кэша с обновлением по расписанию — будет висеть мьютекс. Он будет просто тратить процессорное время там, где гонки НИКОГДА НЕ СЛУЧАТСЯ. А нужен он там, потому что карго культ с интервью или выветривается (и люди просто пишут код с гонками данных, т.к. никогда и не умели писать конкурентный код) или просто не способны думать своей головой.

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

#interviews #stupidcache

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

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

Однако жизнь такова, что некоторые вещи и запросы требуют быстрого и близкого к моментальному времени ответа. Что делать
в таком случае? Ну представьте себе, такую задачу, вы хотите определить пользователя, который произвел платежей в системе
на 10000$ и перевести его на новый тарифный план и сообщить об этом письмо. Причем платежи мультивалютные и поставщик
валюты шлёт вам поток данных по изменениям курсов валют.

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

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

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

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

https://www.piter.com/collection/all/product/potokovye-bazy-dannyh

#bookshelf

Каждый день и в каждом утюге идёт рассуждение о AI. О том как он всех заменит, о будущем и о том как в это будущее попадёт только некоторая элита. Однако для того, чтобы понять всё это нужно сделать очень большой шаг в прошлое и затаить дыхание стоя на той самой скале возле реки Großflüss, где первый Großmensch рисовал первую программу, иллюстрирующую прыжок стада антилоп в обрыв.

Gemini в поисковой выдаче гугла утверждает, что "около 80-85 процентов населения мира относят себя к верующим или
религиозным людям. Если вдуматься, то подавляющее большинство людей верят в то, что горящий куст определил
какой народ будет избранным. И так уже ориентировочно на протяжении около 4 тысяч лет. Когда горящий куст заговорил
второй раз, образовался арабский халифат.

Ну и простая экстраполяция говорит нам очень важную вещь — теперь эти 85 процентов людей на планете подвержены общению с действительно говорящим горящим кустом.

Мышление человека, в целом крайне ритуализованно. Давайте посмотрим примеры из нашей профессии.

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

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

Всё это важно, т.к. наш комфорт определяет в целом порядок и структурированность мира вокруг. Поэтому мы создаем ритуал.Религиозные практики, медитации. Вместо создания реальных ценностей, в критической ситуации. Человечество
более 5 тысяч лет молилось высшим силам, которые должны решить свои проблемы. А AI создает ощущение, что бог теперь
еще и отвечает и решает эти самые проблемы.

Иронично то, что количество параметров у GPT5 от 3 до 5 триллионов. В сравнении у человека число синапсов в мозгу от
100 до 600 триллионов. Вы бы доверили свои жизни и будущее цивилизации своему 95 летнему деду, Альцгеймер которого не позволяет ему вас узнавать и отличить унитаз, от вашей чашки для кофе?

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

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

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

Для тех, кто сомневается. Разница между квалифицированным инженером и всеми остальными составляет ровно порядок. Даже когда те используют AI. Для того чтобы AI приносил пользу вместо хотя бы джунов. Нужно, чтобы инженер писал LLD
документы и верифицировал результат. Совершенно не важно, будешь ли ты писать инструкции для компилятора или
для транслятора (в виде claude). Кроме одного факта — разница просто увеличится. Между квалифицированным и "разработчиком" из бигтеха.

#ai #future

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

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

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

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

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

#teambuilding