Каналы про тимлидов и про коммуникации.
Телеграм только что выкатил новую фичу: теперь папками из телеграма можно делиться. Я взял свои папки про тимлидство и про технические коммуникации (доки + управление знаниями + деврел), убрал из них 1-1 и закрытые чатики, и вот что получилось.

TeamLead: https://www.tg-me.com/addlist/l5DYX3mRhwtiYWU6

DocOps: https://www.tg-me.com/addlist/3GI1i-KgDPI3ODli

Если не работает — обновите приложение :)
Подборки полностью субъективны, я наверняка что-то хорошее пропустил, так что фидбек и предложения принимаю. Пишите комменты )

Купил новую бутылку для воды. Принес домой, радостно налил в неё воду из помпы, потом заметил что внутри лежит инструкция.

Инструкция колд-брю — идеальный напиток для человека, который пишет инструкции.

Developer Relations и как я к этому пришел.

Пора рассказать, что я теперь делаю. С февраля я работаю в =nil; Foundation, мы делаем инструменты для разработчиков. Про компанию расскажу отдельным постом, пока что про себя. Я тут занимаюсь developer relations. Сейчас объясню, что это за штука такая.

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

Теперь сделаем “unfold”, развернем одно из ограничений. Будем писать не только документацию, а еще статьи в блог, учебные задачки с подробным объяснением и разные другие текстовые форматы. Мы же умеем хорошо писать, зачем ограничиваться документацией, другие форматы тоже могут решать нашу задачу.

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

Потом оказывается, что иногда текст воспринимается плохо, надо рассказывать и показывать. Мы с вами тренируемся это делать, осваиваем всякие комбинированные форматы: выступления, воркшопы, курсы, live coding всякий, тренинги. Теперь наша с вами специальность — технические коммуникации, а инструментов у нас много и мы их подбираем под конкретную задачу и аудиторию.

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

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

>>> Вы находитесь здесь <<<

Всё это в индустрии называется developer relations и этим я занимаюсь. Нас в команде двое, прямо сейчас есть вакансии на еще двоих: technical writer и developer advocate. Я напишу пост про вакансии на этой неделе, но если вам уже интересно, пишите в личку @nick_volynkin прямо сейчас.

Вакансии в команду Developer Relations в nil.foundation

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

Ссылки на вакансии, там внутри есть почта:

— Technical writer
— Developer advocate

Подробнее про команду и мой подход к работе я писал в прошлом посте.
Нужно находиться за пределами РФ и РБ, в идеале — в Европе или Штатах. Релокация на Кипр «под ключ» или в другую страну по номад-визе.

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

Вот я соскучился по друзьям и предлагаю им созвониться или поиграть в настолки. Такие встречи поддерживают наши отношения. Но я же не пишу "my dudes, я хочу улучшить нашу дружбу, давайте сделаем ивент". Вместо этого я зову играть в террарию или настолки на выходных.

Или вот представьте, что вы зовёте на свидание девушку или парня, которые вам нравятся. Или вы уже 20 лет в браке, суть та же. Будет максимально кринжово сказать «давай сходим в ресторан, чтобы улучшить наши отношения». И будет очень так нормально сказать «хочу провести с тобой время и тебя порадовать».

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

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

И developer relations — это не предмет деятельности и не цель, а некоторая характеристика результата. Метрика. И определять профессию через метрику это в самом деле что-то странное.

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

Подборка каналов для тимлидов.

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

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

Держите, подписывайтесь. Там можно на всё сразу, а можно повыбирать. https://www.tg-me.com/addlist/mDWR2gD6UEhlOWRi

Технические коммуникации можно поделить примерно на три группы:
1. Что надо сделать и зачем.
2. Как именно мы это сделаем или уже сделали, как оно внутри работает, как это эксплуатировать.
3. Как этим пользоваться и зачем.

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

Через неделю, 19 июня, мы попробуем разобраться хотя бы в части этой истории. Александра Камзеева и Андрей Бураков позвали меня к себе в подкаст, чтобы обсудить техписателей и аналитиков: их роли, задачи и навыки. Что общего, в чем отличия, как те и другие могут друг другу помогать. Приходите послушать нас! И накидывайте вопросы заранее: здесь или в комментариях в @nextway_news.

(Да, надо сразу сказать, что я себя не считаю «гуру техписательства», но побуду в роли techwriter advocate. Раз у разработчиков есть авокадо, значит и у техписателей могут быть.)

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

Давайте писать такое же про всякие наши библиотеки, API, CLI, архитектуру, деплои, вот это всё.

Через 15 минут будем трындеть как будто про техписателей и аналитиков, но больше о том, как всё перепутано в ролях и профессиях, и как это починить. Присоединяйтесь: https://nextway.timepad.ru/event/2465836/.

Запись будет через пару дней, но прийти и задать вопрос в прямом эфире — бесценно.

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

Приходите слушать: https://youtu.be/cI5yxP276Eg

Oh yeah, me grug brained too, can relate.

https://grugbrain.dev/

KnowledgeConf возвращается.

Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf.
Мы уже принимаем заявки на доклады. Читайте подробности и подавайте заявки: https://cfp.knowledgeconf.ru/.

А прямо сегодня, через час (в 17 часов Мск), будет встреча с программным комитетом. Приходите, если хотите выступить с докладом. Особенно, если хотите, но сомневаетесь. Регистрация тут: https://conf.ontico.ru/event/join/open_kc2023.html.

Мы (=nil;) едем на большую конференцию и готовим воркшоп. На нем участники пройдут по всему процессу разработки с нашим тулчейном: скомпилируют код в специальное представление — circuit, отправят его на маркетплейс, потом закажут на этом маркетплейсе криптографический пруф вычислений на конкретных данных и получат результат. А еще там в начале надо будет качнуть с гитхаба сотню мегабайт репозитория и пару гигов докер-образа.

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

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

Как проведем, напишу еще один пост про то, что мы делали и как всё прошло.

Пора рассказать, что у нас получилось с воркшопом.

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

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

Последовательность действий разбили на шаги. Каждый шаг — длинная команда в консоли или пара команд. Всё это мы завернули в один скрипт, чтобы каждый шаг в первый раз выполнять одной командой, вроде run.sh compile. Это должно было застраховать участников от ошибок, когда они невнимательно переписали команду или что-то пропустили. А потом, когда в перый раз всё получилось, можно развернуть подробную инструкцию, где объясняется каждый параметр в длинной команде, и выполнить еще разок.

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

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

Чтобы не тратить время и интернет на подготовку окружения, мы сделали готовые виртуальные машины в AWS. На них сразу был клонирован репозиторий с кодом для воркшопа, установлен Docker, и скачана пара нужных образов. Так мы защитились от плохого интернета, неработающего докера и неподдерживаемых архитектур проца. У меня был готовый inventory, так что с помощью Ansible я мог быстро обновлять код и образы на машинках. И еще был плейбук для того чтобы раскидать по машинкам ключи, чтобы люди могли зайти по SSH. Соединение по SSH — штука нетребовательная и довольно живучая. Даже с плохим каналом можно зайти и работать. Рассчитывали на 15-30 участников, поэтому заранее подняли 30 машинок.

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

Подготовились в целом отлично. Не учли только один риск, и как раз он и случился. Как вы думаете, что это было?

Раз воркшоп на конференции у нас превратился в 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 менялся не слишком часто, только в лучшую сторону, и все эти изменения были задокументированы.

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

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