Я, девелопер
[Об авторе: Павел Веллер — CTO, Digital Engagement Practice в EPAM Systems. Практически 20 лет опыта в разработке ПО и продуктов с использованием Java, С#, Ruby, JavaScript и др. (из них около 14 лет в EPAM). Ведет собственный блог www.pveller.com]
В октябре 2017 года в Будапеште состоялась конференция EPAM SEC 2017: Engineering Next, посвященная будущему технологий и новому поколению инженерных решений. На ней я поделился своим видением того, что значит быть Full Stack девелопером в наши дни и почему практический опыт — это ключ к тому, чтобы стать настоящим экспертом в области мультитехнологий. Видео выступления можно найти по ссылке. И специально для читателей DOU материал по мотивам моего выступления.
Кто такой Full Stack девелопер
Однажды на конференции в Денвере я услышал правильный вопрос: «Вы позиционируете себя как Full Stack девелопер. А когда вы в последний раз писали device driver?». Смысл заключается в том, что, поскольку стек «глубок», мы делегируем множество задач, а тот стек, с которым большинство из нас работает ежедневно, — лишь верхушка айсберга. Как большинство из нас изобразит архитектуру проекта? Скорее всего, мы получим примерно такую картину: Presentation tier — Business logic tier — Database tier. Другая версия: React JS/Native/VR, — REST API’s в микросервисах — Polyglot persistence. Так более модно, чем классическая трехуровневая архитектура, но это все равно лишь вершина айсберга.
Итак, быть Full Stack девелопером не означает быть экспертом во всем этом. Готов поспорить и аргументированно доказать, что ни у вас, ни у меня это не получится. Возьмем HTML. Казалось бы, что может быть проще? Например, на epam.com я насчитал не более 15 тегов (современный HTML — это одни <div>). Быть экспертом в таком количестве — не сложно. Но как насчет HTML5? Service workers, Web workers, WebSockets, WebRTC, скоро — WebUSB — вот неполный перечень того, что нужно знать, чтобы называться экспертом в новой версии языка. Многие ли могут похвастаться идеальными знаниями всего перечисленного? Лично я не могу.
Другой пример — CSS. 15 лет назад его даже не причисляли к языкам программирования, а работы (и зарплаты) у фронтенд-разработчиков, скорее всего, было меньше, чем у Java-девелоперов. Как обстоят дела сейчас, когда к CSS прибавилась цифра 3 (а фактически 4)? Мы уже не пишем вручную, мы компилируем. Спецификация разбита на ряд модулей, проходящих собственные этапы сертификации. Модули для переходов, трансформации, анимации, два grid layout, отдельный модуль для голосового браузера. Если кто-либо хочет называться экспертом в CSS, он должен быть экспертом во всех этих составляющих. Третий пример — JavaScript, который полностью изменился в течение всего лишь последних двух-трех лет.
Так реально ли быть экспертом и в JavaScript, и в CSS, и в HTML? И кстати, мы говорим только о «вершине верхушки» айсберга. Как насчет фреймворков — Angular 1/2/3/4, React, Vue, Ember, Aurelia? И хорошо, если ваш сервер на Java, а если нет? Это может быть .NET, .NET Core, C#, F#, Erlang, Elixir, Ruby, Golang и так далее — вариантов множество. Можете ли вы быть экспертами во всем? А потом еще базы данных, реляционные и не очень.
Поэтому я определяю Full Stack девелопера как специалиста, который имеет собственные предпочтения и работает с тем языком программирования и стеком технологий, который он предпочитает в данный конкретный момент. И кроме того, у него (или у нее) есть перечень технологий, с которыми он сталкивался в практике и в которых разбирается на достаточно высоком уровне.
Путь эксперта — это постоянные учеба, практика и ошибки
Есть 2 ключевых критерия, по которым можно определить, может ли специалист называться «в достаточной мере экспертом» (заметьте, это понятие не тождественно «эксперту высшей категории») в каком-то конкретном стеке технологий. Эти критерии — reason (умение мыслить на разных уровнях абстракции) и troubleshoot (умение определять, что и почему не работает).
Приведу пример. Допустим, в приложении — а ни одно из них не «однослойное» — возникает проблема. Ваших знаний и компетенции должно быть достаточно, чтобы по симптомам предположить, из-за чего возникла проблема и как ее решить. Вы можете ошибаться, причем неоднократно, но у вас должно быть понимание, с чего начать, как продолжить, что делать, если вы ошиблись, и что предпринять дальше. Это troubleshoot. Другой вариант — «чистый лист», когда еще ничего не выстроено, понимание проблемы и инструментов поможет определить архитектуру, продумать различные варианты и из нескольких правильных ответов выбрать более правильный. Это reason.
Как же достичь такого уровня? Отправная точка — это вы сами, ваше искреннее желание пройти через все трудности и вызовы реального опыта в работе с выбранными технологиями. Теоретической подготовки недостаточно. Я говорю о реальной работе в условиях жестких дедлайнов и прессинга, опыта решения проблем на практике. Чтобы достичь совершенства вы должны проделывать это систематически, в повторяющемся режиме. Рекурсивно.
Важно научиться учиться
Поделюсь своей собственной историей. Моя профессиональная карьера девелопера началась 17 лет назад с разработки software для компаний клиентов. Я работал на Delphi (надеюсь, не все еще забыли, что это такое), PHP, Perl, языке ассемблера, которым с тем пор больше ни разу не пользовался. Парадоксально, но моим главным козырем на начальном этапе стало свободное владение немецким языком, поскольку на нем была написана предоставленная клиентом спецификация. Я оказался «достаточно умелым девелопером», чтобы прочитать ее и правильно понять задачу.
Два месяца спустя я взялся за XSLT. Мне понравился этот функциональный язык и процесс его изучения, хотя очень немногие разделяют мое мнение. Более того, я люблю его до сих пор. Потом было немного практики с Lotus Notes, но очень скоро я перешел на Java для написания Lotus Notes Agents. Затем — большой проект по созданию серверных страниц на старой доброй Javа-версии 2000 года. Еще через год мне понадобились знания Oracle PL/SQL.
В те времена я был джуниором, со мной работали супервайзеры. Мне помогали разобраться в тонкостях и нюансах, но все описанные технологии приходилось применять в условиях настоящей проектной работы для решения реальных задач. И кстати, опыт с PL/SQL, приобретенный в те 6 месяцев, я использую до сих пор, поскольку SQL не изменился. Затем был большой Java-проект с PostgreSQL. Для внутренней системы мы выбрали браузер IE5 с XMLHttpRequest. Мы работали с AJAX, когда этот термин еще не был придуман. Таким образом, я освоил многое из фронтенда.
Не всегда все получалось: проект по созданию приложения на VB6 с базой данных MySQL, в котором я выполнял функции delivery-менеджера, «провалился», но это отдельная история. Резюме: за три года работы в реальных проектах, в качестве того, кого сегодня называют Full Stack, задействовав множество технологий в каждом из них, я выработал практические навыки. И в 2003 я пришел в EPAM. Кстати, само слово EPAM мы используем как глагол: «Он или она еще не научились «епамить». И речь идет не о технологиях, а о skills. Важнее всего научиться постоянно обучаться. Это, наверное, самое важное из того, что я усвоил за первые три года карьеры.
Нужно научиться учиться. Только лишь перекрестного обучения мало. Фронтенд-разработчику недостаточно пройти курс Java и вернуться к фронтенду или наоборот. Мы должны создавать среду, в которой сможем получать перекрестный опыт. Новый тип профессионального роста инженеров должен включать в себя привычку менять технологии каждые
На данный момент мы требуем от специалистов знания технологий, но не популяризируем пути к их освоению. Например, если вы работали Java-девелопером 2 года, достигли уровня senior и переключаетесь на нечто другое, поначалу вам будет очень сложно. Но спустя всего 2 месяца вы освоитесь, и в дальнейшем с каждым разом будет все легче и легче. Трудно лишь сделать первый шаг, первое «переключение». И гарантирую, после освоения новой технологии повысится также ваш уровень в Java, потому что вы не только изучите новые инструменты и методы, но и разовьете другой тип мышления, увидите привычные вещи под новым углом. Смена технологий должна периодически повторяться на вашем карьерном пути — и это чрезвычайно важно!
Синдром самозванца как мощный мотиватор
Что меня вдохновляет? Прежде всего, нужно освоить методы борьбы с так называемым «синдромом самозванца» (imposter syndrome) или же недостаточной уверенностью в собственных силах, значимости. Кому-то может казаться, что он недостоин тех денег, которые ему платят. Периодически этот синдром переживает каждый специалист IT-сферы, особенно в нынешнее время, когда технологии развиваются с фантастической скоростью.
Когда это случается со мной, я делаю паузу, берусь за проект, реализуя который доказываю окружающим и, в первую очередь, самому себе собственную ценность как профессионала. «Синдром самозванца» отступает, чтобы через некоторое время вернуться вновь. И все повторяется.
Второй важный компонент — programming language tourism. Перефразирую анекдот, призывающий не путать туризм с эмиграцией. Вы не должны любить все, в чем пробуете силы, но вы обязаны попробовать для того, чтобы иметь об этом представление. Мой лучший «тур» состоялся 5 лет назад: я нашел проблему в рекламном объявлении Spotify и, не тратя время на решение с помощью алгоритмов, прописал ее, но на 3 языках — Java, Ruby и Prolog. На изучение последнего я потратил 2 недели, выкраивая время между текущей работой и встречами. И это один из тех примеров, когда, оглядываясь назад, я доволен результатами своей работы. Этот написанный 5 лет назад код мне нравится до сих пор (он, кстати, есть на моем GitHub, если кому-то любопытно).
Никогда ранее я не изучал Prolog, вряд ли воспользуюсь им в будущем, но зато я убедился, что могу его выучить, и, при необходимости, написать на нем что-либо. Кстати, сам код был хорош. Он состоял всего из 18 строк против 45 на Ruby и 300 на Java, с полностью аналогичным функционалом.
Существует специализированная платформа — Exercism, на которой вы можете практиковаться в 30 языках, получить помощь других специалистов, пробовать, изучать. И затем, конечно же, переходить к реальной практике.
Что нам нужно для того, чтобы двигаться вперед? Первое — создать сообщество людей, которых я называю людьми «типа А». Они способны действовать, запускать небольшие проекты, создавать прототипы. Они — практики. Второе — нам нужны люди, способные генерировать идеи и передавать людям типа А. Я, например, практик, человек, который реализует идеи, но не генерирует их.
И, повторюсь, все начинается с вас самих. Получайте реальный опыт, изучайте то, о существовании чего даже не догадывались. Это принесет новый опыт, который поможет стать лучше в основной выбранной специализации. Нужно постоянно, снова и снова бросать вызовы самим себе.
