Ну что, айда в Threads?

https://www.threads.net/@ogrmv

Думаю, может попробовать там контент на английском публиковать полезный 🤔

А помните, был такой Clubhouse?

Ужасы отладки

Делаю приложение, которое запускается через pm2. Это такой модный-молодёжный сервис-супервизор, написанный фронтендерами, который следит за приложениями, перезапускает, если надо и т.п.

Все секреты в приложение попадают, как обычно, через env-переменные. Их там уже было N штук, и всё работало.

Процесс такой:
1. Новый код попадает на VPS
2. Собирается
3. Запускается скрипт prod-run-app-migrations.sh
4. Внутри читаются из амазоновского хранилища и экспортируются env-переменные
5. Запускается pm2 ./build/server/app.js
6. app.js проверяет, все ли переменные на месте, ругается и умирает, если нет

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

Крутил скрипты, крутил pm2, запускал руками, даже переменные переименовывал - то работает, то не работает.

Оказалось! 🤬

У pm2 есть флажок --update-env, который надо использовать, чтобы эта поделка подхватила новые переменные из окружения. ЧТО?! И после этого мне говорят, что все эти новые сиюящие утилитки классные, удобные! Вот проверенный годами supervisord таких проблем не имеет. По крайней мере, я не сталкивался.

В итоге час в трубу 🤬

Публично о неудачах

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

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

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

Образовательного проекта с моим другом Витей не будет

Сегодняшняя, а точнее уже месячной давности "плохая" новость в том, что мы с Витей разбежались. Проинтервьюировали 8 человек, много обсуждали и планировали, но так и не пришли к общему понимаю того, что же нам делать, для кого, зачем и почём. Витя хотел более камерный проект, больше для фана и коммьюнити. Мне же в большей степени хочется делать настоящий бизнес, который работает сам, растёт, может обеспечивать нас и будущую команду. Хотя меня пугала громадная конкуренция на рынке онлайн-образования.

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

Не рассориться, наконец, оставшись друзьями 🙂

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

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

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

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

Ещё мои представляения о бизнесе постепенно трансформируются.

Спросить меня полгода-год назад о том, нужны ли инвестиции - и мой ответ сходу был бы "нет". Дескать, если не понимаешь своих клиентов настолько хорошо, что можешь сам сделать первые 10-100 продаж руками, заработать, подтвердить гипотезу и принести пользу, то и нафиг такой бизнес (в качестве первого). Но есть же и более капиталоёмкие проекты, есть маркетинг, который, как показывает опыт, даже при наличии бьющего в цель продукта всё равно необходим и стоит денег. Жить на что-то надо, в конце концов, пока твой бизнес ещё не генерирует прибыль.

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

Совпадения и хорошие новости

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

Про восприятие расскажу отдельно, это прям супер-глубокая и важная для меня тема. А пока про совпадения.

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

Буквально в этот же день я натыкаюсь на классный проект. И сейчас занимаюсь им - с огромным удовольствием. Проектов на самом деле несколько: это утилиты для предпринимателей, основанные на ChatGPT и других публчиных API.

Кайфовый формат, в котором я работаю: один, как хочу, без какого-либо контроля и с полным доверием со стороны клиента. Фулстек, всё от инфраструктуры и devops до бэкенд-сервисов, фронта и UX, prompt engineering ещё. Не то чтобы я всё это одинаково люблю, но мне намного комфортнее делать всего по чуть-чуть, чем одни джейсоны гонять или формы полировать. Дизайн делает дизайнер клиента, но фундаментально на продукт я влияю, кажется, в большей степени.

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

Результат получается тоже супер: уже спустя 3 недели работы (из них 2/3 - это архитектура системы и простые деплои) и самый первый прототип тулзы, я сам с огромным удовольствием с ним балуюсь. Очень интересно выходит. И я всерьёз задумываюсь о том, как использовать LLM и прочие нейронки в бизнесе и собственных проектах. Огромный класс задач на классификацию, экстракцию любой информации из текста, саммаризацию (как по-русски будет?) покрывается с громадной точностью и почти бесплатно.

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

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

Немного английских развлечений вам в ленту :)

Код-ревью: убрать нельзя оставить 😱

Пока я дописываю следующий пост о совпадениях, хочу разбавить поток рефлексии более практичной и холиварной темой для своих читателей-разработчиков 😈


Мой знакомый Алекс написал о том, какие негативные последствия бывают от код-ревью. И хотя я сам обожаю катать в прод без каких-либо тестов и, уж тем более, код-ревью, я не согласен! 😇

