Один из частых вопросов у любого инженера (и не только) — как и когда учить новое? Технологии (по крайней мере внешне) обновляются довольно быстро, количество инструментов, которыми необходимо владеть для ежедневной работы растёт и нужно все это как-то изучать и применять.

Для решения этой проблемы и была придумана методология RDD она же Resume Driven Development.

Для начала ответим на вопрос “как?”, он же “форма обучения”. Я считаю, что всё нужно изучать на реальных и нужных кому-то проектах (e.g. за которые вы получите деньги — зарплату или фиксированную сумму), и чем более они являются реальными и нужными, тем быстрее и качественнее будет идти обучение. Не стоит резать пациента, не умея держать скальпель в руках и нужно соизмерять риски, но сделаем предположение, что совсем новичка не пустят в разработку критичных вещей.

“Когда?” — раз реальные проекты — значит на реальной работе. Я считаю что неэффективно тратить своё личное время на изучение новых штук, когда у вас есть возможность делать это на работе.

Для того чтобы эффективно заниматься RDD нужно выполнить несколько пререквизитов:

  • иметь кредит доверия у того, кто решает, что делать на проекте
  • своими действиями принести проекту хоть какую-то пользу

Кредит доверия вы получаете в двух случаях: когда вас только взяли на новое место работы или когда вы достаточно долго проработали на текущем месте и каким-то образом зарекомендовали себя.

Понятное дело что явно неопытному инженеру никто не доверит добавлять рисков в проект, так же как и на работу где совершенно точно прямо сейчас нужна некая экспертиза, вас просто не возьмут.

С другой стороны, если вас отсобеседовали и взяли на проект где есть вещи, которые вам не знакомы, значит полностью соизмеряют риски которые связаны с этим.

Приносите пользу вы решая какие-то конкретные проблемы бизнеса. Просто так новая рюшка никому не интересна, она должна закрывать какую-то боль.

Дальше рассмотрим конкретные сценарии и примеры как я занимался RDD, и как учить новые вещи не в личное время а в рабочее.

Углубление экспертизы через изменение старого

В далёком 2010 году я зарегался на линкедине и буквально сразу же меня позвали на собес на Java позицию в Люксофт. Если не ошибаюсь, то был мой самый первый собес и спрашивали меня там про Spring и Hibernate. Специфика работы места, где я тогда работал заключалась в том, что разработчики в основном использовали самописные фреймворки, в том числе для доступа к базе и DI. Естественно, ни спринга ни хибера я не знал, потому что у меня на работе их не было, о чем немедленно сообщил интервьюеру. Однако в конце беседы оказалось что я им понравился и они готовы меня брать, а недостающее я подучу по ходу дела. Мне сделали оффер если я не ошибаюсь на 1400$, который я принес и положил руководству на стол. Руководство почесалось и сделало контроффер в 1500$ ну я и остался.

Однако мысли о спринге меня не покидали, беспокоило, что есть какая-то штука, которая всем нужна, но совершенно мне непонятна и нужно было что-то с этим делать.

Шанс представился очень быстро — буквально через несколько месяцев я попал на проект с бравыми ребятами из ThoughtWorks и там мне в популярной форме объяснили что такое TDD и IoC. Однако в нашей платформе не было возможности вообще никак это делать, вот просто потому что не было. Кроме того, по неизвестной мне причине, бытовало мнение что 3rd-party библиотеки вообще сложно протащить в из-за лицензионных ограничений.

Но я это все проигнорировал, и в рабочее и совсем немного в нерабочее время сделал прототип внедрения Spring в нашу платформу. Причем он там реально был нужен, потому что проект требовал возможности переопределять платформенную логику и DI отлично решал эту проблему попутно добавляя разных полезностей вроде тестабельности кода.

  • у меня был кредит доверия, потому что я тогда считался сеньеролидом
  • внедрение новой технологии однозначно решало определённую (причем довольно серьезную) проблему
  • я смог представить это своему руководству как “незначительное улучшение которое позволит нам внедрять проекты быстрее”, хотя двумя годами ранее мой тимлид не смог продать ту же самую идею тому же самому начальству

Потом самостоятельно я сделал запрос в отдел который занимался опенсорс лицензиями и получил добро на добавление зависимости на спринг. Что интересно, оказалось что его уже использовали ребята из другого компонента, но не так, как нам нужно было.

Как показали дальнейшие события, я оказался тем человеком, который катализировал использование Spring по всей компании. Дальше на него начали переползать другие отделы. До сих пор считаю это своим самым значительным достижением с точки зрения импакта на инжиниринг.

После этого на собесах я уже не терялся на вопросах по IoC, а рассказывал даже больше чем нужно, потому что не пришел на проект где было все готовое, а осознал конкретную проблему, которую решает фреймворк и применил его для этого.

