Перевод статьи «Should You Specialize Your Software Skills?».
Мне повезло работать в компании, где я могу быть настоящим full-stack разработчиком. Я создаю приложения для обеих нативных мобильных платформ, iOS и Android. В любой отдельно взятый день я пишу код на Kotlin, Swift, Typescript, а еще занимаюсь поддержкой платформы, если какой-то инцидент случится. В какие-то дни я фокусируюсь на архитектуре интерфейса для записи данных в телефон. В другие занимаюсь бэкендом. В общем, вы поняли.
Я, как говорится, специалист общего профиля, универсал, «генералист», причем еще с колледжа. Свою карьеру я начал в веб-разработке, но код я писал и для сервера, и для веба, и все это попадало в продакшен.
И благодарение небесам за это.
Мне не доводилось работать в компании, которая пыталась бы втиснуть меня в прокрустово ложе того, что у меня «хорошо получается», или того, в чем у меня «есть опыт». Я думаю, благодаря этому я стал куда лучшим разработчиком, чем мог бы стать в других условиях. И потому я уверен: не стоит фокусироваться на том, чтобы стать узким специалистом.
Лучшая перспектива
Первая причина писать full-stack код — так вы получаете понимание всей вашей системы. Задача разработчика — создавать отличные продукты. Когда вы пишете код только для одной части продукта, вы не представляете в полной мере, насколько хорош продукт в целом.
Занимаясь только UI или только базами данных, вы похожи на кондитера, который занимается исключительно глазурью для торта. В результате у вас может получиться отличная глазурь на невкусном торте!
Кроме того, когда вы ведете разработку с расчетом на full-stack, ваш дизайн, естественно, будет более подходящим для full-stack.
Если вам доводилось писать full-stack код, вы знаете, что на уровне базы данных данные выглядят совсем иначе, чем на уровне UI. В базе данных все хранится совсем не в таком виде, в каком показывается пользователю. Этот подход позволяет улучшать производительность и уменьшать избыточность.
Когда вы работаете в контексте full-stack, ваши уровни абстракции и способ формирования данных на каждом уровне становятся более логичными (причем естественным образом, как бы само собой). В результате вы получаете лучший код.
Код становится просто кодом
Когда вы постоянно переключаетесь с одних контекстов и языков на другие, вы к этому привыкаете, и у вас начинает хорошо получаться. В связи с этим вы начинаете куда быстрее усваивать новые языки и контексты. И когда вы сталкиваетесь с новой кодовой базой, у вас оказывается достаточно опыта и навыков для работы с ней.
Это особенно верно для объектно-ориентированных языков. Они заметно похожи между собой. За свою пока еще довольно короткую карьеру я писал продакшен-код как минимум на 5 языках, а в личных проектах применял еще и другие. После изучения первых двух языков изучение каждого нового вообще не было проблемой. Покажите мне, куда ставить точку с запятой, расскажите о разнице между константами и переменными и о том, как создавать класс, — вуаля, дело сделано.
До прихода на мою нынешнюю работу мне никогда не приходилось писать код на Kotlin или Swift. Я много писал на TypeScript (который считается ОО-языком) и так же много на Java.
Когда вы переключаетесь между языками, мелкие различия, касающиеся точек с запятыми, а также отношений между классами, структурами и объектами, становятся для вас менее важными. Ну, а код становится просто кодом.
Языки приходят и уходят
Умение быстро осваивать новые языки это очень полезный навык, потому что языки в наше время это преходящие увлечения.
Одним из самых первых фреймворков, с которыми я работал, был AngularJS. Он вышел в 2010 году, а я начал пользоваться им в 2016-м. Тогда же, в 2016-м, вышел Angular 2+. Это, кстати сказать, совершенно разные платформы с разными языками. Обе они созданы Google для написания одностраничных веб-приложений, но с точки зрения разработки они совершенно разные.
На тот момент я не знал, что Angular 2+ станет концом AngularJS. Официально жизнь AngularJS завершилась в 2018 году. Поскольку я написал веб-платформу на AngularJS, мы искали способ, как ее переписать. В то время я был еще начинающим программистом. Помню, как думал: «Неужели придется учить все это дерьмо заново?!»
За свою короткую карьеру я уже увидел рассвет и закат многих технологий. Означает ли это, что все, что я учил относительно AngularJS, было напрасной тратой времени и сил? Конечно же нет. Это был просто первый раз, когда я практиковался в изучении нового языка. У меня остались навыки, которые я мог применить в работе с Angular 2+ и некоторыми другими веб-фреймворками. А веб-разработка и JavaScript остались теми же.
Сфера разработки быстро меняется, это просто факт. Нужно уметь адаптироваться. Теперь (с высоты своего опыта), когда я вижу, что фреймворк или язык устаревают, я очень легко прощаюсь с ними.
Специализация в любом случае приходит сама
Любопытно, что специализация, в общем, приходит естественным путем. Спросите любого знакомого разработчика, как он выбрал свою специализацию. Кто-то действительно выбирал, но многие просто «уже имели опыт в этом направлении» или «уже хорошо разбирались в этом деле».
Когда разработчик говорит, что «имеет опыт работы с…», это означает, что ему уже приходилось изучать эту технологию на каком-то этапе его карьеры. Он мог осваивать этот язык или фреймворк, когда работал над проектом в колледже или над своим единственным стажерским проектом. Затем он указал эту технологию в своем резюме, когда после окончания колледжа искал работу («Имею опыт в…»). И — хоп! — она внезапно стала его специализацией.
Вся работа разработчика — изучать разные вещи и реализовывать их. Когда мы получаем задание, в котором ничего не понимаем, мы садимся и пытаемся разобраться. Если ваша задача — за год создать Android-приложение, я готов поспорить, что через год вы станете экспертом по Android-разработке. Такова природа нашей работы. Вы делаете то, что нужно вашей компании, и естественным образом становитесь специалистом в этом направлении.
Люди готовы платить экспертам. Но далеко не каждый может себе это позволить
Наконец, если вы хотите работать в маленькой компании, вы можете и не стремиться стать узким специалистом.
Не секрет, что топовые организации готовы платить большие деньги экспертам в отдельных областях инженерии. Компании нанимают узких специалистов, когда им нужно сделать что-то такое, на что не способны остальные разработчики. Это как в медицине: если вам нужно провести операцию, вы ищете узкого специалиста — хирурга.
Но хирурги — дорогие врачи. И разработчики с узкой специализацией — тоже. Крупные компании могут позволить себе нанимать экспертов по работе с определенным фреймворком или платформой. Но если вы хотите работать в стартапе, для вас важнее гибкость. Когда у вас две нативных мобильных платформы и бэкенд, а разработчиков всего 5-10 человек, вы должны уметь адаптироваться. В таких условиях нет возможности держать отдельного специалиста по базам данных.
Став узким специалистом, вы сможете запрашивать более высокую цену за свою работу, но в мире есть не только крупные компании. Стартапам, как и всем остальным, тоже нужны хорошие разработчики.
В общем, если вы любите работать с определенным стеком или языком, вы можете специализироваться. Ваша карьера на этом не закончится, да и работу вы найдете. В нашей сфере вообще полно работы. Но я уверен, что благодаря более широким познаниям мы начинаем писать код гораздо лучше.
Вы слыхали о Т-образных наборах навыков? (В букве «Т» горизонтальная черточка представляет собой широкие знания, а вертикальная — глубокие. То есть, у человека должны быть широкие и при этом неглубокие познания в разных областях, а глубокие — в какой-то одной. — Прим. ред. Techrocks). Я думаю, что набор навыков должен напоминать ну очень широкую «Т». Или даже «Е». Продолжайте изучать новые вещи и оставайтесь в некоторой мере универсалами.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