Да, код-ревью может замедлять разработку. Например, в одной из прошлых команд мы даже замеряли и лечили излишне раздутый cycle time (сколько времени уходит на фичу от карточки в трекере до продакшена). Одним из результативных действий стало как раз изменение правил код-ревью: требуется меньше одобрений, мёржит тоже сам автор.

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

Так зачем вообще код-ревью? Если мы сами как будто бы стараемся дать командам разработки больше свободы и выжать побольше скорости.


☠️ Увеличить bus factor. Если кто-то из команды "попадёт под автобус", работа не должна остановиться. В коде часто бывает очень много легаси, особенно в стабильно работающих продуктах, которое знает только один бородатый синьор, а остальные боятся его трогать.

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


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

Получается даже обратное от "демотивированного и не развивающегося разработчика": в Фейсбуке я и представить не мог, чтобы на код-ревью мне не насыпали дельных предложений. А без хотя бы одного-двух одобрений боялся катить, чтобы что-то не поломать. Системы часто сильно зависимы друг от друга, несмотря на фича-флаги, хитрые фазированные деплои и подобные приседания.

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


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

Да, не за всё в ответе разработчики, их код и его качество. Но думаю, в случае с рентгеновским аппаратом - убийцей (гуглите Therac 25, он убил троих), можно было бы пожертвовать нервами и самооценкой разработчика в пользу хоть сотни раундов код-ревью! Правда не уверен, что в конце 80-х в принципе была такая практика. Agile точно не было.


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

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


Ну и, конечно, код-ревью нужно правильно готовить.

🔢 От общего к частному: начните с того, какую проблему решает код, а уже потом касайтесь деталей реализации. Докапываться до стиля не нужно, настройте линтеры и prettier-ы.

🙇‍♂️Обсуждайте код, а не автора. Критикуйте аккуратно и с уважением. Хорошее тоже подмечайте, особенно если вы выше по рангу (тим/тех-лид).

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

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

Как деплоить свои веб-проекты

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

🔥 Цель простая: быстро писать код и быстро отправлять его в прод. Желательно имея возможность легко откатиться на предыдущую версию (за вычетом миграций схемы данных).

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

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

🚫 Железный выделенный сервер в чьём-то датацентре: не рассматриваю, т.к. слишком дорого и не нужно под игрушечную нагрузку сайд-проектов

✅ Виртуальный сервер в облаке (VPS) от Digital Ocean, AWS, GCP, etc: нормальный вариант, требующий настройки, но достаточно недорогой, нагрузка может быть любой - толькло плати и настраивай горизонтальное масштабирование

⚠️ Платформа (Platfform as a Service): более удобный, но одновременно и более дорогой вариант, который легче настроить. Зависимость стоимости от нагрузки вроде тоже линейная, если не учитывать замороченные pricing схемы облачных провайдеров

🚫 Serverless: не рассматриваю, т.к. не фанат и не вижу практической ценности для своих проектов

Для своих проектов, как личных, так и клиентских, я использовал GCP как PaaS, AWS с ручной конфигурацией (поднять EC2, RDS, SQS, настроить Cloudfront), VPS, а также AppPlatform от DigitalOcean. Ещё баловался с Firebase (тоже PaaS от гугла), но на них забил.

Лично мне больше всего нравится DigitalOcean из-за простоты и доступности. Бот и сайт Стильного клуба работают на App Platform (PaaS), а мой сайт на выделенном droplet (VPS).

Также нужно настроить Cloudflare (в частности, для TLS termination), nginx как reverse proxy, хранилище файлов (S3-подобная штука, либо просто раздавать с диска через тот же nginx), postgres и redis. Последние я беру в managed-исполнении, то есть не заморачиваюсь с настройкой и просто плачу $15 за инстанс.

Единственное неудобство - собственно деплои. Пробовал я следующее:

⚠️ ansible на VPS: геморно в настройке, очень многословно, секреты хранятся в зашифрованном виде прямо в репозитории. От yaml тоже подташнивает

⚠️ github actions + рукописные скрипты для примитивных деплоев в стиле "big bang", секреты для сборки в гитхабе, секреты в продакшене из AWS Systems Manager

✅ деплои на App Platform через git push: работает практически из коробки, включая откаты релизов, но много ограничений, неэффективные пересборки и перезапуски. Секреты берутся из настроек на самой платформе

😍 докер-контейнеры под каждый сервис: собираем всё локально/в гитхабе - фронтенд, бэкенд, воркеры и т.п., кладём в DockerHub/любой container registry, на сервере делаем docker pull и docker compose up.

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

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

А вы как, куда и почём деплоитесь?

Ждём с нетерпением! 🤡

Не деплойся с краю 🐺

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

