Eugene Kozlov

За время что веду твиттер накатал уже приличное количество технических тредов и постов. Для своего и вашего удобства соберу их в единый тред для закрепа😊 📷📷🔽🔽

"Предвосхитил тренды" или "не жили богато - нефиг начинать"😁

Я смущаюсь когда нужно рассказать про должность и чем занимаюсь на работе: - Утром тимлид - После обеда CTO. - Вечером курю пейперы как стафф - Аналитика. Переживаю, что выгляжу несерьезно. Думаю, пора что-то менять. А тут AI revolution и теперь это база. Ну и дела.

Author of Designing Data-Intensive Applications, Martin Kleppmann, on why scaling down is just as challenging as scaling up: “Part of what is interesting about modern cloud services, and backend services in general, is how they've introduced the idea of horizontal scalability and shared nothing systems. We can build systems that are able to cope with very high load, even if the individual components are just fairly cheap commodity machines. The scalability story is not just scaling up, but scaling down as well. How do you run a service in such a way that if it has a very small amount of load, it's really cheap to run? That's sort of the same question as ‘how do you continue running a service if it has a very high load?’ Generally, you want the cost and the computing capacity to be roughly proportional to the load that you have and at the low end, that means actually being able to scale down to something that is extremely cheap to run. That's not necessarily a given. It's something that is hard with on-premises software because if you've got a physical machine, that is a unit of deployment. Yes, you could carve it up into two dozen virtual machines, but it still requires some sort of resource allocation. And so, part of what's interesting about some serverless systems, is their ability to scale down and say ‘okay, if you're going to handle just three requests per day, that's just fine as well’”.

@hiro_oshi1 Откуда инфа про канико, кто вернет?)

@_abstractart Билдкит юзаю Есть еще билдах Канико вернут скоро

Коллеги DevOps, и просто инженеры. Я совершенно случайно узнал что проект kainko уже год как заархивирован на GitHub. Вопрос - и какой сейчас положняк для сборки образов на CI? github.com/GoogleContaine…

@np0kc Да, поглядел, хорошая штука, спасибо!

@_abstractart Podman ?

Если вы увидели оригинальный пост и подумали - "О чем вообще речь, нихрена непонятно" то вы не одиноки, я сам офигел, за 2 года некоторые вещи выветрились напрочь у меня самого. Бахнул Concurrency Mindmap для более комфортного погружения. Исходник добавлю ниже.

P.S. Имел в виду скорее - сборка образов без Docker как зависимости.

@ancientpunk Первый цикл был в принципе про Concurrency, про процессы, потоки, корутины итп) А вот второй уже как этот зоопарк контролировать) Без первого было непонятно как начинать второй. По настоящему скорость будем изучать вот сейчас)

@_abstractart Странно, что не наоборот. Сначала корректный, а потом уже как его сделать ещё и быстрым.

Выдержав паузу начал писать 3й цикл постов по Concurrency. Если в 1м был разбор за счет чего наш код быстрый, то 2й о том как писать корректный код. На скринах то что получилось🙂 Сейчас погружаюсь в lock-free, non-blocking, async и тому как выжимать из железа всё ⏬⏬⏬

Ссылка на цикл постов по Concurrency & Consistency t.me/careerunderhoo…

Ссылка на цикл постов по Concurrency Fundamentals t.me/careerunderhoo…

