В глазах обывателя типичный разработчик представляется нелюдимым бородачом, сидящим в темноте в одиночестве перед мерцающим монитором за сложнейшими задачами. Так ли это на самом деле? Конечно, нет — более того, в современном мире такой попросту не получил бы доступ к таким задачам. Какими на самом деле часто оказываются талантливые разработчики, и зачем хорошему программисту надо осваивать soft skills?
Чтобы ответить на эти вопросы, я взял интервью у Владимира vlkrasil Красильщика, разработчика из Яндекса, о том, как он «вышел из тени», начал выступать на технических конференциях, и что из всего этого получилось.
В начале было слово. И слово было… Легаси
JUG.RU: Владимир, расскажите, как вы начали выступать? Что привело к такой жизни?
Владимир: Выступления всегда были частью моей жизни, правда, путь до выступлений на айтишных конференциях был долог и тернист. Я выступал на отчетных концертах и конкурсах, пока учился в детской музыкальной школе №31 Санкт-Петербурга, пел в хоре, а став постарше, играл фанк и босса-нову в группе «Grano Salis». Так что сам формат публичного выступления, где ты на сцене перед аудиторией и несешь в массы доброе и вечное, мне хорошо знаком с детства.
С выступлениями для айтишников все получилось как-то просто, спонтанно и естественно. Я работал в компании Luxoft на легаси-проекте, в котором одна и та же задача, а именно преобразование одних Java-объектов в другие (то что в народе еще называется «конвертацией», «маппингом» или «трансформацией»), решалось пятью или шестью разными способами. Заниматься поддержкой кода преобразований, основанных на разных подходах, становилось неоправданно сложно, поэтому был поднят вопрос о том, чтобы оставить только один подход — разумеется, самый лучший. Я стал разбираться в существующих библиотеках для преобразований, в том числе Dozer, ModelMapper и Transmorph, и подготовил презентацию для своей рабочей группы. Позже материалом заинтересовались в ArchComm — Архитектурном Комьюнити Luxoft — так как оказалось, что это типовая задача для проектов вокруг, и опыт нашей группы может быть полезен для коллег. Я провел презентацию для АрхКома, познакомившись с тогдашним и теперешним предводителем АрхКома Мишей Дружининым. Это было время, когда в Санкт-Петербурге вовсю проходили доклады возродившегося сообщества питерских Java-разработчиков JUG.RU, а в умах его организаторов Алексея 23derevo Федорова и Андрея real_ales Дмитриева уже зрел план создания крутой Java-конференции в Питере. Миша познакомил меня с Алексеем и Андреем, которые в тот момент как раз подбирали доклады и докладчиков и заинтересовались темой моей презентации. В результате ребята предложили мне выступить на их конференции, помогли подготовить и подтянуть доклад с технической и презентационной точек зрения. Так родился мой первый доклад «Java-mapping для прагматичных программистов», с которым я выступил на самом первой конференции Joker Санкт-Петербурге в 2013 году. Так началось мое сотрудничество с ребятами из JUG.RU.
Дальше все пошло-поехало как-то само собой: я просто работал, а побочным эффектом становилось появление какого-то материала, который в итоге оборачивался докладом и последующим выступлением на той или иной конференции. Так, например, разбор инструментария для мониторинга Java-приложений вылился в обзорный доклад на Joker 2014-го года, рефакторинг логирования в микро-сервисах превратился в выступления на JBreak в Новосибирске и на JPoint в Москве весной 2016-го, а занятие архитектурой породило доклад по Big Data, с которым я буду выступать на Joker 2016 в Санкт-Петербурге в октябре. Мое увлечение open source обернулось серией вебинаров и докладов о vert.x, очередной из которых я также собираюсь нести в массы на предстоящем Joker.
JUG.RU: Я знаю много конференций, на которых выступают маркетологи и сейлзы. Их интерес понятен. А в чем профит у инженера? Помогают ли выступления на конференциях в работе?
Владимир: Подготовка и проведение доклада помогает по-настоящему глубоко разобраться в теме доклада. Одно дело, когда ты на работе срочно-срочно разбираешься в десятке библиотек или инструментов, выбираешь более-менее работающее как тебе надо, готовишь его напополам с бубном, чтобы, что называется, еще вчера вывести в продакшен. И совсем другое дело, когда ты готовишь доклад о своих подвигах для технически грамотной и опытной аудитории: это требует совершенно иного уровня проработки деталей материала, аргументов, замеров и чисел. Окончательная полировка твоих знаний по теме происходит уже непосредственно во время доклада, когда ты отвечаешь на вопросы профессионалов из аудитории или сразу после доклада в дискуссионных зонах, кулуарах конференции или социальных сетях. Тогда тебе становится совершенно понятно, владеешь ты темой или нет, какие аспекты темы еще не раскрыты, в каких направлениях еще следует покопать.
Также нужно понимать, что все инженеры-докладчики выступают от лица компаний в которых трудятся, а у компаний есть свой шкурный интерес на конференциях, выражающийся, как правило, в поиске талантливых специалистов и, как модно говорить, «укреплении лояльности к бренду компании» в техническом и информационном сообществах. Для этих целей компаниям позарез нужны высококвалифицированные специалисты, обладающие техническим опытом и способные рассказать про этот опыт на широкую публику. Поэтому компании очень любят и поощряют технарей, которые вылезают из своих удобных проектных «ракушек» на конференции и митапы и, прилагая неимоверные усилия над собой (тут нет ни капли сарказма), открывают свой рот и общаются с такими же, как и они, шизоидного типа личностями, коими являются большинство программеров.
По себе могу сказать, что с тех пор, как я начал выступать на конференциях от лица компании Luxoft, я узнал массу людей в компании и оказалось, что и меня заочно узнало довольно много людей в Luxoft. В результате меня стали приглашать в качестве спикера на внутренние мероприятия компании и печатать мои статьи в корпоративном журнале. В итоге передо мной стали открываться разнообразные интересные возможности и должности, в частности, моя последняя позиция Big Data-архитектора, которую я занимал вплоть до перехода из Luxoft в Яндекс.
JUG.RU: Насколько я понимаю, до перехода в Яндекс свои доклады ты строил на основе своего опыта в Luxoft. Компания помогала тебе в этом направлении?
Владимир: Luxoft – это самый настоящий «кровавый энтерпрайз» в лучшем смысле слова, а именно: технологическая и сервисная компания, в которой решаются реальные проблемы очень солидных клиентов, в частности банков, авто- и авиа-концернов, причем в реальные сроки и с ограниченными ресурсами. Я бы сказал, что компания Luxoft даже не кузница, а просто-таки доменный цех разработчиков, которые заинтересованы в том, чтобы отрабатывать и применять навыки работы в реально больших и сложных проектах, как с технологической, так и социальной точек зрения. Огромное число разнообразных технологий, как проверенных временем, так и «еще горяченькие, только что из печи» могут быть тесно сплетены в рамках одного проекта. Более того, над одним проектом могут работать люди из разных городов, стран и даже континентов, поэтому ничего удивительного, что в данных условиях появляется масса интересных и практически полезных тем для докладов. Появлению своих уже отыгравших «прагматичных» докладов про Java-маппинг, мониторинг и логирование, как и грядущего «Анти-введения в Big Data» я обязан исключительно опыту, полученному на проектах в компании Luxoft.
В Luxoft очень поощряется желание и умение технических спецов выступать публично от лица компании. Как только девочки из отдела маркетинга Диля Салахетдинова и Настя Тихомирова просекли, что я не прочь подготовить и «толкнуть речь», меня стали зазывать в качестве спикера на различные внутренние и внешние мероприятия компании, например неформальные открытые встречи Logeek Night, которые проходят по всей России, Java Open Day в Софии, а также устроили мне серию вебинаров посвященную vert.x в рамках Luxoft Technology Series. Компания с удовольствием отправляла меня с докладами в командировки для выполнения таких вот компанейских стратегических миссий и всегда находился компромисс с моими проектными, производственными задачами.
Один в поле не воин: О перспективах, командах и Senior'ах
JUG.RU: Для Senior-разработчика путей карьерного роста не так много, если не уходить в управление людьми. Как публичные выступления влияют на профессиональное развитие?
Владимир: Я бы не сказал, что у «синьерного» разработчика, помимо управления людьми, мало путей карьерного роста. Можно копать вглубь и становиться техническим гуру, который может быстро и эффективно решать задачи по своей узкой специализации, давать экспертные оценки, оценивать риски и сэкономить компании большие деньги. Можно копать вширь и становится архитектором, который способен надежно проектировать и запускать большие и сложные проекты. Можно подключаться к тренинговым центрам, если они есть в ваших компаниях, читать готовые курсы или придумывать и развивать свои собственные или просто менторить джунов. Фактически каждый может создать себе такую позицию в компании, которая будет заточена специально под него, в которой будут идеальные для вас пропорции между общением, менторством, маркетингом и, конечно, техникой. Одно из таких сочетаний этих активностей в последнее время набирает огромную популярность в России, а за рубежом в айтишных компаниях оно давно существует — это такая должность, как технический евангелист: высококлассный технарь с прекрасными коммуникационными навыками, который представляет интересы своей компании на технических конференциях и митапах по всему миру.
Давайте пару слов скажем о «синьерности». На одном из моих проектов слово «синьер» стало если не ругательством, то сарказмом. Если кто-то хотел кого-то подковырнуть, то он мог построить фразу как-то так: «Ну ты же синьерный человек, как же ты не можешь понять, что тут необходима проверка на null». Или так: «Здесь собрались синьерные люди, поэтому перестаньте играть со смартфонами на совещании и послушайте наконец меня». Ну и тому подобное. А если серьезно, то «синьерность» — это далеко не только понимание нюансов работы внутренностей JVM или экспертное знание нескольких языков программирования.
«Синьерность» — это прежде всего эффективная работа в команде, помноженное на ясное видение целей – своих, своей команды и своей компании. Уже давно прошли те времена, когда существовали на земле русской богатыри, в смысле, гениальные программисты, и были они полноценной боевой единицей. Сейчас один в поле не воин, и пришло время эффективных команд. Кстати, обратите внимание, что и на выступлениях все чаще и чаще можно увидеть на сцене команду докладчиков, ловко перекидывающих друг другу основную повествовательную нить. Я имею в виду и реактивнейшую парочку из Альфа-лаборатории Кирилла tolkkv Толкачева и Александра aatarasoff Тарасова, и знаменитые Puzzlers с Евгением EvgenyBorisov Борисовым, Барухом jbaruch Садогуским из JFrog и Тагиром lany Валеевым, и битву тулов Maven vs Gradle vs SBT, где на сцене одновременно находилось аж трое докладчиков: все те же Евгений и Барух, плюс Антон antonarhipov Архипов из ZeroTurnaround.
Как и в любой другой области, будь то музыка или футбол, команда играет настолько хорошо, насколько хорошо играет наименее опытный член этой команды. Так вот, действительно «синьерный» человек так организует работу команды, чтобы максимально быстро и эффективно подтянуть молодых и горячих как минимум к уровню средней температуры по больнице, и всегда прикроет самое слабое звено. С другой стороны, Senior и сам не будет заниматься ерундой, и другим этого не позволит. Поясню, что я имею в виду: частенько «синьерные» разработчики скатываются в какие-то бесконечные оптимизации, апгрейды или усовершенствования и тратят кучу времени на подобного рода развлечения, при этом красиво и грамотно их обосновывая. Мотив разработчиков понятен: мы же по сути как дети малые, нам интересно узнать, как все устроено. Например, что будет если а) просто взять и заменить версию Spring на самую последнюю, б) просто взять и переписать все на Scala, в) просто взять и прикрутить Hibernate, г) ну вы поняли, о чем я. Но в том-то и дело, что, в отличие от детей, у взрослых (а я считаю, именно так следуют переводить слово Senior с английского языка в данном контексте), есть четкое понимание, что надо делать сперва, что потом и, главное, зачем это вообще нужно делать. И это не потому что взрослым не интересно узнать, как все устроено, вовсе нет. Это потому, что взрослые прекрасно осознают ограниченность имеющихся в их распоряжении ресурсов и особенно дорожат временем. Поэтому взрослые четко понимают, что в первую очередь нужно делать только то, чего нельзя не делать для достижения поставленной задачи. Вот почему «синьерность» или «взрослость» разработчика как раз и заключаются в перманентной сверке курса своей и командной работы с внутренним компасом личных, командных и корпоративных целей.
Чтобы направлять работу своих коллег в правильное русло, нужны навыки ведения переговоров, командной работы, эффективной презентации и переписки. Ведь опытные «ерундисты» прекрасно умеют аргументировать абсолютную необходимость своих экспериментов, переделок и улучшений. И они будут совершенно правы, но исключительно в том разрезе, что их активность необходима им и только им самим, но никак не помогает решать задачи рабочей группы и компании. Причем аргументы «ерундистов» звучат как раз очень пафосно и стратегически корректно, вроде «чтобы в будущем у нас не было проблем» или «зато потом если кому-то понадобится что-то поменять в этом коде», или «этот г@%но-код совершенно невозможно поддерживать, поэтому я все перепишу на аннотациях», и тому подобное. И вот тут «взрослому» разработчику как раз и пригодятся навыки, которые ни в одной спеке не прочтешь и ни на каких курсах «Senior за 21 день» не освоишь — эти навыки естественным образом вырабатываются в ходе подготовки и проведения технических публичных выступлений, и у каждого опытного докладчика вырисовывается свой собственный неповторимый стиль общения с аудиторией и промывки мозгов «ерундистам». Тут ведь надо жестко осадить тролля из зала или «кодирующего ковбоя» из команды, но сделать это таким образом, чтобы человек не «встал и вышел», а чтобы после вашей «водной процедуры» по-прежнему царила комфортная, творческая, но в то же время продуктивная атмосфера.
Я где-то прочитал про принцип 15 на 85, который лично мне оказался очень близок. Звучит он как-то так: наш успех на 15 процентов зависит от того, что мы умеем делать, и на 85 процентов от того, как мы умеем договариваться с людьми. Безусловно, определение успеха у всех разное, но для конкретики пускай это будет успех в узком смысле этого слова — успешный карьерный рост «синьерного» разработчика. Так вот, из принципа 15 на 85 следует, что любому «взрослому» разработчику просто необходимо развивать так называемые soft skills или коммуникативные навыки. Можно представить самую нелюдимую позицию технического гуру, в одиночестве сидящего в темном-претемном отдельном кабинете перед четырьмя мерцающими мониторами, к которому на поклон с благоговением ходят синьеры, директора и даже главный бухгалтер. Но для того, чтобы её получить, тоже надо договориться с кучей людей, так что без умения договариваться её не видать, как своих ушей! Поэтому, когда в своем стремлении стать лучше и успешнее разработчик решает в очередной раз прокачаться технически и изучить еще один язык программирования, освоить новомодный фреймворк или технологию Big Data, он прокачивает только 15 процентов того потенциала, который способен привести его к успеху.
Видео своих технических докладов или вебинаров и участие в опенсорсных или собственных проектах — это оптимальное профессиональное портфолио «взрослого» разработчика. Я помню времена, когда многие увлекались получением всевозможных сертификатов. У меня был знакомый, у которого целая стена была увешана золотистыми картонками от Benchmark, может, кто еще помнит такие. Сейчас сертификация тоже есть, ее никто не отменял, но ничто не сможет дать потенциальному работодателю такого быстрого и точного представления о кандидате, как возможность просто взять и почитать его код на github. А потом просто взять и посмотреть, как кандидат работает с людьми во время выступлений на конференциях или митапах, как он справляется со стрессовыми ситуациями, как отвечает на каверзные вопросы. И я хочу подчеркнуть эту мысль еще раз: да, работодатель всегда оценивает технические навыки кандидата, но он также смотрит и на то, какой перед ним человек, понятно ли он изъясняется и насколько хорошо он впишется в коллектив и микроклимат компании.
Взболтать, но не смешивать: Рецепт доклада-блокбастера
JUG.RU: Откуда набирается материал для докладов? Что дает больше фактуры: работа, собственные проекты, что-то еще?
Владимир: Только основная работа, на которой проводишь большую часть жизни, может дать почву для достоверного, интересного и полезного доклада. Ведь люди, приходящие на наши конференции, решают реальные задачи, с которыми им приходится мучиться в боевых условиях, то есть с ограниченными сроками и ресурсами. И для решения именно таких повседневных задач людям крайне бесполезно, пусть даже любопытно и познавательно, слушать доклады, выросшие в парниковых исследовательских теплицах или папиных гаражах на заднем дворе. Ведь что такое, по сути, полезный доклад? А давайте я раскрою вам маленький секрет «правильного» выступления. Как ни странно, все правильные выступления построены по одному и тому же простому принципу. Итак, правильное выступление — это буквально… «история о том, как главный герой мучительно борется и в конечном счете успешно побеждает какое-то зло». Ничего не напоминает? Да-да, это все тот же старый как мир принцип, по которому пишутся все книги и снимаются фильмы. А знаете, что делает правильное выступление успешным, книгу бестселлером, а фильм блокбастером? Аудитория. Успех приходит, когда аудитория полностью ассоциирует себя с главным героем, во-первых, потому что главный герой похож на неё, а во-вторых, потому что людям уже знакомо это зло, в данный момент они борются с таким же злом, или люди узнают, что такое зло, оказывается, есть и как с ним надо бороться. Попробуйте вспомнить какой-нибудь понравившийся вам яркий доклад. Я уверен, что это будет доклад, в котором человек на сцене рассказывает, как на его проекте вдруг что-то резко сломалось или резко упала производительность или срочно потребовалось сделать то, чего вообще не может быть. И вот уже он, засучив рукава, профилирует и бенчмаркает, расчленяет и склеивает, мыслимыми и немыслимыми усилиями ума, находчивости и воли и, о чудо: гениальное открытие, миг озарения или крутой фреймворк, наконец, выравнивают перформансные графики, устраняют утечку памяти или совершают еще какое-нибудь технологическое чудо. 
Поэтому, для того чтобы отождествление аудитории технарей с главным героем (в данном случае с докладчиком) происходило естественно и бесшовно, на сцене просто обязан стоять действующий «боевой» разработчик, и рассказывать он должен исключительно свою собственную реальную историю борьбы добра со злом, полную боли, печали и отваги. Ну и, разумеется, выступление должно быть полностью построено по системе Станиславского, но это так, уже детали =)
Собственные или опенсорсные проекты обычно порождают менее мощные истории и доклады, потому что и времени на них тратишь несравнимо меньше, чем на основную работу, и не так жестко они проверяются на прочность пользователями и временем, как те же рабочие проекты (если это, конечно, не опенсорсные проекты уровня Linux, OpenJDK, Spring или Kotlin). В моем случае получилось как раз наоборот: исследование инструментария для мониторинга Java-приложений при подготовке доклада вылилось в свой собственный проект Drozd — плагин для Intellij IDEA, который бы позволял разработчику, не покидая интерфейса старой доброй IDE, мониторить удаленные Java-приложения, при этом не требуя от разработчика устанавливать никаких дополнительных агентов на удаленные сервера, инструментировать или модифицировать крутящиеся на них программы.
«Страх и ненависть» технических конференций
JUG.RU: Наверняка вы в конференциях участвовали и как участник, не только как докладчик. Можете сравнить, в чем разница между двумя этими форматами?
Владимир: Впервые в качестве участника конференции я побывал на конференции Sun Tech Days в Санкт-Петербурге в лихие двухтысячные. Признаюсь честно: я вообще на знал, что такое техническая конференция по Java, как и для чего она проходит и какой пользы от нее ожидать, а цель-максимум была «урвать фирменный черный рюкзак с эмблемой Sun и поесть халявный обед» =) Рюкзак мне тогда так и не достался, а что творилось на сцене и в кулуарах, мне было малопонятно: заморский формат конференций с раскидыванием в зал футболок был диковат, девочки-рекрутеры на стендах скорее пугали, чем привлекали (и как девочки, и как рекрутеры), но в целом сама атмосфера происходящего была революционно пьянящей и вдохновляющей. Из технических докладов до сих пор помню впечатляющие презентации про JavaFX и RTJS — Real-Time Java Specification.
Так уж получилось, что со времен Sun’овских конференций я приходил на конференции по Java только как докладчик, а в качестве участника посещал не совсем профильные для меня Mobius (конференцию по мобильной разработке) и стартовавшую в этом году HolyJS (конференцию по фронтэнду). Тем не менее, отчитав доклад, я стараюсь в остальное время походить и послушать других докладчиков, чтобы, в том числе, оценить их стиль и манеру подавать материал, взять на вооружение какие-то приемы по удержанию внимания аудитории и работе с залом, оформлению слайдов презентации или «живому» кодированию.
Пожалуй, самое сложное для участника конференции — определиться, на какие доклады пойти: обычно одновременно идут несколько докладов, и бывает мучительно сложно отдать предпочтение какому-то одному из них. Выбрать ли мне область, в которой я уже что-то знаю или являюсь специалистом, чтобы почерпнуть для себя те недостающие крупицы информации, которые выведут меня на по-настоящему экспертный уровень? Или пойти на доклад, в названии которого есть куча непонятных слов, чтобы расширить технический горизонт познания? Мне кажется, что организаторам конференций нужно существенно поработать в этом направлении, чтобы активнее помогать участникам выбирать подходящий именно им доклад, и коротких описаний докладов и тегов «runtime», «hardware», «big data» или «microservices» рядом с названиями докладов тут явно недостаточно. Может, делать как в киноиндустрии — короткие трейлеры к докладам, по которым участники смогли бы за одну-две минуты понять, что будет в докладе, увидеть докладчика вживую, оценить его манеру как спикера и, что называется, «примерить» его демонстрационный материал на себя?
JUG.RU: Какой фидбек вы получали после своих выступлений? Речь не столько об оценках докладов, сколько о каких-то интересных случаях: кто-то просился к вам в команду, предлагали свои проекты или давали ценные советы, рекомендации? Может, был какой-то неожиданно негативный фидбек?
Владимир: Самый конструктивный фидбек происходит, как ни странно, до конференции. Я не уверен, в курсе народ или нет, но после подачи заявки на доклад тебя и твой материал тщательно отсматривает программный комитет конференции, руководит которым программный директор конференции Андрей Дмитриев. В состав комитета входят опытные и «мощные» докладчики – ревьюеры, кстати, в этот раз я тоже в него вхожу. Так вот, на определенном этапе делается тестовый прогон доклада, во время и после которого тебя буквально «расстреливают» в упор замечаниями, комментариями и каверзными вопросами твои же собственные коллеги! Тебе становятся сразу понятны как сильные, так и слабые стороны твоего доклада, чего ты не знаешь, а самое главное — решается, нужен вообще твой доклад людям или не нужен, удается ли тебе донести свою главную мысль до аудитории или нет: мнение коллег по ПК в этом смысле прекрасная лакмусовая бумажка. Пользуясь случаем, хочу особенно поблагодарить Володю vladimirsitnikov Ситникова из NetCracker как самого привередливого, жесткого, бескомпромиссного, а потому самого ценного для меня ревьюера программного комитета: если удается договориться с Володей, то уже никакой зал не страшен! =)
Самый приятный фидбек во время конференции — это если удается рассмешить аудиторию. Знаете, конференция — это тяжелая работа не только для докладчиков, но и для участников: надо определиться с докладами, на которые ты идешь, и держать внимание с включенными на полную мощность около часа, ведь ровно столько обычно длится доклад и серия вопросов и ответов. Более того, надо повторить этот цикл 5, 6, а то и 7 раз в день, частенько два дня подряд. Конечно, в программе конференции есть перерывы, вступительное и заключительное выступления, которые обычно не самые хардкорные и скорее призваны быть воодушевляющим и мотивирующим действием, чем изобиловать техническими тонкостями. Но все равно, мне очень жаль участников, и я считаю, что просто обязан вносить элементы шоу в свои выступления, чтобы хоть на пару секунд дать аудитории расслабиться, взбодриться, перезарядить и снова включить .
Еще был такой случай. Я отчитал доклад, ответил на вопросы, поблагодарил аудиторию и склонился над ноутом, чтобы отсоединить его от проектора и сети, а когда, буквально через пару секунд, поднял глаза – слегка онемел от удивления. Вокруг меня было плотное кольцо из ребят с горящими глазами, а самые близкие ко мне при этом еще и шумно дышали. Я вообще не понял, что происходит. Ощущение было такое, как будто еще мгновение, и каждый будет готов наброситься на меня. В каждом взгляде читалось «сейчас порву», и даже стало немного страшно: все это напоминало сцену из фильма или FPS-игры про зомби. И, главное, все столпились, смотрят на меня в упор, ничего не говорят и просто шумно дышат… И я стою, тоже начинаю потихоньку шумно дышать. А куда деваться то? Окружили капитально. Думаю, что-то такое, наверное, ляпнул, поделом мне. Потом включились, дошло что все, наверное, жутко торопились первыми задать какой-то личный вопрос. А чтобы пробраться на сцену за пару секунд, пока я ковырялся с ноутом, надо было весьма быстро пробежаться по залу и взобраться по довольно крутой лестнице, ступенек 5-7, а с физической подготовкой у программистов сами знаете как. Вот и стоят, дыхание переводят, вопрос свой задать хотят, но первым никто быть не хочет, стесняются. Наконец кто-то из «осады» то ли отдышался, то ли набрался храбрости. Прозвучал спасительный типичный вопрос «а вы не пробовали юзать XYZ?», и дальше общение пошло как по маслу. А тут еще и директор конференции Алексей Федоров подоспел и, как у нас говорят, «отбуксировал» меня в дискуссионную зону, чтобы освободить сцену для следующего спикера, после чего мы продолжили общение с народом в более комфортной обстановке: с флипчартом, минералкой, холиваром и блекджеком.
В интервью Владимир говорил о своих докладах на Java-конференциях, если хотите посмотреть, что это такое – приходите на Joker 2016!
А если после прочтения статьи вы решили попробовать свои силы на поприще технических выступлений, мы будем рады видеть ваши заявки на ближайших конференциях, на которых открыт прием докладов (да, это бесплатно, доклады мы не продаем):
- .NET-конференция DotNext;
- JavaScript-конференция HolyJS;
- Конференция по тестированию Гейзенбаг;
- Java-конференция JBreak 2017;
- Java-конференция JPoint 2017;
- Конференция по мобильной разработке Mobius 2017;
Автор: JUG.ru Group
