Интернет завален статьями «как войти в IT и начать писать код», но куда реже говорят о том, как перестать его писать. Что делать, если больше не хочется весь день смотреть в IDE, но и в тимлиды не тянет? Конечно, можно освоить свиноводство, но есть ли сферы, где пригодится уже полученный опыт? Куда можно свернуть «в сторону» от разработки, и какие скиллы для этого понадобятся?
Это похоже на прокачку веток развития персонажа в RPG-игре. Ставишь на ловкость или качаешь силу — получаешь разный результат. Мы выбрали четыре направления, в которых можно качать своего персонажа, и задали вопросы людям, которые уже прошли этими путями:
- DevRel: Барух Садогурский
- Экспертная роль: Евгений Борисов
- Стык IT с другой предметной областью: Дмитрий Нестерук
- Собственная компания: Алексей Федоров
DevRel: Барух Садогурский
+5 к харизме и 10 очков Гриффиндору за качественный техблог. Developer relations — это сфера, которая находится на стыке инжиниринга, коммуникаций и маркетинга. Эта ветка прокачки двигается в сторону публичных выступлений, активной коммуникации с комьюнити и честного кайфа от всего вышеперечисленного.
Про то, как можно прокачать своего персонажа на этом поприще, рассказывает Барух Садогурский (jbaruch) — developer advocate компании JFrog.
— Для начала разберемся с терминами: есть «developer relations», есть «developer advocate», что эти понятия значат и как соотносятся?
— Developer advocate — это одна из двух технических позиций в developer relations. Вторая — это developer relations engineer: там нужно писать код фулл-тайм, и это тоже неплохой вариант пивотнуться, если человек устал от легаси-кода, поддержки и сопровождения, но хочет оставаться внутри технической сферы.
А если хочется вообще поменять сферу деятельности, то developer advocate — хороший вариант. Это человек, который намного больше общается с разработчиками, чем пишет код.
— В случае с разработчиками или сейлзами понятно, какова цель работы. А у «общения с разработчиками», которым занят developer advocate, какая глобальная цель?
— Глобальная цель у нас всех одинаковая: нам нужно в итоге, чтобы наша компания достигла своих целей, чаще всего финансовых или аналогичных. У developer advocate нет цели, например, обязательно взять новый продукт и его впарить. Может быть, надо посидеть с разработчиками и посмотреть, как они используют этот продукт. Иногда это означает сказать, что они купили лишнюю лицензию, и она им не нужна.
Если переходить на тактический уровень, у developer advocate есть две задачи. Это, во-первых, помочь разработчикам решить их проблемы. Желательно сделать это помощью софта нашей компании, но на самом деле совершенно не обязательно — нужно оценить, какие у них реально есть проблемы и как их правильно решать. А во-вторых, собрать как можно больше хорошего реального фидбека от этих разработчиков и принести его обратно организации.
— Твой переход к этой роли был резким («все, больше не хочу столько кодить») или плавным?
— В моем случае это было достаточно резко, потому что ребята, с которыми я работал (как раз фаундеры JFrog), просто предложили мне позицию. Они сказали, что им нужна вот такая функция — «мы даже не знаем, как она толком называется, но вот то, что нужно делать, нам кажется, что тебе подходит, давай». Это было 10 лет назад, названий вроде developer advocate еще никто и не знал.
Но есть и другие примеры. У нас в команде, например, работают люди, которые переходили намного более плавно. Они сначала написали блог-пост, сделали какой-то доклад, и это все параллельно с обычной работой продуктовых разработчиков. А потом мы постепенно все больше задействовали их в DevRel, и в какой-то момент решили к обоюдному удовольствию, что они переходят на фулл-тайм к нам.
— Что нужно для развития в разработке, примерно понятно. А какие вещи нужны, чтобы стать хорошим developer advocate?
— Мне кажется, что основной критерий — желание заниматься этим новым аспектом деятельности. Насколько ты хочешь общаться с разработчиками, насколько тебе это интересно, насколько ты от этого кайфуешь, насколько ты склонен к публичности. Получилось ли, понравилось ли другим, что ты почувствовал после. И вот если это складывается, если тебя прет от таких вещей, то да, это то, что надо.
Все остальное можно набрать с опытом: побороть страх сцены, научиться правильно выстраивать мысли для блога или доклада, набраться скиллов по построению презентации. Единственное, что будет чувствоваться другими людьми — это прет ли тебя с этого или нет. И именно это отличает хорошего developer advocate от плохого.
— Работа developer advocate выглядит близкой маркетингу. Какие скиллы ты начал прокачивать с маркетинговой точки зрения?
— Ты знаешь, мы тогда толком не представляли, что такое DevRel, и тогда это действительно казалось во многом про маркетинг. Не сказать, что я официально прошел маркетинговое обучение, но подумывал о курсах.
А потом, с опытом и знаниями, когда появились книги, коммьюнити вокруг DevRel, и я, и вся индустрия начали более-менее понимать, что маркетинговые скиллы могут даже где-то помешать. Мы разговариваем с разработчиками, у которых достаточно сильная аллергия на классический маркетинг, и чем больше ты пытаешься использовать маркетинговые инструменты, тем хуже будет коммуникация. Поэтому я бы не сказал, что маркетинговые знания — это то, что нужно добавить к разработчику, чтобы получить успешного developer advocate.
— Со скиллами, которые пришлось развивать, мы разобрались. А насколько сейчас сказываются технические скиллы, полученные на этапе работы с кодом?
— Это все же база. Разработчики остаются разработчиками. То, что я умел хорошо, быстро и качественно писать код тогда — это то, что помогает мне хорошо, быстро и качественно писать код сейчас. Плюс я могу, например, читать код, который пишут другие, чтобы правильно помочь кому-то решить свои проблемы. Технический опыт помогает мне давать правильные советы о том, как лучше использовать наш продукт, потому что я понимаю, что делают другие. Кодерский опыт помогает мне писать код для каких-то вещей, которые нужны лично мне. И то, что я пишу код, поддерживает мою репутацию как своего в комьюнити, с которым я общаюсь.
— Как поддерживать технический тонус и не отставать от происходящего в индустрии?
— Есть несколько вариантов. Во-первых, можно всегда заниматься кодом парт-тайм в своей же компании. Допустим, ты выделяешь 20% своего времени и контрибьютишь с командой разработки в продукт в удобном для всех объеме. Это могут быть интеграции, плагины, еще какие-то вещи на периферии.
Второй способ — это pet projects или опенсорс. В этом случае ты помогаешь своей репутации. Это твой опенсорс, его знают, его любят, им пользуются, и ты получаешь очки еще и за это. В обоих случаях это win-win ситуация, и делать это просто нужно.
— Есть ли разница между DevRel-сферой в российском комьюнити и зарубежном?
— Да, есть, и это отличие растет из другого отличия. В России у компаний не всегда есть собственный продукт для разработчиков. За исключением прекрасной компании JetBrains, большинство производителей продуктов для разрабов находятся за границей — в частности, в Штатах. Там моя позиция developer advocate наиболее естественна.
В России DevRel чаще занимается вопросами найма: там developer advocate нужен, чтобы рассказать, какая мы отличная технологическая компания, чтобы к нам пришли хорошие разработчики. Это немного меняет процесс.
— Если кто-то сейчас прочитает наше интервью и решит стать developer advocate, что ты ему посоветуешь?
— Посоветовал бы попробовать. Даже если в компании нет позиции developer advocate, разработчиков часто привлекают к DevRel-активностям, будь то написание текстов для блога, выступления на митапах, конференциях и так далее. Отдел DevRel поможет, дадут ресурсы, поговорят с начальством. Если попрет, понравится, как мы и говорили, то можно делать все больше и больше, и в итоге сказать, что хочешь быть developer advocate фулл-тайм.
Если в компании есть позиция, то можно прямо там. Если в компании есть DevRel, но нет developer advocate, то можно попробовать стать первым. А если ни то, ни другое не работает, то время выходить на рынок. Описанный нами человек, который и техник, и экстраверт, и умеет рассказывать — это редкая птица, которых всегда не хватает. Если ты видишь, что из тебя получится хороший developer advocate, можно прийти ко мне и мы вместе посмотрим, что сегодня есть на рынке.
Экспертная роль: Евгений Борисов
Если сам уже умеешь хорошо — можешь учить других. Формы передачи экспертизы могут быть разными: курсы, тренинги, доклады, книги, консультации и так далее. И вполне можно их сочетать, зачастую один человек занимается сразу многим из этого списка.
Евгений Борисов (EvgenyBorisov) после работы наемным сотрудником ушел на вольные хлеба учить/консультировать других и очень преуспел в этом: сложно найти российского разработчика на фреймворке Spring, не знающего доклад «Spring-потрошитель». Но после фриланса Евгений снова оказался в корпоративном мире. Мы расспросили его и о переходе к жизни «свободного художника», и о возвращении оттуда.
— Когда ты переключился с разработки на тренерство?
— На самом деле, я учил других всегда, и тренерская работа шла параллельно с разработкой. Периодически я проводил внутренние курсы на проектах в компаниях, где работал. Временами компания выдергивала меня на несколько дней с проекта и посылала выступать на какие-то тренинги, конференции и так далее.
— Тогда в какой момент ты решил, что можно переходить на фриланс и заниматься тренерской деятельностью независимо?
— Вообще получилось так, что меня уволили. На работе мне было уже очень скучно, но я там был очень нужен. Параллельно я активно занимался своими фриланс-проектами. Они занимали все больше времени, что не влияло на качество моей работы или сроки, но не нравилось компании. Бюрократия не любит своевольных людей, которые пусть делают правильно, но по-своему, и вообще какие-то непослушные. Я не сильно спорил с ними, мы мирно разошлись.
И тут передо мной встал выбор: либо искать другого дядю, с которым мы можем тоже не сработаться, либо полностью уходить на фриланс. Когда я работал в найме, всегда получалось, что я делаю что-то, с чем не до конца согласен. Поэтому в тот момент я решил, что мне хватит и связей, и опыта для того, чтобы сделать свою подработку постоянным фрилансерским ремеслом. Так оно и вышло. Хотя какой-то четкой и осознанной уверенности в том, что фриланс себя оправдает, у меня не было, иначе я ушел бы сам и раньше.
— Чем тренер в компании будет отличаться от фрилансера?
— Деньгами. В работе на компанию и работе на себя основное различие в том, что в компании у тебя всегда фиксированная гарантированная зарплата. На фрилансе доход, скорее всего, больше, но заметно менее стабильный, и нужно понимать, покроет ли он твои потребности.
— Какие скиллы тебе пришлось качать с переходом в тренерскую деятельность на фулл-тайм? И какие скиллы вообще нужны для успешной работы в качестве коуча?
— Когда я стал фрилансером, тренерство занимало у меня где-то 50% времени. Помимо этого я занимался и консалтингом, и менторингом, и код писал. Я всегда говорил, что хороший тренер должен практиковать сам. Иначе это как врач-теоретик, который в жизни больного пациента не видел, но зато прочитал много книг. Хорошим тренером можно быть, только если ты рассказываешь про вещи, с которым ты лично сталкивался, и можешь привести жизненные примеры.
Если бы у меня уже не было нужных скиллов на достаточном уровне, на развилке я бы не выбрал фриланс. Самый важный навык — это уметь находить общий язык с людьми, потому что люди очень разные. Когда ты преподаешь в школе, твой ученик большую часть своего времени учеником и является. Со взрослыми людьми иначе. Были корпоративные тренинги, где людям уже по 40 лет, они учатся редко и не очень помнят, как это делать. К тому же, у них часто параллельно с тренингом другие дела по работе, задачи, баги в продакшене. Тебе надо уметь со всеми подружиться, ко всем найти подход и понять, какую проблему решает этот конкретный человек, понять его мир, найти какие-то аллегории, чтобы он видел, что ты рассказываешь не абстрактные вещи, а что-то, с чем он сам вчера столкнулся. Тогда он верит тебе.
И конечно, для того, чтобы продавать себя как фрилансера, надо уметь договариваться с людьми, нравиться людям и понимать, что им нужно, давать то, что им нужно и даже больше. Тогда они позовут тебя еще раз и расскажут о тебе соседу.
— Возникает ли при обучении людей проблема, когда учишь привычному тебе, а технологии уходят вперед и отстаешь от них?
— Да, это большая проблема, и ровно поэтому очень сложно быть хорошим тренером долго и во всем, тут надо уметь угадывать тенденции. Во-первых, сам язык постоянно растет и меняется, за этим надо следить. Во-вторых, растет количество фреймворков, и каждый фреймворк еще эволюционирует в процессе. Ты следишь за большим количеством технологий, а они все меняются и меняются, а их все больше и больше. В какой-то момент ты уже не можешь покрыть все и начинаешь концентрироваться на отдельных технологиях. Но ты все равно обязан быть апдейтнутным во всем.
Так что да, быть тренером тяжко. Конечно, на пенсии можно преподавать исторические курсы типа «как правильно писали в объектно-ориентированном стиле в 2005 году», может, на это даже будут ходить. Если будет полезно, можно заняться.
— Ты сейчас работаешь в EPAM. Почему решил вернуться в корпоративный мир?
— Мое знакомство с EPAM примерно совпало с тем периодом, когда я активно работал на фрилансе. В конце 2015 года одна израильская компания — NAYA Technologies — уговорила перейти к ним и создать у них отдел разработки. Это хорошо сочеталось с моей давней мечтой воссоздать ту компанию, откуда вышли и я, и Барух Садогурский, и основатели JFrog. Мне всегда очень нравилось, какие конференции и митапы эта компания устраивала, как прокачивала и отбирала сотрудников.
Два года назад я выступал на конференции в Минске, и в числе зрителей оказался единственный и неповторимый создатель EPAM Аркадий Добкин (удивительно: человек большой начальник, а находит время сидеть на докладах вроде моего). После доклада он подошел и внезапно сказал, что хотел бы купить мою компанию. Мне пришлось объяснить, что NAYA не совсем моя, я в ней просто построил большой отдел и представляю ее на конференциях. Он сказал: «Хорошо, тогда дай телефон того, у кого можно ее купить». Через полтора года переговоров так и получилось, чему я очень рад.
В рамках своей компании мне было тяжело выработать правильный дух взращивания сотрудников. Часто маленькая компания не может позволить себе верную политику, поскольку она экономит деньги, и это сказывается на качестве жизни сотрудников. С EPAM наши финансовые проблемы исчезли, и мне стало намного проще проводить свою политику в этом вопросе, потому что и сам EPAM ее придерживается. В итоге сейчас я по-прежнему очень много и свободно занимаюсь тем, чем я занимался раньше, только еще и нахожусь внутри организации, где мне дают возможности, ресурсы, инструменты, чтобы строить то, что я как фрилансер построить бы не смог.
— Если какой-то разработчик, прочитав этот текст, решит тоже создать свой курс или тренинг, что бы ты ему посоветовал?
— Знаешь, долго думал, отвечать ли на этот вопрос — зачем мне конкурентов плодить, рассказывать, как правильно курсы писать. А потом решил, что поделиться не жалко: и мне не навредит, и мир сделает лучше.
Смотри, какая штука: если каждый тренер будет рассказывать именно то, что он сам пережил, осознал и выродил, то он будет уникальным и классным, у него будут последователи, которые захотят у него поучиться. Конечно, при условии, что то, что он пережил-осознал-выродил — это какие-то полезные вещи.
Некоторые говорят, мол, не смог писать код — пошел командовать разработчиками, не смог командовать разработчиками — пошел командовать менеджерами. Вот тут такое не работает. Если ты как программист не смог набрать опыта и осознать его, то не преподавай. Я никогда не преподаю что-то, что я сам параллельно изучаю. Ладно, иногда так бывает, но во-первых, у меня уже достаточно опыта, чтобы на лету это через себя ретранслировать, а во-вторых, совсем незнакомые вещи с листа я не преподаю.
Вся суть в твоем пути до вывода. Вот бьюсь я с каким-нибудь фреймворком и никак не могу понять его концепцию. А потом в какой-то момент приходит озарение, и я понимаю, что ах вот как надо было на это посмотреть. Из этого можно сделать отличный тренинг. В основу курса ты заложишь всю эту дорогу, только в ускоренном виде, и человек, придя к такому же пониманию в конце, выйдет и скажет «я в процессе курса понял, что я нифига не понимаю, а в конце у меня было вот такое озарение!». И про этот катарсис он и расскажет своим друзьям и начальникам, и к тебе придут еще раз.
Иначе лучше просто не преподавать, потому что это загрязняет рынок ненужными курсами, когда человек книжку купил, прочитал и пробует по ней тренинг сделать. Самые хорошие тренинги — это те, которые именно написаны, а не переписаны с какой-то книги или сфабрикованы из нескольких материалов. Это должно быть авторское творение, тогда это будет работать.
Стык IT с другой предметной областью: Дмитрий Нестерук
Когда потолок прокачки в одной ветке виден еще на первых уровнях, поворот может открыть секретную локацию с бесконечными перспективами. Отойти от IT не всегда означает полностью отказаться от кода — иногда это про углубление в емкую предметную область, где код тоже нужен, но меняются и парадигма, и горизонты.
Понятно, что такие области могут быть разными, и все тут не опишешь, рассмотрим для примера одну. Про вариант на стыке программирования, статистики и финансов рассказывает Дмитрий Нестерук (mezastel) — квант, алготрейдер и финансовый математик.
— Первое, что выдает о тебе Гугл — тайтл «квант». Не всем понятно, о чем это. Объясни на пальцах, чем ты занимаешься?
— Для начала поясню этот термин. «Квант» расшифровывается как «quantitative analyst»: кто-то, кто занимается анализом численных данных (и здесь необязательно подразумевается финансовая область). В более широком смысле это data science, исследование данных, которые могут генерироваться корпорациями, органами управления государством или еще кем-то. Квант — это человек, который получает данные с рынков и бирж, занимается тем, что анализирует их, вырабатывает какие-то стратегии. А потом, возможно, даже пишет непосредственно алгоритмы и торговых роботов, и все это с целью извлечения прибыли.
Поэтому среди инструментов кванта — система компьютерной алгебры, самописные инструменты, некоторые коробочные решения, непосредственно данные для анализа, которые предоставляют биржи. И в конечном счете, это все еще большое количество программирования: где-то 50% все равно уходит на программистскую деятельность, пускай и немного в другом ключе. Здесь первоочередная цель — сделать что-то работающее, что принесет доход.
— Если очень просто: ты пишешь условный алгоритм, который анализирует данные на рынке и выступает в качестве поддержки при принятии решения о покупке или продаже активов?
— Если упрощать, то да.
— У тебя есть заказчик, или ты это делаешь для себя?
— Я использую собственные средства и никогда ничего подобного не продавал. Это чисто мой личный кошелек, который работает на меня. У меня даже нет никаких партнеров. Изначально в эту тему меня пнули мои знакомые, но в конечном счете я ушел в полностью свободное плаванье. Сейчас мне комфортно одному, и я не готов делиться своими подходами и инфраструктурой. Хотя у большинства квантов иначе, обычно это наемные сотрудники.
— Каким образом ты пришел в финансовую сферу?
— Формально интерес к этой сфере был очень давно. Изначально я занимался произвольным анализом, когда на рынке еще только начали популяризировать всякие Forex-кухни и другие подобные вещи. Меня это заинтересовало как некая абстрактная деятельность, которая потом переросла в более серьезное хобби.
Мне всегда нравилась эластичность рынков. Потому что, будучи разработчиком, или менеджером, или даже CEO IT-компании, ты все равно знаешь, что существует потолок, некий лимит, выше которого не прыгнуть. И у меня всегда был вопрос, как найти те рынки, где перспективы роста безграничны. Естественно, что самый большой рынок — это «международный финансовый рынок». При условии, что ты делаешь все верно, перспективы на этом рынке максимальные. В основном я исходил из попытки максимизировать доход на единицу времени: с точки зрения финансовых соображений IT и работа с почасовой оплатой быстро потеряли для меня привлекательность. Переход в финансовый сектор был естественной прогрессией.
— Насколько получилось понять по беглому изучению твоего блога, кванты работают с достаточно узким кругом технологий, верно?
— Да. Поскольку нам не нужна прикладная среда, мы обычно выбираем что-то, что работает достаточно хорошо, и фокусируемся на производительности. Данных очень много, обрабатывать их надо очень быстро, поэтому очень много времени уходит на разные оптимизации, которые работают на ускорение процессов и обход конкурентов.
— А есть все равно какая-то необходимость быть в курсе новых технологий?
— То, что основным языком программирования в финансовой инженерии является С++ — это хороший такой намек на то, что тут никто никуда не торопится. Какой-то прогресс с точки зрения железа есть, но мы не стараемся быть на острие и использовать экспериментальные языки. Это консервативная сфера, где суть в том, что у тебя есть какие-то рыночные процессы, и тебе нужно их анализировать и работать с ними. Адаптация в основном происходит к рынку, а углубленности в технологии и попытки бежать впереди всех в этом плане нет.
— Какие скиллы тебе понадобилось прокачивать для перехода в эту сферу?
— Со стороны математики пришлось поднимать все университетские знания по матстатистике и теории вероятностей, потом постепенно воскрешать навыки стохастики и сложного моделирования, которое используется при анализе численных данных. Пришлось вспомнить базу, связанную с обычным математическим анализом и теорией меры, через которую написаны большинство книг по теме. Дальше стандартно: стохастические дифференциальные уравнения и все, что с этим связано. Плюс параллельная реальность, где фигурируют численные методы, Монте-Карло методы и, как апофеоз всего, современные методы, связанные с машинным обучением и торговлей с помощью «черного ящика».
Со стороны программирования усилий потребовалось меньше, но пришлось поднять навыки, связанные с высокопроизводительными вычислениями. Очень быстро стало понятно, что у меня нет никакой возможности анализировать крупные объемы финансовых данных на домашнем компьютере. Пришлось искать какое-то место, где можно анализировать огромные объемы и использовать огромные вычислительные ресурсы. К счастью, мне повезло — через свой университет я такое место нашел и смог амортизировать те механизмы, которые там были. Навыки программирования на С++ тоже пришлось покопать, как и работу с архитектурными проблемами. В контексте высокопроизводительных вычислений были еще две темы, которые меня очень заинтересовали: GPGPU (вычисления на графических картах) и ПЛИСы.
— В финансовой сфере много фундаментальной матчасти с точки зрения функционирования рынков. Как ты нарабатывал эту базу?
— В первую очередь нужно чисто механистически понимать, как мы взаимодействуем с биржей: как заявки выставляются, как сдвигаются, сводятся в сделки. Это можно изучать с помощью каких-то визуальных инструментов, а потом уже переходить на программирование и работу с API конкретной биржи.
Здесь нужно учитывать, что помимо биржи, которая может подсунуть нам ошибки, существуют еще и более привилегированные участники. У них может быть более близкое к самой бирже железо или какие-то специальные условия, но со всем этим нужно работать и нужно понимать, что у разных участников будет разное поведение. Это тоже один из методов познания: мы просто смотрим на то, что происходит на тех или иных инструментах, и пытаемся понять, кто там участвует и в какой роли. Такие наблюдения хоть и дают нам довольно абстрактное понимание, но помогают выработать интуицию, которая пригодится при автоматизации.
Если мы говорим про инструменты, то тут, естественно, нужно грызть гранит науки: читать про то, какие инструменты существуют, как производятся различные расчеты по этим инструментам или по совокупности, т.е. портфелю, инструментов. Нужно понимать, что делает биржа, и потом уже искать, какие у нее есть неэффективности и допуски, которыми можно манипулировать, чтобы положить свою копеечку в карман.
— Если какой-то разработчик решит перейти в финансовую математику и алготрейдинг, что бы ты ему посоветовал? С чего начать?
— Тут нужно изучать сразу три разные дисциплины. Первая — это математика, математическая статистика, теория вероятностей и смежные с этим дисциплины, с целью выйти на более сложные конструкции вроде стохастики, которые используются в современном финансовом мире. Здесь достаточно понятная прогрессия. Но все это нужно еще разбавлять книгами, связанными непосредственно с финансами. В качестве базовых книг по финансовой математике я рекомендую читать Халла «Options futures and other derivatives» или Вилмотта «Quantitative Finance» (PWIQF).
Что касается чисто финансовой части, то здесь нужно прежде всего понимать инструменты и рынки, на которых они торгуются, нужно понимать, какие есть участники рынка и для чего они этими инструментами оперируют. Здесь тоже довольно понятная конъюнктура: будет часть людей, которым, например, понравятся экономика и фундаментальный анализ. Однако я воспринимаю quantitative finance как чисто математическую область, поэтому считаю, что нужно знать некий базовый минимум, при этом не вдаваясь в такие вещи, как чтение отчетности компаний или что-то в этом духе.
Ну и третья часть связана непосредственно с программированием. Если программистские навыки уже есть, то нужно оттачивать их именно с расчетом на биржу. Я бы сразу рекомендовал открывать тестовые счета, подключать API и начинать торговать, пусть даже на старте это будет paper trading. Нужно набивать руку на написание автоматических торговых систем. Человек с навыками программирования может неплохо амортизировать теории и превращать их в стратегии, которые торгуются как бы сами по себе, а сам квант может в процессе их подкручивать. У меня в блоге есть большой список книг, которые я рекомендую как первый шаг для того, чтобы как-то понять эту область. Естественно, самое важное во всем этом — это практика. Нужно открывать счета, изучать рынки и пытаться понять, нравится тебе все это или нет.
Собственная компания: Алексей Федоров
Прокачаться в босса игры может звучать заманчивее всего, но этот путь несет в себе и наибольшее количество рисков. И именно в них оказывается главная разница между владельцем компании и наемным менеджером.
Чтобы расспросить фаундера, мы не стали далеко ходить и обратились к нашему собственному основателю — Алексею Федорову (23derevo). До того, как создать JUG Ru Group и делать большие IT-конференции, он работал в петербургском центре разработки Oracle.
— Как произошел переход от разработки к организации конференций?
— В Oracle я занимался небольшой частью платформы Java, и это отдельный от прикладной разработки мир, довольно специфический. Попадая в этот мир, ты выпадаешь из программистского мейнстрима, и с годами есть риск серьезно отстать от рынка. Чтобы быть в курсе происходящего в разных областях IT-отрасли, я начал делать ежемесячные митапы Java User Group, где вытаскивал каких-то интересных людей из индустрии: они делали доклады, на это все приходили десятки или сотни людей. Это была интересная движуха, которая давала мне связь с внешним миром.
Тогда большие конференции в России делали несколько крупных компаний и вендоры отдельных технологий. И в какой-то момент Oracle, которые делали конференции по Java, отказались от них. Мы к тому моменту уже кое-как научились делать ивенты, и решили замахнуться на нечто большее — сделать конференцию. Я поговорил с партнерами, спонсорами, заказчиками, и мы пришли к выводу, что можно попробовать.
А где-то к середине 2014 года возникла ситуация, когда мы делали уже несколько конференций в год. И тут пришлось выбирать: оставлять это в качестве хобби или развивать дальше, а значит, уходить с основной работы. Важную роль в моем решении сыграло два момента. Первый — я не карьерист: линейный карьерный рост в Oracle или другой компании меня не особо интересовали. Второй — делать конференции у меня получалось хорошо. Мы получали быстрый, живой и часто положительный фидбек от спикеров и участников, чего мне не всегда хватало на работе. Все просто: ты что-то сделал хорошо, и люди тебе за это благодарны.
Как сделать так, чтобы уделять своему хобби больше времени? Превратить его в профессию. Для меня это был не самый сложный шаг, потому что у меня не было никаких рисков. У меня не было серьезных обязательств вроде ипотеки, был опыт в организации конференций, были контакты в среде и был, если что, путь назад. И была страховка: Антон Федчин из Одноклассников предложил мне сотрудничать с ними в области бренда работодателя. В Одноклассниках я провел около двух лет, работал и как контрактор, и как сотрудник Mail.Ru Group, совмещая эту деятельность с конференциями.
— То есть в конференциях ты тогда для себя видел больше перспективы?
— Да. Oracle образца 2010-х годов — это мощнейший центр технологических компетенций мирового уровня. Я каждый день пил кофе с очень крутыми техническими специалистами: глядя на них, понимаешь, что тебе до их уровня безостановочно пахать лет пять. Но за это время они уйдут еще сильнее вперед, и тебе понадобится еще пять лет, чтобы… Ну и так далее. Плюс я не такой умный, как эти ребята, поэтому в той гонке я был обречен. Я довольно объективно оценивал себя: я не был топовым инженером, был просто приличным. Вертикальный карьерный рост мне был неинтересен, а горизонтальный был интересен, но время я упустил. Поэтому возник тупик, из которого я вышел, сменив поле деятельности.
— Насколько в новом поле деятельности оказался полезен девелоперский опыт?
— В момент перехода девелоперский опыт помогал, потому что у меня было понимание проблем индустрии, знание предметной области, знакомство с нужными экспертами. На первые конференции в качестве спикеров я просто звал своих коллег и друзей. Я мог бы делать конференции по другим темам — например, мне всегда была интересна журналистика. Но на меня бы посмотрели как на идиота: это было бы долго, и плохо, и мимо, и непонятно, чью потребность я бы решал. Проблемы программистов мне были хотя бы понятны.
— С момента перехода ситуация изменилась: у JUG Ru Group уже много конференций, у каждой свой программный комитет, больше не нужно самому звать спикеров. Помогает ли девелоперский опыт при таком масштабе?
— Да, помогает, и очень сильно.
Во-первых, сейчас я сам как разработчик отвечаю за некоторые айтишные куски в компании. Во-вторых, разработка софта — это еще и инженерия. Я переложил свое инженерное образование и инженерный опыт работы на организацию и построение процессов внутри компании. Многие инструменты и подходы я взял из IT — например, JIRA и Confluence, ретроспективы и стендапы, подход к организации инфраструктуры офиса и рабочих мест и многое другое.
— Помимо девелоперского, надо было разбираться в бизнесовых вещах. Насколько это было сложно?
— Я столкнулся с этим в 2014 году, когда кругом было уже очень много книг. Как разработчик, я в свое время развивался за счет чтения профессиональной литературы, и это очень ценный навык. Плюс уже был опыт организации мероприятий: на момент, когда я ушел из Oracle, мы уже сделали несколько конференций.
Позже я познакомился с несколькими людьми, которые помогли мне разложить по полкам, что такое бизнес и маркетинг. Я ходил на курсы, читал книги и таким самообразованием это закрывал — благо, навык разбора теории по косточкам у меня был.
— И наемный менеджер, и владелец компании занимаются управлением людьми и построением процессов. А в чем принципиальные различия?
— Я не вижу принципиальной разницы, кроме работы с рисками. В случае, когда ты наемный менеджер, цена ошибки очень низкая. Если меня, как наемного работника, уволили — я пойду на горячий айтишный рынок, найду другую компанию, устроюсь на работу. А в собственном бизнесе риски куда выше (что, например, показал COVID). Поэтому принципиальная разница — это готовность предпринимателя брать на себя риски.
Тезис о том, что в собственном бизнесе ты сам себе хозяин, на мой взгляд, довольно ущербный. Твои хозяева в бизнесе — клиенты. Один босс, который был у тебя, когда ты работал в найме, заменяется на множество клиентов, у которых разные мнения и цели, а тебе нужно связать свое видение с их и удовлетворить хотя бы часть, чтобы они заплатили тебе, а ты — команде.
— Если какой-то разработчик после этого текста захочет создать свою компанию, что бы ты ему бы посоветовал?
— Быть смелее и попробовать проработать риски. Подумай, как ты во время этого пивота вообще будешь жить. Есть риск, что твой бизнес не будет сразу зарабатывать — значит, надо накопить какую-то финансовую подушку, чтобы ты мог на несколько месяцев посвятить себя новому делу. Есть риск, что твои друзья-семья-близкие не одобрят твой переход — значит, тут тоже требуется некоторая работа. В конце концов, бизнес может просто не взлететь. К этому нужно быть готовым.
Переходный процесс — это всегда самый тяжелый период для для любой системы, в том числе, для человека. Когда ты делаешь пивот, возникает точка, к которой ты приходишь и говоришь: окей, я теперь пойду направо. И тут, как в известной сказке, можно и коня потерять, и голову, и все остальное. Нужно четко это понимать, иметь план и усердно трудиться. И быть готовым к любому развитию событий.
Отойти от IT: куда расти, когда код ради кода больше не интересен
Интернет завален статьями «как войти в IT и начать писать код», но куда реже говорят о том, как перестать его писать. Что делать, если больше не хочется весь день смотреть в IDE, но и в тимлиды не...
habr.com