Із зони комфорту на європейську конференцію: як я підготувався за 28 днів і виступив вперше

Привіт, мене звуть Гліб, я працюю в Django Stars на позиції Senior Software Developer. Сім років тому один хороший хлопець (привіт, Niko Skrypnik!) привів мене в світ Python, і з тих пір я працюю в сфері web, пройшовши шлях від створення сайтів для баптистів з Огайо і езотериків з Таїланду до розробки fintech/CRM/real estate продуктів.

Публічні виступи ніколи не були моїм коником, але так вийшло, що в квітні 2019 року я розповів про те, як і навіщо використовувати SQLAlchemy Core у проектах на Django. І одразу зі сцени головною конференції для Django community у Європі — DjangoCon Europe 2019.

Виступ на конференції

Як я зважився виступити на конференції

Відразу Хочу зазначити, що я — не та людина, яка може з легкістю говорити ротом, концентрувати на собі увагу оточуючих і вже тим більше штовхати публічні промови.

В інтернетах пишуть, що це називається глоссофобией або страхом сцени, в моєму випадку в гармонійному поєднанні з інтровертністю як такої. Весь мій досвід в області мовлення зводиться до дуже давнім і поодиноких випадків: захист диплома, випадкове п'ятихвилинне виступ на lightning talk в Дніпрі про Zope framework і один внутрішній доповідь в компанії аля sharing experience по закінченні одного цікавого проекту. Власне, і все. Тому це подія мені чимось нагадувало ситуацію, коли вивозять на середину річки і скидають у воду, щоб навчити плавати. Так і тут, замість поступової тренування на невеликих локальних митапах — відразу на європейську конференцію.

Тема доповіді та заявка на виступ

Вся історія з виступом на DjangoCon Europe 2019 насправді почалася за півтора року до самого заходу, коли до нас в компанію зайшов проект, пов'язаний з аналізом даних з EMR-систем (electronic medical record). Якщо коротко, це агрегація і побудова графіків ефективності відділень різних клінік, на підставі яких менеджери і власники мереж поліклінік і лікарень можуть оцінювати ефективність і оптимізувати свій healthcare-бізнес.

На етапі вибору технологій ми прийшли до висновку, що Django ORM з ряду причин не підходить для цього завдання, тому почали дивитися в бік SQLAlchemy. У той же час від самого Django нам не хотілося відмовлятися, тому що він з коробки покривав всі інші завдання, пов'язані з роботою web-додатки (адмінка, юзери, пермишены, перекази тощо). Так і з'явилася ідея зробити в'язку Django + SQLAlchemy Core. Виявилося, що на цю тему інформації та гайдів майже не було, хіба що пара пакетів на GitHub про Django + SQLAlchemy ORM. Відчуваючи себе першовідкривачем, я із задоволенням взявся за роботу.

В результаті ми залишилися задоволені результатом і впевнилися, що така зв'язка може бути вкрай ефективним для певного типу проектів. Захотілося поділитися отриманим досвідом з іншими розробниками, які можуть опинитися в такій же ситуації вибору відповідних інструментів, і висвітлити нюанси використання цього стека на реальному проекті.

Так народилася невелика стаття на цю тему «Merging Django ORM with SQLAlchemy Easier for Data Analysis» — вона і стала першим кроком до підготовки повноцінного доповіді.

У лютому за тиждень до закриття call for proposal на DjangoCon Europe від нашої компанії надійшла пропозиція всім бажаючим або раздумывающим подати заявки на участь. У підсумку зважилися на таке три людини, включаючи мене. Рівно через місяць всім нам прийшла відмова, ми видихнули і розслабилися.

Після цього пройшов ще місяць. І одним прекрасним ранком, випадково прокинувшись раніше звичайного, я глянув на телефон і побачив лист:

«Dear Gleb,
After some late modifications to our programme, we are happy to announce that your submission was accepted to DjangoCon Europe 2019».

Після цього заснути я вже не міг і почав рахувати дні до початку конференції. 28 днів. Всього 28 днів, а з матеріалу у мене невелика стаття, в якій лише 1/10 того, про що планував розповісти. Відлік пішов.

Підготовка до виступу: що і навіщо

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

Почитавши статті по сторителлингу і послухавши поради від досвідченої на цьому терені співробітниці Насті Марушевський (яка як раз цю тему піднімає на своєму курсі для копірайтерів в Projector), я почав замислюватися про структуру виступу.

Насамперед потрібно відповісти собі на єдине питання, від якого все бере початок: Яку думку я хочу донести до людей у своєму виступі?Запам'ятайте відповідь. Він буде надійним компасом і опорою на багатьох етапах, навіть коли ви будете підніматися на сцену до трибуни спікера. Для мене було важливо розповісти людям, що Django ORM — не панацея, що і є інший зручний інструмент, якого не потрібно боятися і, як мінімум, варто розглянути перед початком розробки певного типу проектів.