По просьбе CTO компании-клиента, который не любит питон, свой текущий проект делаю на node/ts + react/ts. Прикольно, конечно, типы шарятся туда-сюда, express мне тоже очень нравится - простой, быстрый, очевидный. Типизация в TS просто огонь в сравнении с этими class User(TypedDict) в питоне. Асинхронность более привычная, чем с asyncio. Короче, кайф, жить можно. Хотя питон тоже огонь с dataclasses, fast-api и прочими sqlalchemy.

В общем, полез я смотреть что там у deno сейчас происходит, а они уже конкурента vercel строят вовсю 🤯

Всю эту молодёжную серверлесс красоту я воспринимаю скептически (а NextJS вообще уродец жуткий и тормозной, как по мне). Но тут взгляд зацепился. Потому что идеи, стоящие за deno, мне нравятся.

- простая cистема зависимостей (в теории)
- лучшая совместимость с привычными API браузеров
- адекватная система ограничений
- typescript из коробки

Ну и всяко-разное ещё, выглядит многообещающе 😍 bun тоже прикольный, но в нём мне больше сам код на сишке zig нравится, а в deno функциональность.

Так вот, сначала взгляд зацепился за Deno KV (key-value что ли?). Это какая-то чудо-юдо serverless edge database as a function 🥴 Там всё на свете сразу: и распределённость c масштабированием, и (де-)сериализация прям в/из JS. Хоть товарищи и говорят, что подобных БД на рынке уже хватает, мне всё равно любопытно (как человеку, у которого железный сервер под столом стоит).

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

🔥 А идеальное решение для деплоев сайд-проектов такое: сохранить функцию (отправить код в продакшен) и не потратить на это силы, время и деньги. То есть код в проде есть, а настраивать ничего для этого не надо. И платить тоже (на игрушечных нагрузках сайд-проектов, конечно же).

Я хоть и сопротивляюсь serverless изо всех сил, и в работающий и приносящий деньги проект всё это наверное бы не потащил, такие штуки выглядит суперски для быстрой проверки идей и проектов, которые не жалко выкинуть.

Bloom filter

Ковырял мануалы по редису, наткнулся там на Bloom/Cuckoo filter и понял, что не помню, что это такое. Полез искать и наткнулся на две потрясающие визуализации:

- тык
- тыдык

Очень круто и наглядно сделано! 🔥

Вкратце: bloom filter - это set, который поддерживает 2 операции:
- достоверно определить, что элемента в множестве нет
- с некоторой вероятностью определить, что элемент в множестве есть

Реализуется на основе хэш-функции с хорошим распределением.

При добавлении любой элемент сначала превращается в N битов, и эти биты устанавливаются в 1.

Для проверки делаем то же самое, и если все биты взведены, то элемент вероятно в множестве. Если нет, его точно нет.

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

Enjoy!

☠️ Deno - живой труп?

Как вы помните, мне приспичило побаловаться с deno. Причиной послужило то, что тайпскрипт с нодой по-прежнему дружит достаточно плохо: нужно поставить ts-node для разработки, ускорить это через swc, в прод собирать через tsc или ts-patch, сверху пяток плагинов для тривиальных штук, подружить это всё через tsconfig... Короче, очередной вебпак и бабель.

Тогда я решил попробовать собрать нового телеграм-бота на deno и запушить всё это бесплатно в deno-облако.

Мои ожидания по поводу поддержки тайпскрипта, конечно же, оправдались. Всё летает, --watch работает быстро и как часы, не нужно никакой обвязки! Очень круто, что не надо ставить 100500 утилит вокруг: есть deno test, deno lint и fmt (и не такое придурашное, как prettier или airbnb-конфиг для eslint), deno repl и deno bench. Кайф 🔥

И можно даже забить на отсутствие официального образа в Dockerhub под apple silicon. Есть неофициальный, в котором даже watch работает как надо.

Почему же deno - труп?

Изначально deno задумывался как правильный node js. Они выкинули всё, включая стандартные и проверенные годами штуки вроде http, fs и подобных модулей, многие привычные API отправились туда же и были заменены браузерными (вот уж где я не совсем согласен, но идея понятна).

Поначалу запустить какой-нибудь express на deno было просто нельзя, by design. По всем любимой причине: "ты не должен этого хотеть" 🤣 Но что-то случилось, и спустя несколько лет появляется...

1️⃣ Обратная совместимость с нодой, а с недавних пор - и полная совместимость с npm-пакетами. На первый взгляд круто, да? И удобно! Но это первый симптом долгой и мучительной кончины. Следим за руками:

- В deno мы сделаем всё как надо...

- Никто не повёлся, без npm жизнь не мила. Выкатим обратную совместимость с npm...