Углубление экспертизы через разработку нового

Другая история произошла уже в 2014 году. Помимо известных событий, тогда же я посетил конференцию JavaDay. То было как раз время хайпа по микросервисам и там я попал на доклад, где показывали как работает решение на Spring Cloud Netflix, сервис дискавери, circuit breakers все дела. Я этим докладом очень сильно вдохновился и прям прозрел насколько (как мне казалось тогда) крутые вещи происходят в мире в то время когда я пилю JavaEE монолиты. На работе как раз тогда начинались всякие облачные инициативы и я вписался в архитектурный комитет где мы рисовали диаграмки и занимались другой непродуктивной деятельностью.

Однако довольно быстро я сообразил что просто так что-нибудь поделать, реализовать тут мне никто не даст, и с этим надо было что-то решать. Поэтому я пошел на поиски работы где будут облака и микросервисы. Таковая очень быстро нашлась и меня взяли первым инженером в перспективный стартап.

Когда я туда пришел, то не знал, ни как делаются микросервисы в продакшене, ни как работают облака и имел об этом всём только теоретическое представление. Но CTO дал мне достаточный кредит доверия, на который я разработал прототип, защитил его, и дальше команда на этой базе делала непосредственно продукт. Тот же CTO одним из условий поставил использование NoSQL решений, так что тут еще эту тему пришлось плотно изучить (самый топчик был когда для хранения информации об отложенных задачах использовали записи в S3 бакете который потом читался спарком. Полная дичь. До прода так и не дошло). Все это потом успешно было запущено в продакшн и живет до сих пор в более-менее неизменном виде.

Итак,

  • у меня был кредит доверия от руководства, несмотря на то, что я не имел практического опыта с технологиями, которые требовались
  • руководство понимало риски и соизмеряло их с потенциальной пользой, поэтому и дало возможность мне и команде обучиться фактически за их время

Таким образом я на работе изучил кучу интересных штук в рамках своей основной экспертизы (Java) и потом еще и запустил это всё в прод.

Эти знания мне позже пригодились как в принципе, потому что многие из них были фундаментальными, так и на собесах где я ловко поражал интервьюеров знаниями как работают потроха Spring Cloud штук.

Расширение экспертизы через разработку нового

Мы рассмотрели как можно копнуть вглубь своей экспертизы внедряя новые вещи в существующее решение, или разрабатывая что-то с нуля. Теперь поговорим о том, как расширить экспертизу и стать T-специалистом.

Под расширением я понимаю наработку опыта в смежных с вашей областях. Для бекенд разработчика (коим я являюсь) это разработка бекенда на другом языке, фронтенд, инфраструктурные вещи (девопс), автоматизация тестирования, data science и так далее, продолжите сами.

Тут есть несколько вариантов развития:

Заполнение постоянно существующей нехватки или дефицита экспертизы

Возвращаясь к стартапу, где я работал, помимо собственно разработки бекенда, нужно было всё это каким-то образом деплоить. Я (а также мой CTO) решил что мне это интересно и плотно засел за CloudFormation докеры шмокеры облака vpc самопальный дженкинс с сотнями баш скриптов и другие инфраструктурные вещи. У меня получилось относительно неплохо, и со временем я стал все больше заниматься инфраструктурой и инструментарием вокруг этого, и все меньше разработкой продукта. Таким образом я заполнил существующую позицию на которую не было человека (девопса), при этом не отрывался от своей основной работы далеко (бекенд) и решил проблему бизнеса (построил CI/CD).

Продолжая историю, когда я уже отошёл от дел в этом стартапе, то другой коллега, сходив на конференцию где был доклад по Terraform, перепилил CFN в Terrafrom, переписал и упорядочил bash деплоймент скрипты, которые я сделал, и переписал внутреннюю тулзу для деплоя в продакшн (первую версию которой я сделал на node.js) на Go. Всё стало сильно лучше и потом уже я ретроспективно учил Terraform по его наработкам. Парень знает толк в RDD, берите с него пример. Как ему удалось это сделать? У него был кредит доверия :) А у бизнеса — время на реализацию этих штук.

Заполнение временной нехватки

Часто бывает так что на некоторых участках работ загруженность значительно выше, нежели на других. Например, весь бекенд уже написали и сейчас пилят фронтенд. Или наоборот. Такие моменты нужно ловить и пробовать расширяться в то время когда у вас спокойный период, а у других — напряжный. Например, вы можете помочь коллегам-фронтендерам с небольшими фиксами или некритичными доработками, пока основные силы будут брошены на более серьезные вещи. Это может происходить по вашей или по менеджерской инициативе, и я советую этим пользоваться даже если вначале не хочется.