Наступний крок — зробити план доповіді, який слід відразу озвучити аудиторії. Для себе я вирішив його зробити таким:

  1. Навіщо це потрібно і в яких випадках ці знання можна застосувати з користю(щоб зацікавити людей і тих, хто сумнівається).
  2. Чому варто відійти від звичних правил/інструментів і розглянути альтернативу(SQLAlchemy Core).
  3. Як відбувається інтеграція такого рішення на прикладах.
  4. Плюси і недоліки : про що важливо знати і пам'ятати.

Що було найскладнішим

Під час підготовки презентації було два взаємозалежних види труднощів.

Перша трудність — контент.

Необхідної мені інформації ніде не було. Потрібна була сильна аргументація того, чому Django ORM не підходить: які запити не може побудувати, які будує неоптимально і які не можна оптимізувати (не спускаючись до рівня raw SQL), що незручно/важко/нечитаемо. Без сильної аргументації виступати з доповіддю не мало ніякого сенсу.

Левова частка часу пішла саме на цей етап — шукав цікаві SQL-запити в інтернетах і намагався реалізувати їх на Django ORM, питав про нетривіальних випадках у колег на сусідніх проектах (і шукав у своїх). Потім, поглянувши з боку, розумів, що приклади недостатньо гарні або несподівано знаходив рішення — доводилося все викидати і починати дослідницьку діяльність заново. А годинник-то цокає. Закінчити цю частину вдалося лише за тиждень до початку конференції.

Звідси витікала друга складність — психологічна.

Думка про те, що не з чим їхати виступати, дуже тиснула і тримала в напрузі, перетворюючи кожен день, без зайвих подробиць, у пекло.

В день виступу, природно, не спалося і був мандраж. Дуже складно далося початок виступу. Особливо сильно закарбувалася в пам'яті пауза, коли тебе вже оголосили, зал притих, а ти ще не почав свою промову. У цей момент фізично відчувається сконцентроване увагу публіки і усвідомлення того, що найближчі 35-40 хвилин єдиною дійовою особою буду я. На щастя, з кожною хвилиною було все менше і менше сторонніх думок. Знайомі слайди прямо перед очима були надійним орієнтиром протягом всього виступу і допомагали будувати мова за заздалегідь відомими стежками.

Що б я зробив по-іншому

З того, що можна було поліпшити, в першу чергу цеякість виступу , але для цього потрібно було починати готуватися як можна раніше. Коли вже є вся інформація, можна приступати до роботи над якістю її викладу, починаючи з банального поліпшення англійської та позбавлення від слів-паразитів і до опрацювання драматургії/жестикуляції/пауз. Все це окремий світ знань у сфері публічних виступів, в який, як мінімум, слід заглянути, а в ідеалі — сходити на спеціальні курси.

Другий момент: при подачі заявки на виступ я б вибрав 50 хвилин, а не 30 . Спочатку я і не припускав, що виявиться так багато матеріалу. У підсумку довелося деякі моменти упускати, про щось говорити побіжно і дуже швидко перемикати слайди. До речі, у мене їх було 64, тобто потрібно було йти в темпі 30 секунд на слайд. А на деяких ще й код був... При підготовці в основному доводилося звертати увагу на те, наскільки швидко я кажу, щоб встигнути у відведений таймслот. Внаслідок постраждала якість і ускладнилося сприйняття матеріалу.

Виступ на конференції

Рекомендації тим, хто хотів би виступити на конференції

Головний моя порада: знайдіть тему, яка чіпляє і спонукає розповідати про неї. Наприклад, про досвід інтеграції різних інструментів, про знайдених best practices, про архітектурні рішення, про щось прикладному/новий/мотивирующем — те, що буде корисно спільноти і після чого до вас підійдуть і скажуть: «Дякую, це був відмінний доповідь, ми як раз з цим зіткнулися». Сумно і нудно дивитися на виступи, де просто пережовують документацію.

Періодично радьтеся і запитуйте думку компетентних колег. Погляд з боку дуже корисний. І щоб не витрачати сили даремно і не робити зайвого, краще поетапно валідувати ідеї і чернетки, перш ніж доводити їх до розуму.

Готуйтеся заздалегідь , aka «зробив діло — гуляй сміло». Коли весь матеріал зібрано, готові слайди і в голові є структура розповіді, можна починати тренуватися розповідати доповідь з секундоміром. Наприклад, кілька днів поспіль раз або два в день, а потім можна робити це рідше і періодично освіжати в пам'яті. Цього повинно бути достатньо для хорошого виступу. Але якщо хочеться підняти планку виступу на новий рівень, можна використовувати цей час для роботи над якістю. Приміром, почерпнувши інформацію з рекомендацій досвідчених спікерів, можна попрацювати над жестикуляцією, пауз та іншими нюансами. Якщо хочеться під час виступу дивитися в зал і бути ближче до аудиторії, то також потрібно відучувати себе дивитися на слайди під час розповіді.

