Раз воркшоп на конференции у нас превратился в live-coding-show, мы решили делать воркшопы онлайн. И не один раз, а много, регулярно и серийно. О принципах, на которых мы будем строить эти воркшопы, я напишу отдельный пост. А пока что хочу сказать, что первый воркшоп я провожу сегодня, через 2.5 часа, и за последние сутки его содержимое поменялось больше чем наполовину. Про то, почему так и какие выводы я из этого сделал, тоже напишу. А пока что пожелайте мне удачи. :)

---

Если что, всё прошло нормально, я жив, напишу ещё про опыт.

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

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

Я только что вышел с репетиции доклада. Настроение примерно как на картинке: выступать всё еще сложно и страшно — и неизвестно, будет ли когда-то легко — но я сделаю лучшее, что смогу. А еще мне помогают коллеги, и каждый тоже делает лучшее, что может. Победа неизбежна и неотвратима. :)

Есть хорошая топология документации: tutorials, guides, explanations, reference. Я писал про нее три года назад и с тех пор активно использую в работе. Всё это время я видел в ней только логику пользовательского пути:

1. Разработчик пишет hello world, чтобы попробовать и заинтересоваться.
2. Проходит несколько гайдов, чтобы опробовать технологию в деле или разобраться, как решать конкретную задачу.
3. Потом читает объяснительные статьи и разбирается в тонкостях технологии. Это путь к профессиональному владению инструментами.
4. Наконец, после пары лет уверенного пользования инструментом, разработчик только заглядывает в референс, когда не помнит деталей API.

Теперь, поработав полгода в стартапе, я выработал совершенно новое понимание логики: с точки зрения бизнеса, который строит свой продукт на основе нашей технологии:

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

2. Гайды по решению конкретных задач нужны для того, чтобы ускорить разработку до состояния прототипа, proof of concept. На основании этого прототипа бизнес будет решать, вкладывать ли дальше ресурсы в разработку решения на вашей технологии, или выбрать что-то другое. А еще набор типичных решаемых задач помогает предпринимателям находить такие задачи в окружающем мире и решать их именно с помощью вашей технологии.

3. Статьи про то, как делать правильно, нужны на этапе разработки приложения после одобренного прототипа. Там будут появляться первые большие проблемы: производительность, надежность, безопасность, масштабируемость решения. Для того, чтобы эти проблемы решить, разработчикам понадобятся объяснительные статьи. До этого этапа они не нужны — рано еще решать проблемы, надо выжить. Результат этого этапа — MVP, первая версия продукта, у которой есть пользователи и которая решает их задачу. Но и дальше такие статьи не теряют своей ценности.

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

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

Желаю вашим продуктам дожить до этого прекрасного времени. :)

Нет времени объяснять, запрыгивайте в трансляцию :)
https://www.youtube.com/watch?v=NBdZmyNGdcQ

Когда-то я купил микрофон и радовался ему. Заодно обещал курс и митапы. С тех пор я сменил работу и пару стран, курса всё ещё нет, зато митапы я на работе теперь делаю. И вот новый микрофон приехал.

Вообще, я подкаст хочу давно уже. Есть куча тем, которые мне интересны, и много людей, с которыми я бы поговорил вообще про что угодно, настолько эти люди классные. Да-да, читатель, я про тебя в том числе.

О чем бы вы послушали? О чем бы пришли поговорить со мной?

Хорошая новость в том, что такое можно репортить в @NoToScam. Плохая новость в том, что репорты никто не читает, похоже. Мой прошлый репорт так и висит с 2020 года.

Тем временем, поддельную учетку переименовали и я закиберсквоттил имя себе.

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

Зарегался в Вастрик-клубе, занёс долор, написал интро. Если вы тоже там, давайте дружить и общаться.

https://vas3k.club/user/nickvolynkin/

Пока нормальные посты не пишутся, поделюсь смешным видео. Человек читает мануал neovim с начала до конца, девять с половиной часов.

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

https://www.youtube.com/watch?v=rT-fbLFOCy0

Goodhart's Law (xkcd)

[later] I'm pleased to report we're now identifying and replacing hundreds of outdated metrics per hour.

(сохраните на случай переговоров про метрики со своим менеджером)

Doom на дашборде Grafana! Гениальный devrel-проект. Снимаю шляпу, восхищаюсь, хочу куда-нибудь украсть эту идею.

Ну и если где-то я увижу «в графане нельзя сделать Х», буду в ответ кидать эту ссылочку.

https://play.grafana.org/d/ePolu9Lnk/doom-half-resolution?orgId=1

Мой любимый браузер в очередной раз обновился и показал мне картинку про то, что поменялось. Было быстро, а стало быыыыстрееееее.

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

Ладно бы только длина полоски противоречила идее сообщения. Они еще и слово удлиннили, и полоску закрасили красным. Красная полоска в метриках это что? Это всегда что-то плохое.

Так досадно, хоть письмо пиши.

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

Старый мем переродился

Как я выгорел

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

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

Друзья мои, не будьте как я, трудоголиками. Берегите себя, заботьтесь о себе. Работа подождёт.

Ну а я ищу новую работу. Хочу и могу работать менеджером продукта или девадвокатом/техписателем в каком-нибудь продукте для разработчиков. Но если это просто хороший продукт — тоже интересно. Кипр или любая страна мира, откуда можно платить кипрской компании. Если у вас есть что-то такое — напишите мне на @nick_volynkin.

Чему я научился в этом году

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

1. Курс Вани Замесина про управление продуктом и AJTBD. Брал трек с практикой, успел применить к рабочим задачам, и многие уже известные мне вещи переосмыслил. TODO: рассказать вам новое про Diataxis, свой курс и книгу.

2. Курс Владимира Иванова про system design. Участвовал в самом первом потоке, послушал лекции, но не хватило сил сделать домашку — большой проект с фидбеком на каждой итерации. Все равно курс отличный. Думаю о том чтобы еще раз его пройти ради домашки и фидбека.

3. Еще один курс Замесина, про ответственность, умело замаскированный под названием «Что делать, когда жопа». Об этом писать отзыв будет сложнее всего, потому что ответственность это не только приятно и радостно, но еще и тяжело и больно. Хотя Ваня как раз утверждает, что больно — это необязательная часть.

4. И вот-вот начнется еще один, от Стратоплана про софт-скиллы. Здесь будет эксперимент: я не буду ждать полгода, чтобы подвести итоги, а наоборот, начну с ожиданий и логики выбора. А через полгода можно будет оглянуться на этот текст и сравнить ожидание и результат. (Посты: 1, )

Итак, начнем со Стратоплана и софт-скиллов.

Чему я научился: софт-скиллы, пост 1/N.

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

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

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

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

Посмотрим, что получится. Следующий пост будет после первого модуля.

Собственно, курс: https://stratoplan-school.com/engineer/