Традиционно разработчики предпочитают засовывать голову в песок и говорить “не, это фронтенд (или бекенд), я этим заниматься не буду и не хочу, мне комфортно в моей песочнице”. Конечно можно и так делать, но если есть возможность изучить что-то новое а в идеальном случае еще и получить небольшое менторство, то почему бы и нет? Вы ничем не рискуете, и сможете как только так сразу вернуться к своим делам, команда тоже ничем не рискует потому что очевидно не будет давать вам критичные вещи, все в профите.

Расширение экспертизы через разработку прототипов и RnD проектов

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

В этом месте на сцене должны появиться вы.

Однажды ко мне попал проект от сумасшедшего — писатель собирался издать книгу, на страницах которой были бы размещены специальные изображения, при наведении на которые камеры смартфона, нужно было проигрывать аудио или видозаписи. Такой себе расширенный экспириенс. Собственно технически задача состояла в том что у нас был набор эталонных изображений, которые нужно было сопоставлять с тем, что поступает от камеры. Дело осложнялось тем, что всё должно было работать оффлайн и на двух платформах (android/ios)

Для этих целей позвали меня и пришлось быстро освоить OpenCV, потом запихнуть это в мобилы, потом долго вручную подбирать коэффициенты/алгоритмы и экспериментировать с размерами эталонных изображений и того что приходит с камеры.

Нам удалось сделать неплохую точность распознавания, но все равно она местами сбоила из-за похожести эталонных изображений (два почти одинаковых рояля под разными углами например).

Два года спустя этот опыт пригодился мне когда уже другой заказчик пришел с вопросом можем ли мы делать сравнение изображений. Там уже была возможность отправлять данные на сервер, я опять вооружился питоном и OpenCV и соорудил примерно то же самое, что и на первом проекте.

К сожалению, и в этот раз нам дали библиотеку невероятно похожих изображений (потому что их делали без учёта технических требований а просто надизайнили как есть) и точность распознавания получилась очень низкая — 60% или около того и это еще с костылями по сравнению цветов и формы а не только по фичам которые вытащил SIFT.

Думаю, вы уловили суть — на пустом месте мне пришлось быстро вникнуть в совершенно новую для меня технологию, попутно подучить новый язык и реализовать интересную штуку.

  • у меня был кредит доверия от руководства в первом случае и от заказчика во втором
  • задача была совершенно реальная и за нее мне даже заплатили денег

Про OpenCV только один пример, самый яркий, когда я разбирался вообще с чем-то совершенно новым, непредсказуемым и отличным от моей основной экспертизы. Таким образом я постоянно изучаю новые вещи — ищу возможности где можно применить технологию, сделать прототип и получить из этого пользу в виде новых знаний.

Итоги

Подытожим — как и когда учить новые штуки, применять современные технологии и при этом нормально жить не выжигая глаза кодом 24х7:

  • искать работу где применяются интересные вам вещи
  • искать возможности улучшить проект, над которым вы работаете с технической стороны так, чтобы это принесло пользу бизнесу
  • смотреть за тем, что происходит вокруг и по возможности брать некритичные участки работы из смежных областей
  • закрывать дефицит экспертизы, если есть такая необходимость
  • не зарывать голову в песок и не бояться пробовать новое. В крайнем случае, если не получается или не нравится то всегда можно отвалиться и сделать лапки (главное не злоупотреблять а то потеряете кредит доверия)

Для того чтобы у вас была возможность всё это делать, нужно всего ничего — быть норм типом с головой на плечах а дальше:

  • получить кредит доверия
  • грамотно оценивать риски vs польза vs критичность. Плохо будет, если бизнес вам доверится, а вы не вывезете штуку которую обещали сделать, потому что у вас в этом нет глубокой экспертизы или вы наткнулись на неожиданные проблемы.

Такие возможности открываются не сразу и не везде, но я уверен что у каждого на проекте (если это не какой-то махровый энтерпрайз на саппорте) есть возможности двигаться как вглубь так и вширь.

Совершенно необязательно учить новый стек дома по вечерам, нужно просто найти работу, которая позволит это делать днём. Если я смог найти такую работу (и я сейчас говорю про найм, а не про консалтинг), значит и вы сможете.

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

Иные скажут — если ты не погружаешься глубоко в какую-то область и работаешь вширь, то это и незачем делать — зачем заниматься девопсом если ты сам не планируешь дальше копать в эту сторон? Ну, я так скажу — во-первых, я за тотальное расширение, E-shape и супер-фуллстечность, когда один в поле воин, во-вторых, как понять что тебе что-то нравится или не нравится если не попробовал, а в-третьих, даже поверхностное знание соседних областей на порядки упрощает коммуникацию ведь ты начинаешь говорить с коллегами на одном языке и дальше, с широкой экспертизой уже смело открываешь себе дверь ногой в архитекторы и CTO.