Обов'язково варто виступити перед колегами з готовим доповіддю. Попросіть їх в кінці задавати будь-які питання, нехай навіть очевидні або провокаційні — це допоможе зімітувати різні ситуації при інтерактиві з залом після заготовленої частини, де вже доведеться імпровізувати і викручуватися на ходу. Деякі питання можна передбачити і подумати над відповіддю заздалегідь. Крім корисного фідбек і додаткової практики виступу в доброзичливій обстановці цей крок дав мені впевненість у підготовленому матеріалі, і, найважливіше, впевненість у своїх силах виступити перед великою аудиторією, значно зменшивши психологічне напруження.

У разі інтернаціонального виступу варто приділити увагу граматики та вимови , розповівши доповідь репетитора. Наприклад, правильно будувати речення і використовувати потрібні часи, виписати і перевчити слова, які звикли говорити неправильно. Сюди також відносяться терміни, назви бібліотек/інструментів, акроніми — їх можна підслухати в інших виступаючих в Youtube. Потрібно переконатися, що не використовується щоденний робочий IT-сленг, так як ми цього можемо навіть не помічати, а іноземці просто не зрозуміють. Один з прикладів — «апі пойнт», а по-хорошому має звучати як «эйпиай эндпойнт».

Потрібно прагнути до того, щоб людям не різало слух від помилок, і вони не відволікалися з-за цього від суті доповіді.

Поради тим, хто боїться виступати

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

Додатковим двигуном повинна бути тема , а саме її корисність, бажання поділитися знаннями, мотивувати, розширити кругозір, підкинути хороших ідей і показати цікавий підхід. Зробити свій внесок у розвиток ком'юніті і поповнити базу знань галузі.

Маючи під ногами таку опору, можна впевнено починати робити перші кроки в бік невеликих публічних виступів серед своїх, плавно набираючи обертів і збільшуючи масштаби.

Втомлені, але задоволені обличчя. Колега Олександр Рябцев теж дебютував на сцені з Lightning talk

Життя після виступу

В першу чергу цей виступ став одним з важливих досягнень для мене особисто: я і не думав про те, що буду коли-небудь так виступати перед людьми і тим більше англійською. Від однієї лише думки про це частішав пульс, а долоньки мокрели. Це було радикальне катапультування з зони комфорту і подолання страху.

Після виступу залишається приємне відчуття від того, що поділився чимось корисним і новим, що комусь ця інформація стане в нагоді і наштовхне на правильне рішення. Почуття, що зробив внесок у community та додав більше інформації в певну нішу, в якій її було не так вже й багато. З-за цього з'являється бажання продовжувати робити такі внески в співтовариство.

У стані афекту навіть виникали думки поїхати на перший в історії Pycon Africa в Гану в серпні, проте з часом настільки радикальний запал вщухає. Та й ціни на переліт натякають не здійснювати таких імпульсивних вчинків. Можливо, розповім цей же доповідь на PyCon Ukraine восени. Моя наступна мета — шукати теми для нових статей і доповідей, щоб вони були корисні і недостатньо інформаційно освітлені, тому що саме це додає ентузіазму, сил і енергії для соціально корисних активностей.

Ще з'явилося чітке розуміння того, що якщо хочеться чогось досягти, то потрібно повністю віддаватися цьому. Час, сили, так і себе самого. Чи то доповідь на конференції, запуск стартапу, вивчення мови програмування, або підкорення фортепіано. Коли день у день наполегливо рухаєшся в намічену бік — обов'язково буде результат. Головне — у важкі моменти не втрачати мотивацію і подумки промовляти, навіщо ти це робиш. Банально, але цю думку мені вдалося відчути, і сподіваюся, це допоможе рухатися далі.

Ось матеріали мого виступу:


Читайте також:

Як стати доповідачем на міжнародній конференції: покрокова інструкція

Як подолати страх публічних виступів: поради бізнес-тренера

Опубліковано: 14/05/19 @ 10:21
Розділ Безпека

Рекомендуємо:

Senior Research Analyst в IBM Олександр Романко: «Аналіз великих даних буде популярними ще років 10 мінімум"
C++ дайджест #15: геолокація з Qt, ACCU 2019
PM дайджест #18: порівняння ефективності методологій, фреймворк AgileLite, перехід з розробки PM
7 причин, чому продукти не стають успішними на ринку. Приклади Nokia, IBM, Apple та інших компаній
Як дорости до рівня Solution Architect