- PVSM.RU - https://www.pvsm.ru -
Это статья появилась за распитием пива с друзьями в Академгородке — стало понятно, что лучше её перенести в текстовый вид, дабы не повторять сто раз.
Существуют легенды на тему того, что единственный смысл конференции — это найти себе работу покруче за деньги текущего работодателя. Несмотря на внешнюю неэтичность, в этом хотя бы есть смысл. В реальности бывает куда хуже: люди приходят на конфу, и потом не знают, чем заняться, кроме как хавать булочки в переходе (особенно если они бесплатные). Давайте я расскажу, что делать, чтобы не тратить свои и чужие ресурсы зазря.
Основная проблема разработчика в том, что навыки, технологии, идеи — всё это постоянно устаревает. Когда-то на земле жили динозавры, а теперь их нет. Вы точно не хотите быть одним из этих динозавров. Для этого нужно сфокусироваться на обновлении собственных знаний — это важно и максимально приоритетно. Это настолько приоритетно, что вы готовы потратить на это свои и чужие бабло и время.
Человеческое
В книге «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. Остается либо дивиться на непонятные вещи, о которых вещают со сцены, либо хавать булочки в переходе.
Чтобы не опростоволоситься, перед тем как куда-то ехать, и вообще соглашаться на конфу, надо изучить её программу и составить план подготовки.
Дальше я скопипастил из недавней статьи [2] план конференции DevOops 2017 [3]:
Зацените как меняется восприятие этого списка сразу же, как вы понимаете, что это не просто список чего-то, что мужики будут толкать со сцены, а список вещей, с которыми лично тебе надо срочно заранее ознакомиться. Он начинает выглядеть гигантским.
Важно, что предварительная подготовка должна занимать какое-то достаточно небольшое время, например суммарно час в день. Иначе обычный ленивый разработчик (типа автора этой заметки) отмораживается и перестает готовиться. Простой способ – не нужно изучать вообще всё перечисленное, а только по одному слову из каждого пункта, это серьезно облегчит задачу.
Теперь классифицируем источники информации, по которым мы будем проводить предварительную подготовку.
Просто берете любую технологию, и начинаете её использовать.
Использовать где угодно:
Не нужно тратить огромное количество времени, достаточно сделать пару рабочих прототипов, чтобы зацепить основные идеи. Например, чтобы завести Ansible и что-нибудь им сделать — нужны считаные минуты, плюс это можно тут же применить на работе.
Способ хорош тем, что в отличие от всевозможных туториалов, он дает понимание о вещах, которые нужны лично тебе, а не доброму дяденьке, сочинявшему документацию на сайте.
Сейчас все мы проводим в социальных сетях просто непростительное количество времени. Достаточно открыть Хабр или Фейсбук, и залипнуть на целый день. Способ использовать прокрастинацию с пользой — начать читать технические блоги по нужным темам.
Чтобы обмануть свой
Сейчас я не буду мусорить здесь, описывая всю первую страницу гугла по запроу «Docker Blog», они там все интересные. Если у тебя, читатель, есть какие-то любимые блоги, напиши о них в комментариях!
Возможно теме систематизации devops блогов стоит посвятить отдельный пост. Нужно ли это Напишите в комментариях.
Хочется только отметить, что лучшие материалы — это те, которые промаркированы по времени. Чтобы было четко понятно, какие именно события, и в каком порядке, произошли за последний год. Сравнить «как было» и «как стало». Потом посмотреть «как стало» уже на конференции и сравнить
Как ни странно, в 2017 году, книги всё еще не изжили себя. В отличие от обрывочных твитов и постов в бложиках, они представляют собой конденсированную и многократно проверенную мудрость, особенно это касается учебников по фундаментальным технологиям.
Некоторые советы по использованию книг:
На ютубе есть огромное количество видео, которые помогут быстро настроиться на правильный лад, например DockerCon 2017 [4]. Особенно круты видеозаписи предыдущих конференций: можно посмотреть «что было» и «что стало», как менялось отношение спикеров по разным вопросам из года в год.
Хорошие рекомендации недавно были опубликованы вот в этой недавне статье на Хабре [5].
На этом можно бы и закончить, но всё же главное:
Отдельно по поводу записей. Если мысли тут же не записать, то под давлением мощного потока информации они быстро забываются. Диктофоны на подобных мероприятиях зачастую работают плохо из-за акустики залов и стремности диктофона (можно купить хороший диктофон). Лично для меня лучше всего работают mind maps на ноутбуке. Мне нравится платный Mindjet MindManager, но есть и куча бесплатных утилит (google: «best free mind mapping software 2017»). Если дополнить это слайдами доклада (докладчики обычно выкладывают их в интернете), получается очень хорошая база.
Внедрение чего угодно с конференции связано с несколькими сложностями.
Во-первых, материалы конференции не являются быстрофиксами для решения лично твоих проблем. Докладчики — не твои сотрудники. Просто так срисовать доклад и метнуться у себя что-то чинить — не получится. Поэтому можно относиться к полученной информации как к трендам, тенденциям, которые нужно учесть и проработать.
Чтобы было что прорабатывать, нужно иметь:
Дальше идет собственно проработка темы. Например, если мы на конференции впервые познакомились с Kubernetes, то не стоит бежать и внедрять его. Стоит всесторонне изучить тему и отнестись к этому максимально серьезно.
Во-вторых, обычно внедрение новшеств зависит не только от вас, а еще и от руководителей. Руководители зачастую относятся к конференциям, и информации, полученной с них, без особой радости. «Какая-то фигня для хипсторов». Изменить это отношение зачастую помогает просто нормальный диалог с описанием открывающихся перспектив.
Тут можно было бы написать мануал по проведению презентаций для руководства, но это тема отдельной статьи. Ограничусь основными мыслями.
Наиважнейшая штука в том, как именно подать внедрение новой технологии. Обычно мы, технари, просто задавливаем собеседника интеллектом. Но в случае если ты пытаешься убедить начальника провести тестирование какой-то совершенно новой штуки, того самого критического объема знаний может еще не быть. Тогда можно задавить собеседника здравым смыслом. Здравый смысл стоит начать с описания типа:
Еще раз подчеркну, что так как мы получили на конференции не конкретные быстрофиксы, а снимок трендов, перед тем как вступать в такой диалог, нужно основательно подготовиться.
Зачастую начальство привыкает к общению в виде просмотра слайдов. Можно считерить, и просто доработать слайды с конференции, благо на них есть публичная ссылка.
Но слайды для огромной конфы готовятся для просмотра с большого экрана.
Я обычно перерабатываю их следующим образом:
Это был короткий чеклист, о чем стоит подумать перед посещением конференции. Если ты
То конференция, возможно, прошла незря.
А если ты собираешься всё-таки, ни к чему не готовиться, и тупо жрать булки в коридоре в ожидании конца доклада, то можешь здорово сэкономить, поменяв конфу на посещение Бургеркинга.
Всем добра.
Автор: Олег Чирухин
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/konferentsiya/259413
Ссылки в тексте:
[1] мышление: http://www.braintools.ru
[2] недавней статьи: https://habrahabr.ru/company/jugru/blog/331346/
[3] DevOops 2017: https://devoops.ru/
[4] DockerCon 2017: https://blog.docker.com/2017/05/dockercon-2017-session-videos-now-live/
[5] в этой недавне статье на Хабре: https://habrahabr.ru/company/jugru/blog/331898/
[6] Источник: https://habrahabr.ru/post/332126/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.