- Стало лучше (наверное), но авторы oak, redis и прочих написанных под deno библиотек отправляются в пешее эротическое путешествие. Зачем нужны кривые и недописанные костыли, если есть проверенные годами koa, express, официальный node-redis, с хорошей поддержкой и покрытием тестами?

- Нода продолжает развиваться, а вместе с ней и популярный опенсорс. Появляются новые API, про deno никто из авторов не думает, а значит deno вынужден (будет) продолжать поддерживать node.

- И тогда deno... превращается в node с быстрой компиляцией typescript?

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

Но есть и вторая причина...

2️⃣ Венчурное финансирование и целевая аудитория! Команда подняла $21m год назад, чтобы сделать "javascript for serverless era" - и позволить хипстерам деплоить свои функции прямо на край, без занудной настройки серваков и инфраструктуры.

Но мы-то знаем, что, хотя для миниатюрных проектов serverless и может быть почти бесплатным, зарабатывают облака не на них. А на огромных клиентах вроде Netflix или Twitch, в которых есть свои инфраструктурные команды, оптимизирующие и издержки, и developer experience.

Весь serverless может оказаться просто оплачиваемой из бездонного кармана крупных облачных провайдеров попыткой раскрутиться за счёт почти бесплатных пользоватлей, чтобы, через неизбежную оптимизацию стоимости, затащить их на свои привычные VPS и Anything-as-a-Service решения. Человек в костюме медведя.

А вот у deno карманы не бездонные. А ещё есть конкуренция со стороны Netlify или Vercel, которые как раз для той же ЦА и понаделали Next.js и подобных штук. И, с их точки зрения, deno как среда разработки наверняка сильно проигрывает комбайнам, где всё уже как-то сделано за тебя.

🤔 Получается, что платформа deno наверняка умрёт без органического роста adoption и из-за совместимости с node, в то время как деньги подняли под serverless-штуки: deno deploy и deno kv. Мало того, что каждый из компонентов сложно сделать правильно и выдержать конкуренцию, они ещё и бьют в хотелки разных целевых аудиторий.

Я могу ошибаться, ведь serverless рынок растёт. Как думаете, чем закончит deno как технология и компания?

Красота-то какая! 😍

Отличная статья LLMs Practical Guide из замечательного рассказа Andrej Karpathy про то, как устроены и как использовать LLM.

А вы как относитесь к LLM? К ChatGPT и подобным.

Используете в работе?
Делаете приложения на их основе?
Думаете, они бесполезны, и всё это хайп?
Не знаете, что это такое вообще и зачем?

Поделитесь в комментах!

Вот как на самом деле работают продукты с суффиксом AI 😁

Не хочу превращаться в новостной канал, но 2 недели назад OpenAI подал заявку на патент на GPT-5 🫣

Мемчики на вашу мою любимую тему завезли 🤪

1. Идея важнее всего — делаем стартапы с умом ❤️

Переписывался с подписчиком, и он мне говорит: "понимаю, что у меня нет такой способности генерить идеи, как у тебя".

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


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

Понятно, что в большинстве случаев никаких чудес не происходит. Но как увлекательно носиться со своими идеями. Хоть в рамочку их, и на стену. Не трожь, моя идея, я первый придумал!

Идей у меня был миллион. Самый смешной случай был наверное лет 15-20 назад. Я придумал минималистичную CMS под названием Colibri (очень оригинально), и до того мне эта идея понравилась, что я написал на неё СПЕЦИФИКАЦИЮ. Неделю наверное писал.

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

Я тогда зачитывался книгами Брукса, ДеМарко и Листера, Спольски про лютый энтерпрайз и зачем-то тащил решения энтерпрайзных проблем в свои миниатюрные задумки. До сих пор ржу 🤣


✅ Плюсы этапа одержимости идеями

1. Это весёлый творческий этап, на котором можно поймать много кайфа и вдохновения

2. Идеи (изредка) могут быть хорошими

Хорошие идеи "из головы" появляются, на мой взгляд, только лишь как следствие большого опыта и прокаченной интуиции в той области, где вы создаёте. Ну, как у Баффета в финансах и бизнесе.

Но даже если идея потрясающая, её всё равно надо быстро проверять, чтобы увеличить шансы попасть в окно возможности. Зависать на этом этапе вредно!


👎 Минусы

1. Обычно "классные идеи", приходящие в голову без погружения в проблему, мало чем отличаются от галлюцинаций LLM. У меня так точно

2. Идеи имеют отрицательную стоимость, потому что реализация и продвижение стоят денег - а главное, времени

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

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

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

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

Ставьте ❤️, если ждёте следующие части. И рассказывайте про свои идеи!