Недавно у меня случился спонтанный собес, который потревожил больную мозоль, и я решил наконец собрать мысли в текст, т.к. давно хотелось об этом поговорить. Все вроде как согласны, что важен инженерный подход, умение думать, декомпозировать задачи, разбираться в незнакомом. Это прям мантра на каждом митапе и в каждом посте на LinkedIn. И при этом, когда доходит до реального собеседования, тебя спрашивают конкретный фреймворк или конкретный инструмент. И если ты его не знаешь, ну или знаешь недостаточно глубоко, разговор как-то сам собой сворачивается. Я долго думал, что это просто лицемерие, что люди говорят одно, а делают другое, потому что им лень или потому что так проще. Но кажется, всё интереснее. Есть такая штука как affinity bias, это когда ты неосознанно отдаёшь предпочтение человеку, в котором узнаёшь что-то своё. Не обязательно внешность или бэкграунд, это может быть стек технологий. Когда кандидат говорит "я писал на Go с PostgreSQL", а у тебя в проде Go с PostgreSQL, у тебя в голове щёлкает что-то вроде "свой человек, понимает контекст, можно не объяснять базовые вещи". И это ощущение знакомости мозг интерпретирует как компетентность, хотя одно с другим вообще не связано. Исследование Diversity Australia показало, что affinity bias влияет на 78% решений о найме, и я подозреваю, что в IT это даже хуже, потому что технический стек, это такая штука, про которую легко думать, что она объективна. Типа, "я же не по внешности сужу, я по скиллам", но "скиллы" в этом контексте почему-то означают "знает то же, что и я", а не "умеет разобраться в новом". Есть ещё halo effect, это когда одна положительная черта распространяется на всё остальное. Кандидат работал в Google, значит он наверное и с архитектурой хорош, и в команде нормально работает. Или кандидат знает твой стек, значит он наверное и задачи декомпозирует нормально, и в проде не накосячит. Мозг дорисовывает картину из одного пикселя, причём делает это незаметно для тебя самого. И вот что получается. Harvard Business School провели исследование про skills-based hiring, это когда вместо требования диплома компания вроде как оценивает навыки напрямую. 85% компаний заявляют, что перешли на этот подход. А реально это затрагивает 0.14% наймов. Один из семисот. 45% компаний из выборки просто поменяли формулировки в вакансиях, но нанимают ровно тех же людей, что и раньше. Исследователи назвали эту категорию "In Name Only", что, кажется, довольно точно описывает ситуацию. Я это к чему. Мне кажется, с инженерным мышлением vs конкретными навыками происходит то же самое. Компании пишут в вакансиях "нам важен problem-solving и умение учиться", а на собеседовании проверяют, помнишь ли ты синтаксис конкретного языка или API конкретного фреймворка. И тут есть ещё одна хуйня, которая делает ситуацию практически безвыходной. Допустим, ты реально умеешь разбираться в новом, у тебя за плечами десять лет переключений между стеками и каждый раз ты выходил на рабочий уровень за пару недель. Как ты это покажешь на собеседовании? Собеседование длится час, может полтора. Все вопросы заточены под заготовленные ответы, ты либо знаешь как устроен event loop в Node.js, либо нет, и если нет, то никакое инженерное мышление тебе не поможет ответить на этот вопрос прямо сейчас, потому что оно работает на масштабе дней и недель, а не минут. Ты не можешь "разобраться в новом" за время собеса, потому что это процесс, а собеседование проверяет результат. И получается замкнутый круг: компании говорят, что ценят способность учиться, но формат проверки физически не позволяет её увидеть, зато прекрасно позволяет увидеть, что кандидат заранее вызубрил ответы на типовые вопросы по нужному стеку. И проблема в том, что человек, который проводит техническое интервью, физически не может отделить "этот кандидат хорошо думает" от "этот кандидат знает то же, что и я". Когда кандидат оперирует теми же инструментами и терминами, что и ты, мозг автоматически считывает это как "он понимает проблему", хотя, возможно, он просто заучил ответы на типовые вопросы по этому стеку. Karat в своём отчёте за 2026 год пишут, что 73% руководителей считают сильных инженеров стоящими минимум 3x от их компенсации. При этом AI размывает сигнал в традиционных интервью, т.к. кандидат может скормить задачу нейросети и получить рабочее решение, и отличить того, кто реально понимает, от того, кто хорошо гуглит (или промптит), становится всё сложнее. Живые интервью становятся ценнее, потому что на них можно наблюдать процесс мышления, а не результат. Но на живых интервью affinity bias работает ещё сильнее, потому что ты сидишь напротив человека и твой мозг активно ищет сигналы "свой/чужой". SHRM описывает этот механизм как "familiarity is experienced as competence recognition", и мне кажется, это самая точная формулировка проблемы, которую я видел. Знакомость ощущается как компетентность. Ты не принимаешь решение "выберу того, кто знает мой стек", ты принимаешь решение "выберу того, кто кажется более компетентным", просто компетентным кажется тот, кто знает твой стек. И structured interviews вроде как снижают этот bias на 40%, но я хз, сколько компаний реально проводят structured interviews для технических позиций, по ощущениям, большинство до сих пор работает в режиме "ну, поговорим, посмотрим". Чёт я пока это писал, подумал, что сам, наверное, делаю то же самое, когда оцениваю чужой код или чьё-то резюме. Видишь знакомый стек и автоматически начинаешь относиться с большей симпатией, хотя умом понимаешь, что человек, который умеет думать, разберётся в любом стеке за пару недель. Возможно, осознание проблемы, это уже половина решения, но я не уверен.

@DAlekperov Но все равно спасибо за ваш комментарий, я действительно сфокусирован больше на проблеме "говнокод как блокер роста" а не "говнокод как триггер к гибели".

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

Ребята, которые считают что говнокод в Claude проблемой - видели ли вы компании разорвишиеся из-за кода? Я нет, но видел такое: - стартап шарашит код для захвата рынка. И он захватывает, и на заработанное переписывает. - бигтех, где код уже не основная проблема.

@DAlekperov Я к ней аппелирую потому что обычно люди аппелируют к говнокоду как абсолютному злу. Мой посыл - "it depends".

@duremarik А точно в этом дело? Из последнего что я знаю про ту же W11 это то что там наоборот встраивают кучу веб компонентов и AI и все работает хуже чем в W10 которая написана нативно (на говнокоде)

@_abstractart Я легко дам 2 примера : Oracle DB и Windows 11. Да, эти компании заработали сотни миллиардов. Но теперь эти продукты идут к закату. Причина именно говнокод.

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

@_abstractart Может, можно выпустить МВП и заняться сразу нормально кодом. Сидеть на говнокоде в долгосроке - опасная затея

@burntobe У стартапа может не быть бюджета и времени делать сразу идеально, моя мысль в этом.

@_abstractart Вы себя то слышите? Заработать чтобы потратить на переработку кода... Т.е. вместо того чтобы на старте нанять 1 спеца который с помощью агента будет писать не говнокод - такой опции не предусматривается конечно...