Про что выступать
Я решил перебраться со своим блогом на отдельный сайт. Основная причина — у Medium отвратительная политика монетизации, которая рушит мой опыт читателя. Поэтому жду вас на сайте etolstoy.com! А конкретно эту статью можете прочитать по этой ссылке.
Пару раз, читая статьи с советами по публичным выступлениям, натыкался на один довольно провокационный тезис, с которым я никак не могу согласиться.
Никогда не выступайте.
Здесь речь ведется о том, что способов самовыражения масса — статьи, подкасты, встречи с друзьями разработчиками. А выступать с презентацией — сложно, лучше даже и не пытаться, только хуже себе и слушателям сделаете. Да и вообще, выступать надо только тогда, когда какая-то тема у тебя прямо горит, ты в ней отлично шаришь, и она уникальна.
В отличие от авторов совета я верю в то, что практический любой доклад может быть полезным — все зависит от правильной аудитории, способа подачи и уровня подготовки. Но в первую очередь важно понять, о чем вообще стоит рассказывать.
Я для себя вывел три ключевые категории докладов, которые могут и должны друг с другом пересекаться. Чтобы было проще, буду приводить примеры с моей любимой конференции — AppsConf.
Прикладные доклады
Для таких докладов хорошо подходит термин “фастфуд”, причем без всяких негативных коннотаций. Эти выступления обычно не сносят крыши. Вы вряд ли узнаете там что-то, чего не могли бы при большом желании выяснить сами. Это просто какой-то кусок знаний, которые можно прямо взять и использовать в своих задачах хоть завтра — и он вам может сэкономить очень много времени и сил.
- Эволюция CI в команде мобильной разработки, Николай Нестеров
Поэтапный гайд по настройке и тюнингу CI в зависимости от сложности проекта и размера команды. Много практических советов, которые можно смело использовать в своей ежедневной деятельности. - Разработка библиотеки: от API до публичного релиза, Ася Свириденко
Если перед вами стоит задача по разработке собственной либы, то этот доклад разжевал все возможные грабли за вас. Смотрите, выписываете тезисы, радуетесь. - Что нам стоит видеоредактор построить, Максим Никулин
Видеоредакторы — относительно узкая область. Благодаря докладу Макса, вы можете не пытаться понять все нюансы их разработки самостоятельно, а просто использовать его детально описанный опыт.
Хардкорные доклады
Это рассказы на довольно узкие или сложные для понимания с первого и даже со второго раза темы. В отличие от прошлой категории вообще не факт, что полученные знания вам хоть когда-то в жизни пригодятся. Эти доклады часто отличает то, что спикер является уникальным носителем этих знаний.
- Как ускорить интернет, Александр Тоболь
Для типичного мобильного разработчика все за пределами Alamofire уже хардкор. А в этом докладе вообще история про разные сетевые протоколы, особенности их работы и оптимизации производительности. - “Latency numbers” на iPhone, Дмитрий Куркин
Дмитрий замерил производительность оперативной памяти и файловой системы на iOS. Скорее всего, вам вообще никогда не придется об этом думать, но технические детали, в которые он погружается, чертовски интересны. - Инфраструктура для UI-тестирования в Авито, Влад Алексеев
Поддержка 1.000 UI тестов на 50 Mac Mini это что-то из категории “проблемы больших компаний”. Влад рассказывает об очень крутых инженерных решениях, которые позволяют ему решить не слишком актуальную для большинства проблему.
Хайповые доклады
Тут хайп не стоит понимать слишком буквально. Это не обязательно доклады про ML, AR и блокчейн. В эту категорию я вкладываю такие истории, которые провоцируют слушателей на живое обсуждение, холивары, да и вообще, горящие глаза.
- Как работают большие команды в мобильной разработке, Максим Ефимов
500 инженеров на одно приложение. Опять же, это не самая часто встречающаяся проблема, но послушать про это и потом обсудить — бесконечно интересно. - Главное не качество, а количество, Егор Бугаенко
Хайп здесь начинается сразу от имени докладчика. Выступления Егора всегда вызывают поток бурных обсуждений. Этот случай не исключение — разговор ведется о том, что разработчик не должен думать о качестве того, что он делает. - Собеседование мобильных разработчиков. Обе стороны баррикады, Александр Черный
Тема собеседований стабильно очень горячая. У каждого из зрителей есть тут свой опыт, который он будет сравнивать с опытом спикера — и это неминуемо приведет к горячим дискуссиям.
Все эти категории вполне неплохо смешиваются. Доклад может быть одновременно прикладным и хардкорным — когда спикер одновременно затрагивает и вопросы по ежедневному использованию технологии, и лезет в какие-то глубокие кишки. Может встречаться смесь хардкора и хайпа — например, какие-нибудь суровые истории про машинное обучение. Вот пересечений сразу трех секторов я, навскидку, еще не встречал — но посмотреть на это было бы очень интересно.
Чем этот фреймворк хорош? Готовясь к докладу, очень просто пойти не в ту сторону, и, рассказывая про очень прикладную тему, не рассказывать ни слова о ее практическом применении, а пытаться вытащить технические кишочки. Мой фреймворк позволяет понять, каким должен быть ваш доклад, и какие ключевые характеристики в нем стоит качать — техническую сложность, daily tips или количество замечательных историй на единицу времени.
Вот все за пределами этих окружностей я аккуратно называю “коричневой зоной”. Чтобы не ругать других, поругаю сам себя. Выступал я пару лет назад с набором историй про то, как мы делали клиент для LiveJournal. Это не был прикладной доклад — то, что я рассказывал никому бы особо не пригодилось. Не был он и хардкорным — никакой технологической новизны или сложности. Да и хайпануть не вышло, по наполнению эти истории были довольно бедненькими.
Бывает и по-другому. Я поехал выступать на небольшой митап в Новосибе с докладом про чистоту юнит тестов — о разных паттернах и всяком таком. Казалось бы, обычный прикладной доклад. Звезд с неба не хватает, но дает неплохие советы, которыми можно воспользоваться хоть завтра. Кроме того, один раз я с ним уже выступал в Москве, зашло на ура. Но, тем не менее, для посетителей он оказался стандартной “коричневой зоной” — когда я спросил у зала, кто вообще пишет тесты, руку не поднял практически никто. История стандартная — все аутсорсеры, у всех сроки-сроки, и мне бы им лучше было рассказать про то, как тесты помогут ускориться, а не про то, как сделать их чистыми. В общем, доклад не зашел.
Всегда в первую очередь определяйте свою целевую аудиторию. Какой уровень разработчиков, из каких они компаний, с какой целью приходят на конференцию. Рассказать про свой двухдневный опыт использования какой-то библиотеки можно на локальном митапе, куда люди приходят предрасположенными к тому, чтобы просто послушать про чей-то чужой опыт. Не надо рассказывать о том же самом на крупной конференции, где за билет платят довольно большие деньги, и ждут за это материала соответствующего качества.
О чем конкретно стоит рассказать — решать вам самостоятельно. Я со своей стороны могу просто посоветовать несколько направлений, в которые стоит покопать.
- Смотрите, как я запилил фичу
Выпишите все фичи и задачи, которые делали за последние месяца три. Выберите ту, при реализации которой столкнулись с трудностями или недостатком информации. Расскажите об этом и сделайте прикладной доклад. - Смотрите, как я не запилил фичу
То же самое, что и в первом случае, но посмотрите на задачи коллег. Не все хотят выступать, так что они могут быть не против, если вы заберете тему себе. Попробуйте спросить. - Мои выходные с либой
Еще один прикладной доклад про какую-нибудь либу, которую вы погоняете на своем проекте, а потом поделитесь впечатлениями с сообществом. - Я прочел или попробовал
Прочтите крутую книгу, попробуйте какой-то новый для себя подход. Из этого может получиться как прикладной, так и хардкорный доклад — все зависит от вашей усидчивости и глубины копания в технологию.
Если есть желание — выступайте. Не стоит переживать из-за того, что вы не проводите целые дни, работая над сложными платформенными задачами и обмазываясь потенциальными темами для докладов. Любой опыт может быть интересен, если вы правильно подберете аудиторию, площадку, и вложитесь в его подготовку.
