Как и когда учить новое? Главная > Статьи > Как и когда учить новое? Resume Driven Development (RDD) нам в помощь

Как и когда учить новое? Resume Driven Development (RDD) нам в помощь

Лучшее враг хорошему:
cработавшая подушка безопасности разорвала «Оку» пополам.
«Бомонд», КВН.
14 октября 2019 года

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

 

 


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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Итак:

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

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

   Эти знания мне позже пригодились как на практике (потому что многие из них были фундаментальными), так и на «собесах», где я поражал интервьюеров знаниями о том, как работают «потроха» springcloud-штук.

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

   Мы рассмотрели, как можно копнуть вглубь своей экспертизы, внедряя новые вещи в существующее решение или разрабатывая что-то с нуля. Теперь поговорим о том, как расширить экспертизу и стать 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.

Автор: rozho)))k.

 

 

Ещё материалы по этой теме:


⇓ 

Поделись ссылкой на Seoded.ru с друзьями, знакомыми и собеседниками в соцсетях и на форумах! А сам сайт добавь в закладки! Так победим.

Поделиться ссылкой на эту страницу в:

Полезные ссылки:

Виды интернет-магазинов Хостинги для сайта бесплатно

 


основан в 2008 г. © Все права на материалы сайта Seoded.ru принадлежат Алексею Вострову.
Копирование (полное или частичное) любых материалов сайта возможно только с разрешения автора и при указании ссылки на источник.
Ослушавшихся находит и забирает Бабайка!