Это статья появилась за распитием пива с друзьями в Академгородке — стало понятно, что лучше её перенести в текстовый вид, дабы не повторять сто раз.
Существуют легенды на тему того, что единственный смысл конференции — это найти себе работу покруче за деньги текущего работодателя. Несмотря на внешнюю неэтичность, в этом хотя бы есть смысл. В реальности бывает куда хуже: люди приходят на конфу, и потом не знают, чем заняться, кроме как хавать булочки в переходе (особенно если они бесплатные). Давайте я расскажу, что делать, чтобы не тратить свои и чужие ресурсы зазря.
Основная проблема разработчика в том, что навыки, технологии, идеи — всё это постоянно устаревает. Когда-то на земле жили динозавры, а теперь их нет. Вы точно не хотите быть одним из этих динозавров. Для этого нужно сфокусироваться на обновлении собственных знаний — это важно и максимально приоритетно. Это настолько приоритетно, что вы готовы потратить на это свои и чужие бабло и время.
Человеческое мышление так устроено, что не терпит ничего ненужного. Выделение важного и неважного – одна из самых поразительных и крутых систем, позволяющих думать максимально эффективно.
В книге «Moonwalking with Einstein» рассказывалось о журналисте с феноменально хорошей памятью, которому никогда не нужно было ничего записывать на бумажки и диктофоны включая длинные интервью. Эта память досталась ему благодаря тому, что его мозг считал все события вокруг одинаково важными, и одинаково достойными запоминания. Эта же особенность полностью разрушила жизнь этого человека. Он всю жизнь пытался фокусироваться на всём сразу, и ни разу не достиг ничего конкретного.
Разработчики софта обычного не такие, как этот журналист. Нам постоянно хочется вполне конкретных очевидных вещей: интересней проекты (и обычно они в точности знают, что значит «интересней», больше возможности, выше должности, больше денег – и всё это как можно быстрее. Для этого необходим конкретный фокус на своих задачах, отбросив иллюзии и мораль (в смысле, корпоративный bullshit типа «в нашей компании работать большая честь»).
Самая центральная идея в том, что совершенно тот же фокус следует сохранять и при посещении любых информационных ивентов.
Дальше я попытаюсь показать, как можно обновлять свои знания, используя конференции (и другие организованные события) в качестве ключевого момента в этом непрерывном обновлении знаний и навыков.
Любое достаточно сложное, растянутое во времени действие, должно начинаться с плана. Отсутствие плана — тоже план, только плохой. Как видим, выбора у нас немного: либо план пишем мы, либо его пишут за нас. «Дума — не место для обсуждений».
Наметим несколько опорных пунктов:
Осознайте, зачем вам нужна конференция, определите смысл. Выделите на это хотя бы 2 минуты.
Как говорил один товарищ, «каждый приезжает за своим. Кто хочет поменять работу — за оффером, кто хочет разобраться в технологии — за советами, у кого беда на продакшене — за рекомендациями лучших собаководов».
Можно воспользоваться «помощью друга» или «подсказкой зала» — организаторы конференции в рекламных материалах уж точно расскажут, зачем она нужна. Что угодно, лишь бы вы купили билетик. Но я всячески советую осознать смысл самостоятельно, потому что его может не быть.
Девопсерам повезло, у нас с поиском смысла всё просто.
Например, есть люди, которые могут целыми неделями редактировать две строчки кода, добиваясь корректности какой-то сложной формулы, или починки суперсложного бага в legacy системе. Нас же постоянно преследует удав:
Если вас постоянно преследуют страшные монстры, с этим нужно что-то делать, верно?
Каждый второй хочет быть богом Докера, легко и просто вертя тысячами контейнеров, и ты горишь, и ты в аду.
К сожалению, просто наличия смысла недостаточно.
(Предупреждение: Эта часть будет большой, нет времени — можно смело пропускать)
Представьте, джава-разработчик начинает готовиться к следующему собеседованию. Как может выглядеть его чек-лист?
Как видим, к «чистому программированию», посвященному алгоритмам и железу, примешивается знатная порция всякого борща! Сколько положить хлеба? Может быть, еще два компота и четыре дня на Графану?
У руководителя разработки бывают точно такие же проблемы. Вместо бумажки, приклеенной к холодильнику, будут многотомники «архитектурных видений», заданий и описаний, которые нужно превратить во что-то более умопостигаемое.
Есть один отличный пример — который по дефолту, к сожалению, понятен только игрунам в современные онлайн игры. Хорошо известен термин «метагейм». Попробую объяснить в паре слов. У словно существуют core механики — собственно правила игры, и meta механики — те эффективные способы действия, которые игроки придумывают сами. Например, в футболе core механики – это собственно правила футбола, а meta — выбор оптимального состава команды, стратегий и тактик поведения на поле. В покере core — это правила покера (которых раз два и обчелся), а meta — это вся остальная игра, стратегия игрока, придержать фишки до последнего стола, не рисковать и играть тайтово, забирать блайнды на префлопе, итп.
Обычно у несбалансированных игр (например, у большинства современных moba) всегда есть «господствующая мета» — набор высоко эффективных способов игры, очень сильно зависящих от конкретных характеристик твоих персонажей, которые меняются с каждым новым обновлением. Мета, которая была популярна в прошлом году, совершенно не играет на сегодняшний день, несмотря на то что состав персонажей и их способности почти не изменились. Когда-то в Overwatch всегда играли 2-2-2, а теперь уже нет. Чтобы научиться играть в ту же игру, теми же персонажами, но с новой метой, на профессиональном уровне от игрока требуется вложить усилия, иногда — значительные. Это как если бы в футболе правила менялись каждое воскресенье.
С технологиями происходит примерно то же самое, что в moba — это сплошной метагейм поверх одних и тех же идей, а зачастую одних и тех же реализаций. У тебя есть куча технологий, связанных друг с другом в отношении «все со всеми», имеющие в меню комплексного обеда разные веса. Будучи сисадмином, твои core правила игры включают GNU/Linux и Monitoring. Джава-программисту в 2017 году точно встретятся на пути Spring и Hibernate. Хотя это будут уже совершенно не тот Linux и Spring, которые были в 2003 году (про systemd и Spring Cloud можно похоливарить в комментариях). Одни и те же идеи правильного мониторинга или организации коллекций кочуют из года в год, из технологии в технологию, всегда похожие – и всегда немножечко разные. Иногда они тебе нравятся, иногда ты с ними в чем-то несогласен — но ты знакомишься с ними, и идешь дальше.
Но адаптироваться ко всему этому весьма непросто. Пробовали подписаться на Гитхабе на все интересные проекты и следить за свежими коммитами? Это нереально. Ну разве что тебе вообще мало что интересно, либо ты упоролся и готов потратить на это всё рабочее и свободное время. То же касается мониторинга новостных сайтов, RSS-фидов и почтовых рассылок проектов, итп. Более того, для глубокого понимания метагейма недостаточно их просто читать – нужно анализировать и экспериментировать, пробовать варианты. Возможно, придется нанять нескольких архитекторов, которые будут делать это вместо тебя, и платить им за это конские зарплаты? Это была печальная часть.
Приятная часть в том, что синхронизироваться с метой можно и нужно достаточно редко. Скажем, раз в полгода.
И вот тут отлично подходят конференции. На них приезжают лучшие специалисты в своем направлении, которые специально за месяцы готовились к этому докладу, подобрали для тебя удобную форму подачи, любое блюдо будет съедено за час. Весь комплексный обед съедается за день. Меню обеда, треки конференции – составляют знатные гуру, знающие толк в вопросе. После этого у тебя есть всего полгода-год чтобы попытаться хотя бы как-то угнаться за метой. Полгода-год – потому что потом будет следующая конференция. Изящное, удобное решение. Конечно есть и минусы — придется тратить силы чтобы погрузиться в самолет и дотащить свою тушку до места, но имхо, в целом этот минус полностью покрывается плюсами.
Поэтому второй совет будет такой: воспринимайте конференцию/митап как набор задач, которые нужно выполнить в ближайшие полгода. Как своеобразный чеклист или дополнение к бэклогу. Все задачи – опциональные, но если не проработать достаточное количество тем, то можно серьезно влипнуть в будущем. Важно, что это не какие-то «готовые решения» ваших проблем (для этого есть StackOverflow), а именно список стратегических задач, трендов.
Как и в любом другом проекте, мы должны иметь вполне четкую временную структуру. Пока нет плана — ты тратишь время на фигню. Все, кто недостаточно богат, чтобы спокойно тратить время на ерунду, стоит озаботиться следующим:
Обычно концепт делится как минимум на следующее:
Очевидно, что «для себя» идея выглядит типа «послушать доклад X, лично пообщаться с Y, и нажраться на афтерпати».
Только не нужно сообщать это работодателю, потому что ему обычно не так интересно, что ты там знаешь, как то, что ты собираешься со всем этим делать в конкретном проекте. Ему можно сформулировать как-то более конкретно: «в проекте X собираюсь улучшить Y благодаря использованию A,B,C, которым посвящена конференция». Объяснение желательно придумать емкое и пафосное, сдобрив любимыми баззвордами руководителя.
Придумывать концепт для работодателя стоит всегда, вне зависимости от того — платит ли он за твои билеты или нет. Во-первых, в любом случае это реклама тебя лично (лохи и нищеброды на конфы не ездят – или по крайней мере, такова легенда). Во-вторых, даже если прямо сейчас работодатель не видит выгоды от подобных мероприятий, на твоем опыте он может эту выгоду увидеть, и в следующий раз всё будет совсем по-другому.
Тут всё обыденно:
Об этой ерунде нужно побеспокоиться вовремя, ибо:
Видел огромное количество людей, которые просохатили все полимеры просто потому, что решили оформить бумажки «завтра с утра». Начинай заполнять чертовы бумажки прямо сейчас.
Это — самый интересный пункт программы.
Обучение лучше всего работает следующим образом:
Холиварный пример:
Идея кристалльно ясна со школы, наверное.
Конфа или митап сильно походит на этот план постановки эксперимента. Только экспериментируем мы не над предметами неживой природы или программами, а над докладчиками и их докладами. На приличных конференциях обязательно присутствует дискуссионная зона, поэтому можно ставить тесты напрямую на докладчике.
Теперь, что происходит, когда мы приехали на конфу, не подготовившись? Отсутствует фундаментальные два первых пункта программы: мы не знакомы с обсуждаемыми вещами, и не имеем никаких идей, что же мы собираемся проверять. Epic Fail. Остается либо дивиться на непонятные вещи, о которых вещают со сцены, либо хавать булочки в переходе.
Чтобы не опростоволоситься, перед тем как куда-то ехать, и вообще соглашаться на конфу, надо изучить её программу и составить план подготовки.
Дальше я скопипастил из недавней статьи план конференции DevOops 2017:
Зацените как меняется восприятие этого списка сразу же, как вы понимаете, что это не просто список чего-то, что мужики будут толкать со сцены, а список вещей, с которыми лично тебе надо срочно заранее ознакомиться. Он начинает выглядеть гигантским.
Важно, что предварительная подготовка должна занимать какое-то достаточно небольшое время, например суммарно час в день. Иначе обычный ленивый разработчик (типа автора этой заметки) отмораживается и перестает готовиться. Простой способ – не нужно изучать вообще всё перечисленное, а только по одному слову из каждого пункта, это серьезно облегчит задачу.
Теперь классифицируем источники информации, по которым мы будем проводить предварительную подготовку.
Просто берете любую технологию, и начинаете её использовать.
Использовать где угодно:
Не нужно тратить огромное количество времени, достаточно сделать пару рабочих прототипов, чтобы зацепить основные идеи. Например, чтобы завести Ansible и что-нибудь им сделать — нужны считаные минуты, плюс это можно тут же применить на работе.
Способ хорош тем, что в отличие от всевозможных туториалов, он дает понимание о вещах, которые нужны лично тебе, а не доброму дяденьке, сочинявшему документацию на сайте.
Сейчас все мы проводим в социальных сетях просто непростительное количество времени. Достаточно открыть Хабр или Фейсбук, и залипнуть на целый день. Способ использовать прокрастинацию с пользой — начать читать технические блоги по нужным темам.
Чтобы обмануть свой мозг, чтобы он всё еще считал это отдыхом и прокрастинацией, а не новым типом работы, можно поставить какой-нибудь четкий будильник: например, читаем про Энсибл не более 30 минут, а потом снова за работу!
Сейчас я не буду мусорить здесь, описывая всю первую страницу гугла по запроу «Docker Blog», они там все интересные. Если у тебя, читатель, есть какие-то любимые блоги, напиши о них в комментариях!
Возможно теме систематизации devops блогов стоит посвятить отдельный пост. Нужно ли это Напишите в комментариях.
Хочется только отметить, что лучшие материалы — это те, которые промаркированы по времени. Чтобы было четко понятно, какие именно события, и в каком порядке, произошли за последний год. Сравнить «как было» и «как стало». Потом посмотреть «как стало» уже на конференции и сравнить
Как ни странно, в 2017 году, книги всё еще не изжили себя. В отличие от обрывочных твитов и постов в бложиках, они представляют собой конденсированную и многократно проверенную мудрость, особенно это касается учебников по фундаментальным технологиям.
Некоторые советы по использованию книг:
На ютубе есть огромное количество видео, которые помогут быстро настроиться на правильный лад, например DockerCon 2017. Особенно круты видеозаписи предыдущих конференций: можно посмотреть «что было» и «что стало», как менялось отношение спикеров по разным вопросам из года в год.
Хорошие рекомендации недавно были опубликованы вот в этой недавне статье на Хабре.
На этом можно бы и закончить, но всё же главное:
Отдельно по поводу записей. Если мысли тут же не записать, то под давлением мощного потока информации они быстро забываются. Диктофоны на подобных мероприятиях зачастую работают плохо из-за акустики залов и стремности диктофона (можно купить хороший диктофон). Лично для меня лучше всего работают mind maps на ноутбуке. Мне нравится платный Mindjet MindManager, но есть и куча бесплатных утилит (google: «best free mind mapping software 2017»). Если дополнить это слайдами доклада (докладчики обычно выкладывают их в интернете), получается очень хорошая база.
Внедрение чего угодно с конференции связано с несколькими сложностями.
Во-первых, материалы конференции не являются быстрофиксами для решения лично твоих проблем. Докладчики — не твои сотрудники. Просто так срисовать доклад и метнуться у себя что-то чинить — не получится. Поэтому можно относиться к полученной информации как к трендам, тенденциям, которые нужно учесть и проработать.
Чтобы было что прорабатывать, нужно иметь:
Дальше идет собственно проработка темы. Например, если мы на конференции впервые познакомились с Kubernetes, то не стоит бежать и внедрять его. Стоит всесторонне изучить тему и отнестись к этому максимально серьезно.
Во-вторых, обычно внедрение новшеств зависит не только от вас, а еще и от руководителей. Руководители зачастую относятся к конференциям, и информации, полученной с них, без особой радости. «Какая-то фигня для хипсторов». Изменить это отношение зачастую помогает просто нормальный диалог с описанием открывающихся перспектив.
Тут можно было бы написать мануал по проведению презентаций для руководства, но это тема отдельной статьи. Ограничусь основными мыслями.
Наиважнейшая штука в том, как именно подать внедрение новой технологии. Обычно мы, технари, просто задавливаем собеседника интеллектом. Но в случае если ты пытаешься убедить начальника провести тестирование какой-то совершенно новой штуки, того самого критического объема знаний может еще не быть. Тогда можно задавить собеседника здравым смыслом. Здравый смысл стоит начать с описания типа:
Еще раз подчеркну, что так как мы получили на конференции не конкретные быстрофиксы, а снимок трендов, перед тем как вступать в такой диалог, нужно основательно подготовиться.
Зачастую начальство привыкает к общению в виде просмотра слайдов. Можно считерить, и просто доработать слайды с конференции, благо на них есть публичная ссылка.
Но слайды для огромной конфы готовятся для просмотра с большого экрана.
Я обычно перерабатываю их следующим образом:
Это был короткий чеклист, о чем стоит подумать перед посещением конференции. Если ты
То конференция, возможно, прошла незря.
А если ты собираешься всё-таки, ни к чему не готовиться, и тупо жрать булки в коридоре в ожидании конца доклада, то можешь здорово сэкономить, поменяв конфу на посещение Бургеркинга.
Всем добра.
Существуют легенды на тему того, что единственный смысл конференции — это найти себе работу покруче за деньги текущего работодателя. Несмотря на внешнюю неэтичность, в этом хотя бы есть смысл. В реальности бывает куда хуже: люди приходят на конфу, и потом не знают, чем заняться, кроме как хавать булочки в переходе (особенно если они бесплатные). Давайте я расскажу, что делать, чтобы не тратить свои и чужие ресурсы зазря.
0. Целеполагание
Основная проблема разработчика в том, что навыки, технологии, идеи — всё это постоянно устаревает. Когда-то на земле жили динозавры, а теперь их нет. Вы точно не хотите быть одним из этих динозавров. Для этого нужно сфокусироваться на обновлении собственных знаний — это важно и максимально приоритетно. Это настолько приоритетно, что вы готовы потратить на это свои и чужие бабло и время.
Человеческое мышление так устроено, что не терпит ничего ненужного. Выделение важного и неважного – одна из самых поразительных и крутых систем, позволяющих думать максимально эффективно.
В книге «Moonwalking with Einstein» рассказывалось о журналисте с феноменально хорошей памятью, которому никогда не нужно было ничего записывать на бумажки и диктофоны включая длинные интервью. Эта память досталась ему благодаря тому, что его мозг считал все события вокруг одинаково важными, и одинаково достойными запоминания. Эта же особенность полностью разрушила жизнь этого человека. Он всю жизнь пытался фокусироваться на всём сразу, и ни разу не достиг ничего конкретного.
Разработчики софта обычного не такие, как этот журналист. Нам постоянно хочется вполне конкретных очевидных вещей: интересней проекты (и обычно они в точности знают, что значит «интересней», больше возможности, выше должности, больше денег – и всё это как можно быстрее. Для этого необходим конкретный фокус на своих задачах, отбросив иллюзии и мораль (в смысле, корпоративный bullshit типа «в нашей компании работать большая честь»).
Самая центральная идея в том, что совершенно тот же фокус следует сохранять и при посещении любых информационных ивентов.
Дальше я попытаюсь показать, как можно обновлять свои знания, используя конференции (и другие организованные события) в качестве ключевого момента в этом непрерывном обновлении знаний и навыков.
1. План
Любое достаточно сложное, растянутое во времени действие, должно начинаться с плана. Отсутствие плана — тоже план, только плохой. Как видим, выбора у нас немного: либо план пишем мы, либо его пишут за нас. «Дума — не место для обсуждений».
Наметим несколько опорных пунктов:
- Предположения
- Вехи
- Конкретные задачи
2. Предположения
2.1 Предположение: смысл существует
Осознайте, зачем вам нужна конференция, определите смысл. Выделите на это хотя бы 2 минуты.
Как говорил один товарищ, «каждый приезжает за своим. Кто хочет поменять работу — за оффером, кто хочет разобраться в технологии — за советами, у кого беда на продакшене — за рекомендациями лучших собаководов».
Можно воспользоваться «помощью друга» или «подсказкой зала» — организаторы конференции в рекламных материалах уж точно расскажут, зачем она нужна. Что угодно, лишь бы вы купили билетик. Но я всячески советую осознать смысл самостоятельно, потому что его может не быть.
Девопсерам повезло, у нас с поиском смысла всё просто.
Например, есть люди, которые могут целыми неделями редактировать две строчки кода, добиваясь корректности какой-то сложной формулы, или починки суперсложного бага в legacy системе. Нас же постоянно преследует удав:
Если вас постоянно преследуют страшные монстры, с этим нужно что-то делать, верно?
Каждый второй хочет быть богом Докера, легко и просто вертя тысячами контейнеров, и ты горишь, и ты в аду.
К сожалению, просто наличия смысла недостаточно.
2.2 Предположение: благородные сэры не варят кашу
(Предупреждение: Эта часть будет большой, нет времени — можно смело пропускать)
Представьте, джава-разработчик начинает готовиться к следующему собеседованию. Как может выглядеть его чек-лист?
- Java Core, Collections, Concurrency (14d)
- Spring, Spring MVC (7d)
- Hibernate, SQL (7d)
- JS (Angular, React) (7d)
- Testing, TDD (2d)
- Building (Maven, Nexus) (1d)
- VCS (Git, Mercurial) (2d)
- Jenkins (1d)
- GNU/Linux, Monitoring (2d)
Как видим, к «чистому программированию», посвященному алгоритмам и железу, примешивается знатная порция всякого борща! Сколько положить хлеба? Может быть, еще два компота и четыре дня на Графану?
У руководителя разработки бывают точно такие же проблемы. Вместо бумажки, приклеенной к холодильнику, будут многотомники «архитектурных видений», заданий и описаний, которые нужно превратить во что-то более умопостигаемое.
Есть один отличный пример — который по дефолту, к сожалению, понятен только игрунам в современные онлайн игры. Хорошо известен термин «метагейм». Попробую объяснить в паре слов. У словно существуют core механики — собственно правила игры, и meta механики — те эффективные способы действия, которые игроки придумывают сами. Например, в футболе core механики – это собственно правила футбола, а meta — выбор оптимального состава команды, стратегий и тактик поведения на поле. В покере core — это правила покера (которых раз два и обчелся), а meta — это вся остальная игра, стратегия игрока, придержать фишки до последнего стола, не рисковать и играть тайтово, забирать блайнды на префлопе, итп.
Обычно у несбалансированных игр (например, у большинства современных moba) всегда есть «господствующая мета» — набор высоко эффективных способов игры, очень сильно зависящих от конкретных характеристик твоих персонажей, которые меняются с каждым новым обновлением. Мета, которая была популярна в прошлом году, совершенно не играет на сегодняшний день, несмотря на то что состав персонажей и их способности почти не изменились. Когда-то в Overwatch всегда играли 2-2-2, а теперь уже нет. Чтобы научиться играть в ту же игру, теми же персонажами, но с новой метой, на профессиональном уровне от игрока требуется вложить усилия, иногда — значительные. Это как если бы в футболе правила менялись каждое воскресенье.
С технологиями происходит примерно то же самое, что в moba — это сплошной метагейм поверх одних и тех же идей, а зачастую одних и тех же реализаций. У тебя есть куча технологий, связанных друг с другом в отношении «все со всеми», имеющие в меню комплексного обеда разные веса. Будучи сисадмином, твои core правила игры включают GNU/Linux и Monitoring. Джава-программисту в 2017 году точно встретятся на пути Spring и Hibernate. Хотя это будут уже совершенно не тот Linux и Spring, которые были в 2003 году (про systemd и Spring Cloud можно похоливарить в комментариях). Одни и те же идеи правильного мониторинга или организации коллекций кочуют из года в год, из технологии в технологию, всегда похожие – и всегда немножечко разные. Иногда они тебе нравятся, иногда ты с ними в чем-то несогласен — но ты знакомишься с ними, и идешь дальше.
Но адаптироваться ко всему этому весьма непросто. Пробовали подписаться на Гитхабе на все интересные проекты и следить за свежими коммитами? Это нереально. Ну разве что тебе вообще мало что интересно, либо ты упоролся и готов потратить на это всё рабочее и свободное время. То же касается мониторинга новостных сайтов, RSS-фидов и почтовых рассылок проектов, итп. Более того, для глубокого понимания метагейма недостаточно их просто читать – нужно анализировать и экспериментировать, пробовать варианты. Возможно, придется нанять нескольких архитекторов, которые будут делать это вместо тебя, и платить им за это конские зарплаты? Это была печальная часть.
Приятная часть в том, что синхронизироваться с метой можно и нужно достаточно редко. Скажем, раз в полгода.
И вот тут отлично подходят конференции. На них приезжают лучшие специалисты в своем направлении, которые специально за месяцы готовились к этому докладу, подобрали для тебя удобную форму подачи, любое блюдо будет съедено за час. Весь комплексный обед съедается за день. Меню обеда, треки конференции – составляют знатные гуру, знающие толк в вопросе. После этого у тебя есть всего полгода-год чтобы попытаться хотя бы как-то угнаться за метой. Полгода-год – потому что потом будет следующая конференция. Изящное, удобное решение. Конечно есть и минусы — придется тратить силы чтобы погрузиться в самолет и дотащить свою тушку до места, но имхо, в целом этот минус полностью покрывается плюсами.
Поэтому второй совет будет такой: воспринимайте конференцию/митап как набор задач, которые нужно выполнить в ближайшие полгода. Как своеобразный чеклист или дополнение к бэклогу. Все задачи – опциональные, но если не проработать достаточное количество тем, то можно серьезно влипнуть в будущем. Важно, что это не какие-то «готовые решения» ваших проблем (для этого есть StackOverflow), а именно список стратегических задач, трендов.
3. Вехи
Как и в любом другом проекте, мы должны иметь вполне четкую временную структуру. Пока нет плана — ты тратишь время на фигню. Все, кто недостаточно богат, чтобы спокойно тратить время на ерунду, стоит озаботиться следующим:
- Определить концепт
- Обеспечить ресурсами (билеты, время, итп)
- Провести информационную подготовку
- Поучаствовать в конференции
- Внедрить изученное
- Перейти на следующую итерацию (через полгода-год)
4. Задачи
4.1 Определение концепта
Обычно концепт делится как минимум на следующее:
- Для себя
- Для работодателя
- Для друзей и прочего окружения
Очевидно, что «для себя» идея выглядит типа «послушать доклад X, лично пообщаться с Y, и нажраться на афтерпати».
Только не нужно сообщать это работодателю, потому что ему обычно не так интересно, что ты там знаешь, как то, что ты собираешься со всем этим делать в конкретном проекте. Ему можно сформулировать как-то более конкретно: «в проекте X собираюсь улучшить Y благодаря использованию A,B,C, которым посвящена конференция». Объяснение желательно придумать емкое и пафосное, сдобрив любимыми баззвордами руководителя.
Придумывать концепт для работодателя стоит всегда, вне зависимости от того — платит ли он за твои билеты или нет. Во-первых, в любом случае это реклама тебя лично (лохи и нищеброды на конфы не ездят – или по крайней мере, такова легенда). Во-вторых, даже если прямо сейчас работодатель не видит выгоды от подобных мероприятий, на твоем опыте он может эту выгоду увидеть, и в следующий раз всё будет совсем по-другому.
4.2 Обеспечение ресурсами
Тут всё обыденно:
- Если ехать на деньги компании
- Заявить руководству свое желание присутствовать
- По необходимости — придумать аргументацию для убеждения.
- Если ехать за свои деньги — купить билеты:
- Конференция
- Самолёт
- Гостиница/хостел
Об этой ерунде нужно побеспокоиться вовремя, ибо:
- Некоторые конференции дают бешеные скидки на предзаказы билетов.
- Гостиницы и самолёты, будучи заказанными заранее, могут стоить сильно дешевле.
- В некоторых компаниях нужно заявлять бюджет на год вперед. Или на месяц.
Если не заявить работодателю прямо сейчас — потом поезд ушел.
Также работодатели не любят внезапного желания выделить хорошую гостиницу. - Некоторые компании отпускают на конференцию, только если ты не собираешься увольняться ближайшие полгода. Если ты собираешься — надо продумать тайминг.
Видел огромное количество людей, которые просохатили все полимеры просто потому, что решили оформить бумажки «завтра с утра». Начинай заполнять чертовы бумажки прямо сейчас.
4.3 Информационная подготовка
Это — самый интересный пункт программы.
Обучение лучше всего работает следующим образом:
- Некоторое время интуитивно изучать X
- Придумать теорию относительно Х
- Сделать предположение, как X должно работать
- Поставить эксперимент и узнать, как Х работает на самом деле
- На основании разницы между предположением и реальностью скорректировать теорию
- Пойти на следующую итерацию улучшения теории
Холиварный пример:
- Некоторое время использовать Windows-сервер, создавая общее впечатление
- Теория в том, что Linux значительно лучше Windows как файлопомойка
- Предположение: сделав файлопомойку на Linux мы не получим тех проблем, что были в Windows
- Эксперимент: делаем файлопомоку на Linux и обнаруживаем, что в ряде случаев проблемы есть, а в ряде случаев – нету
- Корректировка: Linux лучше Windows как файлопомойка только в ряде случаев
- Следующая итерация: определение ситуаций, когда лучше, а когда хуже
Идея кристалльно ясна со школы, наверное.
Конфа или митап сильно походит на этот план постановки эксперимента. Только экспериментируем мы не над предметами неживой природы или программами, а над докладчиками и их докладами. На приличных конференциях обязательно присутствует дискуссионная зона, поэтому можно ставить тесты напрямую на докладчике.
Теперь, что происходит, когда мы приехали на конфу, не подготовившись? Отсутствует фундаментальные два первых пункта программы: мы не знакомы с обсуждаемыми вещами, и не имеем никаких идей, что же мы собираемся проверять. Epic Fail. Остается либо дивиться на непонятные вещи, о которых вещают со сцены, либо хавать булочки в переходе.
Чтобы не опростоволоситься, перед тем как куда-то ехать, и вообще соглашаться на конфу, надо изучить её программу и составить план подготовки.
Дальше я скопипастил из недавней статьи план конференции DevOops 2017:
- Контейнеры, Оркестрация (Docker, Kubernetes, Clusters, etc).
- Виртуализация, Облачные технологии (AWS, Azure, Heroku и другие).
- Мониторинг и аудит приложений (Prometeus, OkMeter, DataDog, BPF, Dynatrace, XRebel, Glimpse, Zipkin, OpenTrace и другие).
- Continuous Delivery (Jenkins, TeamCity, Bamboo).
- Configuration Management (puppet, chef, ansible).
- Безопасность (Vault, etc.)
- Разбор полетов на примерах крупных проектов, внедряющих DevOps: успешных и провальных.
Зацените как меняется восприятие этого списка сразу же, как вы понимаете, что это не просто список чего-то, что мужики будут толкать со сцены, а список вещей, с которыми лично тебе надо срочно заранее ознакомиться. Он начинает выглядеть гигантским.
Важно, что предварительная подготовка должна занимать какое-то достаточно небольшое время, например суммарно час в день. Иначе обычный ленивый разработчик (типа автора этой заметки) отмораживается и перестает готовиться. Простой способ – не нужно изучать вообще всё перечисленное, а только по одному слову из каждого пункта, это серьезно облегчит задачу.
Теперь классифицируем источники информации, по которым мы будем проводить предварительную подготовку.
4.3.1 Целенаправленное применение чего-то нового
Просто берете любую технологию, и начинаете её использовать.
Использовать где угодно:
- Соорудить небольшой тестовый проект
- Помочь коллеге или другу, который уже её использует на практике
- Использовать на работе, если это возможно
Не нужно тратить огромное количество времени, достаточно сделать пару рабочих прототипов, чтобы зацепить основные идеи. Например, чтобы завести Ansible и что-нибудь им сделать — нужны считаные минуты, плюс это можно тут же применить на работе.
Способ хорош тем, что в отличие от всевозможных туториалов, он дает понимание о вещах, которые нужны лично тебе, а не доброму дяденьке, сочинявшему документацию на сайте.
4.3.2 Блоги
Сейчас все мы проводим в социальных сетях просто непростительное количество времени. Достаточно открыть Хабр или Фейсбук, и залипнуть на целый день. Способ использовать прокрастинацию с пользой — начать читать технические блоги по нужным темам.
Чтобы обмануть свой мозг, чтобы он всё еще считал это отдыхом и прокрастинацией, а не новым типом работы, можно поставить какой-нибудь четкий будильник: например, читаем про Энсибл не более 30 минут, а потом снова за работу!
Сейчас я не буду мусорить здесь, описывая всю первую страницу гугла по запроу «Docker Blog», они там все интересные. Если у тебя, читатель, есть какие-то любимые блоги, напиши о них в комментариях!
Возможно теме систематизации devops блогов стоит посвятить отдельный пост. Нужно ли это Напишите в комментариях.
Хочется только отметить, что лучшие материалы — это те, которые промаркированы по времени. Чтобы было четко понятно, какие именно события, и в каком порядке, произошли за последний год. Сравнить «как было» и «как стало». Потом посмотреть «как стало» уже на конференции и сравнить
4.3.3 Книги
Как ни странно, в 2017 году, книги всё еще не изжили себя. В отличие от обрывочных твитов и постов в бложиках, они представляют собой конденсированную и многократно проверенную мудрость, особенно это касается учебников по фундаментальным технологиям.
Некоторые советы по использованию книг:
- Не читайте от корки до корки. Смотрите оглавление, и читайте только то, что интересно. Время для подготовки к конфе очень ограничено, если залипнуть в одну книгу длиной 1500 страниц, времени ни на что другое не останется.
- Не бойтесь, что текущая глава опирается на предыдущую настолько, что пропустив её, вы ничего не поймете. Обычно — поймете. Исключение составляют, например, книжки по алгоритмам и дискретке.
- Читайте книги по фундаментальным вещам. Для всего остального есть документация в интернете и StackOverflow.
- Если книга выглядит так, как будто автор просто перенес на бумагу документацию с официального сайта проекта — дальше можно не читать, в печь.
4.3.4 Видео
На ютубе есть огромное количество видео, которые помогут быстро настроиться на правильный лад, например DockerCon 2017. Особенно круты видеозаписи предыдущих конференций: можно посмотреть «что было» и «что стало», как менялось отношение спикеров по разным вопросам из года в год.
4.4 Участие в конференции
Хорошие рекомендации недавно были опубликованы вот в этой недавне статье на Хабре.
На этом можно бы и закончить, но всё же главное:
- Заранее определи, что собираешься слушать.
(Если нет ничего интересного, то на конфу можно не идти) - Если идете толпой от одной компании, можно разделиться по разным докладам.
Кто куда пойдет — тоже решить заранее - Взять с собой блокнот или смартфон, чтобы записывать интересные моменты и мысли.
- Обязательно поймать докладчика в дискуссионной зоне. Не бояться задавать странные и неудобные вопросы
- Продумать вопросы — где пожрать и поспать. Не пишу здесь, не маленький уже
Отдельно по поводу записей. Если мысли тут же не записать, то под давлением мощного потока информации они быстро забываются. Диктофоны на подобных мероприятиях зачастую работают плохо из-за акустики залов и стремности диктофона (можно купить хороший диктофон). Лично для меня лучше всего работают mind maps на ноутбуке. Мне нравится платный Mindjet MindManager, но есть и куча бесплатных утилит (google: «best free mind mapping software 2017»). Если дополнить это слайдами доклада (докладчики обычно выкладывают их в интернете), получается очень хорошая база.
4.5 Презентация и внедрение
Внедрение чего угодно с конференции связано с несколькими сложностями.
4.5.1 Quickfix vs trending topic
Во-первых, материалы конференции не являются быстрофиксами для решения лично твоих проблем. Докладчики — не твои сотрудники. Просто так срисовать доклад и метнуться у себя что-то чинить — не получится. Поэтому можно относиться к полученной информации как к трендам, тенденциям, которые нужно учесть и проработать.
Чтобы было что прорабатывать, нужно иметь:
- Память о том, что происходило на конференции
(как минимум, не следует во время и после конференции употреблять излишне много алкоголя, иначе точно всё забудешь) - Записи: блокнот, диктофон, майдмапы, итп
- Видеозаписи конференции (бывают не везде, и точно не сразу)
Дальше идет собственно проработка темы. Например, если мы на конференции впервые познакомились с Kubernetes, то не стоит бежать и внедрять его. Стоит всесторонне изучить тему и отнестись к этому максимально серьезно.
4.5.2 Презентация темы
Во-вторых, обычно внедрение новшеств зависит не только от вас, а еще и от руководителей. Руководители зачастую относятся к конференциям, и информации, полученной с них, без особой радости. «Какая-то фигня для хипсторов». Изменить это отношение зачастую помогает просто нормальный диалог с описанием открывающихся перспектив.
Тут можно было бы написать мануал по проведению презентаций для руководства, но это тема отдельной статьи. Ограничусь основными мыслями.
Наиважнейшая штука в том, как именно подать внедрение новой технологии. Обычно мы, технари, просто задавливаем собеседника интеллектом. Но в случае если ты пытаешься убедить начальника провести тестирование какой-то совершенно новой штуки, того самого критического объема знаний может еще не быть. Тогда можно задавить собеседника здравым смыслом. Здравый смысл стоит начать с описания типа:
- Проблема.
Нужно выдернуть какую-то реальную проблему из текущего проекта. - Решение.
Тут следует название полюбившейся тебе технологии с кратким комментарием.
Не нужно вываливать на человека всю глубину технической мысли, для начала нужно чтобы название технологии врезалось в память и засело там навечно. - Концептуальное описание пути к успеху.
Например, рассказываешь, что при наличии дополнительных двух человек и недели времени мы внедряем технологию, и получаем такой-то профит. Тут нужно сконцентрироваться на бизнес-аспектах: деньгах, времени, наборе платных решений, итп. Впрочем, грузить конкретными цифрами тоже не нужно, только намекнуть общий смысл. - Магия, благодаря которой всё это работает.
Вот тут можно развернуться в технических описаниях, впрочем, не перегибая палку. Как только заметишь, что у начальника погасает взгляд и интерес — необходимо тут же заткнуться и переходить к другим вопросам. - Конференция!
Упомянуть что вся эта магия стала доступна благодаря участию в конференции.
Это гарантирует тебе оплаченные билеты на следующие конференции :) - Как мы это представим заказчику.
Зачастую новая технология требует совершенно отдельного подхода к продаже её заказчику, если такой имеется. Это серьезный пункт, который надо прорабатывать отдельно. - Очень круто было бы объяснить, почему того, что ты сейчас будешь внедрять, убьёт на месте всех ваших конкурентов, если таковые имеются, и ты достаточно в этом понимаешь, чтобы не сморозить чушь.
- На последок, можно притащить информацию о текущем статусе проекта, и о конкретных метриках (например, увеличении числа запросов к веб-сервису), которые покажут успех внедрения технологии
Еще раз подчеркну, что так как мы получили на конференции не конкретные быстрофиксы, а снимок трендов, перед тем как вступать в такой диалог, нужно основательно подготовиться.
Зачастую начальство привыкает к общению в виде просмотра слайдов. Можно считерить, и просто доработать слайды с конференции, благо на них есть публичная ссылка.
Но слайды для огромной конфы готовятся для просмотра с большого экрана.
Я обычно перерабатываю их следующим образом:
- Инвертирую цвета: задник тёмно-серый, шрифт белый
- На первой страничке должен быть какой-нибудь запоминающийся логотип (логотип твоего проекта, или технологии, которую ты пиаришь. Он должен прямо вжечься в мозг смотрящего)
- Все шрифты сконвертить в sans serif или что-то такое серьезное. Никаких комиксансов.
- Поменьше длинных списков. Спикеры пишу длинные списки всего на свете, а ты с начальнкиом сможешь обсудить от силы 3-5 пунктов. По той же причине не должно быть многоуровневых списков и прочего треша и угара.
- Выбросить картинки – мемасики и смехучеки с Боромиром
- Графики и пайчарты — оставить. Если их вообще нет — добавить.
- Особый понт и шик — сделать печатную версию слайдов на хорошей бумаге и действительно распечатать их. Принтер в соседнем книжном магазине, скорей всего, не умеет печатать белым по темной бумаге, поэтому придется нагуглить подходящую типографию.
5. Заключение
Это был короткий чеклист, о чем стоит подумать перед посещением конференции. Если ты
- поставил четкую цель,
- составил план мероприятия,
- определил концепцию того как это мероприятие укладывается в повседневную жизнь коллектива,
- вовремя купил билеты на конфу-самолет-гостиницу (вовремя — в смысле, сейчас, потом будет поздно),
- основательно подгтовился к конференции, используя видео, блоги, книги и другое,
- внимательно слушал доклады и майндмапил важные мысли,
- после конференции проработал эти заметки и отсмотрел видео,
- по полученному сформировал картину трендов и задач по развитию твоего проекта,
- и грамотно презентовал начальству
То конференция, возможно, прошла незря.
А если ты собираешься всё-таки, ни к чему не готовиться, и тупо жрать булки в коридоре в ожидании конца доклада, то можешь здорово сэкономить, поменяв конфу на посещение Бургеркинга.
Всем добра.
