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

Если еще не посмотрели - смотрим запись стрима

https://youtube.com/live/cSWOOVh7xkU

⚡️ Предварительная регистрация на интенсив:
Превращение существующего проекта в «local-first»

1. Обзор основных отличий подхода «local-first»
2. Практическое руководство: Как быстро создать PWA «local-first» из существующего приложения
3. Анализ кода: как добавлять новые сущности, операции, бизнес-логику

👉 Регистрация на мастер-класс по local-first https://forms.gle/ENXGB84bRY4fCiYZ8

Конкурс «Code with AI»

Призы: 2 места на один из моих курсов:
- Architecture 2025
- Async 2025 for JS/TS
- Patterns 2025 for JS/TS
- Node.js 2024
Задача: https://github.com/tshemsedinov/code-with-ai-contest

Программисты пугают, друг-друга, что их заменит AI, но почему такого не происходит в IT менеджменте? Ведь составлять наполеоновские планы и писать таски AI умеет лучше, они даже не должны запускаться, могут быть сколь угодно противоречивыми и туманными...

Кто там кричит «AI заменит программистов»? Тут в github тысячи issues есть в самых популярных репозиториях. Когда вы их собираетесь закрывать с помощью AI?

Node.js 1.7k, Next.js 2.3k, TypeScript 5k, React 811, Redis 2.2k, Angular 1.2k, Go 5k, Deno 2.3k, Rust 5k, Kubernetes 1.9k

Я вот делаю 1 раза в неделю лайвкод с парным программированием на AI: Cursor, Copilot, Claude code и т.д.
https://www.patreon.com/cw/tshemsedinov

AI научился говорить "ну шо там?" и теперь может делать 98% работы менеджмента

Все библиотеки Metarhia обновлены, ни одна из них не была заражена во время сентябрьских атак на NPM.

👉 https://github.com/metarhia/Docs

ℹ️ Официально: Metarhia не имеет ни малейшего отношения к этим атакам

Сегодня Деми Мурыч с Виталием Брагилевским

Виталий Николаевич Брагилевский:
В прошлом член двух комитетов языка Haskell
Более 20 лет опыта преподавания
Автор книжки haskell in depth
Участник десятка конференций
Волшебник из НИИЧаВо

Ну а Мурыча вы знаете

https://www.youtube.com/watch?v=iQ_PRQPBEgQ

Так выгладит окно, установленного в Chrome PWA из примера https://github.com/HowProgrammingWorks/PWA

Код не стоит ничего! Ценно владение кодом, а владение — это не авторские права, а возможность внести в код изменения в предсказуемые сроки.

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

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

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

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

Что задерживает разработку и как?
Куда уходит время, которое можно было бы потратить на новые фичи?

🐢 долгое согласование — вопросы или задачи сформулированы так, что люди подсознательно их игнорируют, уходят от ответа, не отвечают на сообщения, не приходят на созвоны; процесс принятия решений затягивается.
🔗 высокое зацепление — части программы слишком тесно связаны: много обращений к чужим свойствам и методам, из-за чего изменения в одном месте ломают другое, и модули невозможно исправлять независимо.
🤯 недооценка сложности — задача кажется простой, но в процессе реализации выясняется, что есть скрытые зависимости, то же зацепление, обновление зависимостей, исключения и дополнительные условия.
🔥 тушение пожара — вместо планомерной работы, новой функциональности, приходится срочно чинить критические баги или решать кризисные ситуации, у пользователей работа встала, теряем клиентов, разрушаются данные.
🧩 нет типовых решений — похожие задачи есть всегда, но для них не всегда подготовлены типовые решения, каждый раз разработчик выделяет решение из сторого кода, нет единого переиспользуемого подхода.
📦 плохая декомпозиция — код разделен на модули не по смыслу и не по зацеплению, а по непонятному признаку, слишком крупно или нелогично; "ось изменений" проходит по нескольким классам или модулям.
🙈 непонятный код — сложно читается, не подходящая гранулярность (слишком мелкие или крупные части); именование даже не намекает на что-то известное; оверинжиниринг: использованы лишние абстракции, паттерны, слои.
⚖️ противоречивые требования — разные руководители и представители заказчика присылают разные противоречивые требования или команды хотят разное, требования конфликтуют между собой или даже противоречивы внутри.
🛑 ручные процессы — отсутствие автоматизации: нет или мало тестов, ручной деплой, воспроизведение багов делаются вручную, не соблюдается semver и не отслеживаются версии зависимостей, вызывающих проблемы.
🌀 изменение приоритетов — задачи и цели постоянно «прыгают», фокус команды рассеивается, людей дергают на созвоны, на которых политика опять меняется и ничего не доводится до конца, ответственных не найти.
🚧 технический долг — старые и успешно замаскированные проблемы никуда не исчезли, костыли и временные решения, когда-то введённые для ускорения результата, замедляют развитие новых возможностей.
🔒 блокеры от внешних команд — выполнение задачи упирается во внешнюю зависимость и все всех ждут (например, API другой команды, решение смежного отдела, партнеров, безопасности), и прогресс стоит на месте.

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

Хрупкий код — это когда каждое изменение ломает что-то еще, а вы сидите в дебагере, а потом откатываете до рабочего коммита, иначе проект не собирается. Дебагер в проекте — это зло, его место — исследование рантайма, можно лучше понять инструмент ­— да, но в разработке, дебагер — это просто слив времени в никуда.

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