🎶 Немного музыки для работы

Дебютный альбом моего брата в жанре Lounge
Несмотря на название - мне заходит и во время кодинга 🙂

Хочется услышать в комментах отзывы опытных меломанов — что хорошо, что плохо?

Сссылки на альбом ⬇️

https://music.yandex.ru/album/26340373
https://open.spotify.com/album/1CMDH6BXJtXEYEZv7esex7
https://music.apple.com/us/album/aftercoding/1693373990

Про Вадика на память
https://youtu.be/FHW0bXcQ4Is

1. Подарок 🎁 к рождеству

2. Про канал и интенисв

https://youtu.be/2Mg0oz3DDr4?si=FjSf7jaJY_XNlh5r

Первый урок нашего легендарного интенсива.
Интересно, что в самых первых потоках его не было.

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

Пришлось как обычно за 18 минут вспомнить всё 🤓️️️️️️

https://youtu.be/PslExWYTD8U?si=cPDeyAcF2bLAJHV7tuj

Коротышечка 1


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


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


Глупые компании "делают ставку на ИИ" и сокращают штат. Умные знают где их бизнесу ИИ помогает, а где нет и пользуясь случаем отбирают с рынка по дешевке лучших программистов.


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


Когда пузырь лопнет, глупые компании останутся с простреленными ногами. Незавидна судьба многих из них.


А умные останутся с лучшими командами и уменьшенной конкуренцией.

Разминка для ума 🧠
Пример вопроса на собес уровня senior/staff+ по мотивам реальной рабочей проблемы.

Вы тех лид сервиса типа google analytics.

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

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

К счастью у вас есть архив событий (с информацией о юзере - user agent, cookie, ip и о визите - timestamp, url, и т.д.) в виде zip файлов на S3.

Каждый файл несколько десятков гигабайт событий за ровно 1 час какого-то дня (час и день в пути файла видны).
Внутри этого файла события не отсортированы. Для простоты положим у вас есть либа для последовательного чтения строк из этого файла без загрузки всего файла в память или копирования целиком из S3.

Предложите схему решения проблемы и ее trade-offs.

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

2. Полезно потом погуглить и составить более детальную картину (или полностью поменять свой изначальный проект).

💬 Доп вопросы и свои идеи пишите в комментах

🧐 Коротышечка 2

В реальных проектах и реальных компаниях (от нескольких десятков разработчиков) время и ресурсы потраченные на написание и исправление непосредственно кода это от силы 20-30% времени разработчика (в крупных компаниях даже 10% можно считать удачей).

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

Значит в самом идеальном раскладе прирост общей скорости серьезного проекта не значительный, а компромиссы в качестве — это новый риск, плохо предсказуемый.

Речь идет о серьезных проектах, когда разрабатывается что-то в какой-то степени новое, не типовое.

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

Личное наблюдение
с LLM агентами моя продуктивность написания кода на Java с учетом всех переделок, тяни-толкаев и прочего в среднем почти сравнялась с моей же скоростью работы на Typescript (которая в свою очередь немного отстает от скорости работы на Ruby)

Мораль
Морали нет, в работе все средства хороши, которые помогают.
А еще Java - говно мамонта 🦣, без которого в 2026м в 99% случаев можно было бы прекрасно обойтись.
Только заядлым джавистам не говорите 🤫 им тоже надо семью кормить.

🧐 Коротышечка 3

ЛЛМки изменяют работу программистов но не совсем так как шароголовые эффективные мэнеджеры думают.
ЛЛМка не думает как программист, не принимает решения как программист, она не способна заменить программиста, ни опытного ни начинающего.
Также она не способна сама по себе волшебно ускорить или облегчить работу программиста (про это предыдущая коротышечка ☝️).
И волшебным образом превратить рядового менеджера в инженера она тоже не способна.

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

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

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

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

Может не значит будет. Инструмент-усилитель усиливает и плохие и хорошие решения. Цена ошибки будет возрастать, а растущие масштабы проектов будут создавать отрицательную обратную связь (чем больше выработка программистов - тем сложнее и крупнее проект - чем крупнее и сложнее проект - тем сложнее его двигать с ЛЛМ или без).

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

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

😎 Коротышечка 4


Знания можно условно разделить на декларативные и процедурные.

ЛЛМки by design заточены на декларативные и коммуникацию. Процедурные они лишь имитируют.

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

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

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

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

😎 Коротышечка 5

Повод для поста - новый тренд ждать когда ИИ заменит менеджеров.

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

Несколько суровых истин из моего наблюдения за реальностью:

1. В хайтек компаниях всегда менеджмент самая важная и одновременно почти всегда самая плохо организованная функция.

В каждой компании я встречаю по несколько сильных программистов и 1-2 вау. А менеджеров, которых хочется приводить в пример и у кого хочется учиться я за всю карьеру встретил примерно 5.

2. Инженеры и их крутые навыки играют критичную роль только в 0.01% по-настоящему инновационных проектов (R&D), для всех остальных - с большим запасом достаточно тех, кого можно нанять на рынке (если не факапить функцию хайринга).

3. Ключевая роль менеджеров в 99.9% компаний (включая почти все текущие проекты фаанга, например) - правильно собрать машину бизнеса из ролей и людей (инженеров, маркетологов, продажников и тп) и поддерживать ее в здоровом состоянии.

Так же как программист в тех же 99.9% компаний собирает систему из известных решений, фреймворков, библиотек, алгоритмов, сервисов.

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

5. …но текущая система в хайтеке сложившаяся еще 20 лет назад (когда создавались те 0.01% технологий) и по инерции исповедуемая ее авторами (фаанг) помогает менеджерам замести сложность под ковер, раскидать свои ключевые функции на других людей (чего стоит только стандартная практика performance review, где ты сам себе придумываешь цели а потом сам себя по ним оцениваешь + мнения о тебе коллег) и достаточно долго выживать в роли примитивного передатчика информации, съезжая на базаре и получая звездочки на погоны по принципу ходжи насреддина: или шах сдохнет (команда виновата, все провалила, несмотря на мои героические усилия) или ишак (я молодец, я привел команду к успеху).

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

Однако это не решение проблемы. Проблема в построении системы менеджмента аналогично другим индустриям но с учетом нашей специфики.

Только такие команды будут конкурентоспособны и смогут отъесть рынок у неповоротливых монстров.