×

Я, девелопер

[Об авторе: Павел Веллер — 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 и вернуться к фронтенду или наоборот. Мы должны создавать среду, в которой сможем получать перекрестный опыт. Новый тип профессионального роста инженеров должен включать в себя привычку менять технологии каждые 3-5 лет, а для некоторых специализаций и чаще, например, каждые 6 месяцев. Для таких профессий, как solution architect, это должно стать обязательным требованием прежде, чем проходить тестирование на SA 1-го уровня.

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

Что нам нужно для того, чтобы двигаться вперед? Первое — создать сообщество людей, которых я называю людьми «типа А». Они способны действовать, запускать небольшие проекты, создавать прототипы. Они — практики. Второе — нам нужны люди, способные генерировать идеи и передавать людям типа А. Я, например, практик, человек, который реализует идеи, но не генерирует их.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




41 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Я думаю, що ще більш різноманітна і ширша експертиза у тестувальників, правда мабуть більше поверхова. Поки розробники можуть тижнями пиляюти одну фічу, я встигаю написати автотести під UI, API, Performance, трохи розширити фрейморк написаний ще до початку моєї кар’єри, і реалізувати пару фіч для внутрішнього QA утіліти на Backbone.js. Голова іде колом, але точно не нудно ;)

Никогда ранее я не изучал Prolog, вряд ли воспользуюсь им в будущем,

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

Баланс я ищу (и иногда нахожу) в другом месте. Что читаю, что смотрю, как провожу вечера, когда я один (в командировке) или решил лечь спать попозже, и как организую свой рабочий день. Семьей, спортом и хобби, которые не связаны с компьютерами, не жертвую. Жертвую художественной литературой (к сожалению), кабельным телевидением, и бесполезной работой (= busy work).

> Прежде всего, нужно освоить методы борьбы с так называемым «синдромом самозванца» (imposter syndrome) или же недостаточной уверенностью в собственных силах, значимости. Кому-то может казаться, что он недостоин тех денег, которые ему платят. Периодически этот синдром переживает каждый специалист IT-сферы, особенно в нынешнее время, когда технологии развиваются с фантастической скоростью.

Знакомая жизненная ситуация. Только мы ее называли не «синдромом самозванца», а «ямой позора» :)

Открыл линк на GitHub, но кода на Prolog не увидел.
Может быть, плохо искал — ткните пальцем, пожалуйста?

и вот подробности если правда интересно: pveller.blogspot.com/...​java-ruby-prolog-and.html

В області мозку, що відповідальна за нові знання, нейрони народжуються впродовж всього життя людини

Хто це знайшов таку особливість?

However, in a Nature paper published in March, Shawn Sorrells and colleagues (2018) report that, at least in humans, neurogenesis ends sometime in childhood. Once again flipping the narrative, this study has stirred up controversy.

I f..cking love science :)

Ще цей факт приводиться в курсі «Learning how to learn» професором Седжновскі.

Це оптимістично, але питання контроверсійне, висновки не однозначні, тому я б не говорив про це, як про факт без пояснень.

Та то зрозуміло, от тільки є вагомі причини довіряти Теренсу Седжновскі стосовно даної теми, він все-таки в цьому неслабо гребе

Я також вважаю, что треба усвідомлювати міру цієї сенсаційної новини. Автори не стверджують, що в області, яка, як вважається, відповідальна за обробку нових знать, нейрони народжуються та розвиваються у літніх людей, як у немовлят. Гліальні нейрони можуть народжуватися, можливо, дендро-дендральні контакти можуть модифікуватися, ми вчимося новому, це важче, але можливо, тому не треба дорікати тільки на власний вік. Безліч цінних ідей, де потрібні робота з висновками та досвід, були народжені літніми людьми.

Это конечно всё очень круто, я тоже могу рассказать парочку кул стори о том, как я за 2 года написал 10 проектов, и каждый на новом наборе языков или технологий, как это было классно и как я всё успешно заделиверил. Но в общем случае есть одна проблемка, по крайней мере, в случае с наймом: в 90% случаев вы не сможете пройти типичное техническое собеседование, если у вас нет 10 лет опыта в чём-то одном. Вы скорее всего на собеседование даже не попадёте. Такое свитчерство сейчас прокатывает разве что в случае с Go, Machine Learning или подобными только-только проявившимися, но уже востребованными технологиями и областями знаний. Ну ещё если вы уже работаете в компании, и она переходит на новый стек (что встречается не так уж часто), тогда да.

Адекватные компании (взгляд в сторону silicon valley) нанимают программистов, а не «программистов на».

Я говорю о реальной работе в условиях жестких дедлайнов и прессинга

а работа без прессинга не «реальная» ? под прессом хорошо шаблоны создаются, отсюда и импостор синдром — мы понимаем что шаблоны не имеют большой ценности

Є таке прислів’я «Jack of all trades master of none». Чим більше я знаю тим більш я розумію що важко стати master of something якщо ти такий собі jack of all trades.

Спасибо, познавательно, и ссылки норм )

Здравствуйте!
Правильно будет «Я — девелопер.»
То, что написали Вы, — незаконченное предложение. К примеру, «Я, девелопер и Perl».
За статью «спасибо».
С уважением,
тестировщик.

Оригинальное название моего выступления на конференции было I, Developer. Помните кино I, Robot ? Вот так и получился Я, Девелопер.

У тестировщицы тест кейс не прошёл)

Девелопер — это уточнение. Ваш КО.

Чому «Девелопер» а не «Дівелопер»?

Ноу)) Event — ивент же, а не эвент. Так почему девелопер а не дивелопер?

Так, просто, принято в современном обществе, похоже — ru.wikipedia.org/wiki/Девелопер

Спасибо, очень интересная статья.

Что нам нужно для того, чтобы двигаться вперед? Первое — создать сообщество людей, которых я называю людьми «типа А». Они способны действовать, запускать небольшие проекты, создавать прототипы. Они — практики. Второе — нам нужны люди, способные генерировать идеи и передавать людям типа А.

Интересно, кто сможет создавать идеи/проблемы для общества людей типа А, например, в аутсорсинговой конфигурации компании?

Провожу эксперимент уже несколько месяцев. Выступил на QBR (quarterly business review) перед аудиторией account managers и предложил использовать часть моего R&D бюджета не на прототипы и идеи, которые есть у нас инженеров, а на прототипы и идеи, которые помогли бы им помочь их/нашим клиентам. Движение есть. О результатах стоит будет говорить через год

Интересно, какой формат идеи от аккаунт менеджера запомнился?

Підписатись на коментарі