Стоит ли разработчику специализироваться (и есть ли у него выбор)?

0
745
views

Перевод статьи «Should You Specialize Your Software Skills?».

Photo by Anna Daudelin on Unsplash

Мне повезло работать в компании, где я могу быть настоящим full-stack разработчиком. Я создаю приложения для обеих нативных мобильных платформ, iOS и Android. В любой отдельно взятый день я пишу код на Kotlin, Swift, Typescript, а еще занимаюсь поддержкой платформы, если какой-то инцидент случится. В какие-то дни я фокусируюсь на архитектуре интерфейса для записи данных в телефон. В другие занимаюсь бэкендом. В общем, вы поняли.

Я, как говорится, специалист общего профиля, универсал, «генералист», причем еще с колледжа. Свою карьеру я начал в веб-разработке, но код я писал и для сервера, и для веба, и все это попадало в продакшен.

И благодарение небесам за это.

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

Лучшая перспектива

Cake, for reference. Photo by Alina Karpenko on Unsplash

Первая причина писать full-stack код — так вы получаете понимание всей вашей системы. Задача разработчика — создавать отличные продукты. Когда вы пишете код только для одной части продукта, вы не представляете в полной мере, насколько хорош продукт в целом.

Занимаясь только UI или только базами данных, вы похожи на кондитера, который занимается исключительно глазурью для торта. В результате у вас может получиться отличная глазурь на невкусном торте!

Кроме того, когда вы ведете разработку с расчетом на full-stack, ваш дизайн, естественно, будет более подходящим для full-stack.

Если вам доводилось писать full-stack код, вы знаете, что на уровне базы данных данные выглядят совсем иначе, чем на уровне UI. В базе данных все хранится совсем не в таком виде, в каком показывается пользователю. Этот подход позволяет улучшать производительность и уменьшать избыточность.

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

Код становится просто кодом

Код, просто код. Правда, нечитаемый. Photo by Markus Spiske on Unsplash

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

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

До прихода на мою нынешнюю работу мне никогда не приходилось писать код на Kotlin или Swift. Я много писал на TypeScript (который считается ОО-языком) и так же много на Java.

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

Языки приходят и уходят

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

Одним из самых первых фреймворков, с которыми я работал, был AngularJS. Он вышел в 2010 году, а я начал пользоваться им в 2016-м. Тогда же, в 2016-м, вышел Angular 2+. Это, кстати сказать, совершенно разные платформы с разными языками. Обе они созданы Google для написания одностраничных веб-приложений, но с точки зрения разработки они совершенно разные.

На тот момент я не знал, что Angular 2+ станет концом AngularJS. Официально жизнь AngularJS завершилась в 2018 году. Поскольку я написал веб-платформу на AngularJS, мы искали способ, как ее переписать. В то время я был еще начинающим программистом. Помню, как думал: «Неужели придется учить все это дерьмо заново?!»

За свою короткую карьеру я уже увидел рассвет и закат многих технологий. Означает ли это, что все, что я учил относительно AngularJS, было напрасной тратой времени и сил? Конечно же нет. Это был просто первый раз, когда я практиковался в изучении нового языка. У меня остались навыки, которые я мог применить в работе с Angular 2+ и некоторыми другими веб-фреймворками. А веб-разработка и JavaScript остались теми же.

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

Специализация в любом случае приходит сама

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

Когда разработчик говорит, что «имеет опыт работы с…», это означает, что ему уже приходилось изучать эту технологию на каком-то этапе его карьеры. Он мог осваивать этот язык или фреймворк, когда работал над проектом в колледже или над своим единственным стажерским проектом. Затем он указал эту технологию в своем резюме, когда после окончания колледжа искал работу («Имею опыт в…»). И — хоп! — она внезапно стала его специализацией.

Photo by Hunters Race on Unsplash

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

Люди готовы платить экспертам. Но далеко не каждый может себе это позволить

Наконец, если вы хотите работать в маленькой компании, вы можете и не стремиться стать узким специалистом.

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

Но хирурги — дорогие врачи. И разработчики с узкой специализацией — тоже. Крупные компании могут позволить себе нанимать экспертов по работе с определенным фреймворком или платформой. Но если вы хотите работать в стартапе, для вас важнее гибкость. Когда у вас две нативных мобильных платформы и бэкенд, а разработчиков всего 5-10 человек, вы должны уметь адаптироваться. В таких условиях нет возможности держать отдельного специалиста по базам данных.

Став узким специалистом, вы сможете запрашивать более высокую цену за свою работу, но в мире есть не только крупные компании. Стартапам, как и всем остальным, тоже нужны хорошие разработчики.

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

Вы слыхали о Т-образных наборах навыков? (В букве «Т» горизонтальная черточка представляет собой широкие знания, а вертикальная — глубокие. То есть, у человека должны быть широкие и при этом неглубокие познания в разных областях, а глубокие — в какой-то одной. — Прим. ред. Techrocks). Я думаю, что набор навыков должен напоминать ну очень широкую «Т». Или даже «Е». Продолжайте изучать новые вещи и оставайтесь в некоторой мере универсалами.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here