Фулстеки — это будущие архитекторы, а не вечные мидлы (если захотят конечно)

Ой, а напомни как называют очень опытного программиста, там что-то такое романтично-средневековое, кажется «милорд»...

Почти три года назад на Хабре вышла статья «Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать». Я еще тогда был не согласен с изложенным, но сдержался:) Однако недавно я стал свидетелем весьма примечательного случая и сразу вспомнилась та самая статья... Итак, одна команда испытывала нехватку бекенд-разработчиков и сравнительный переизбыток разработчиков на фронте. Дело осложнялось сжатыми сроками сдачи проекта. Проблема типовая, но стек..., ах если бы не стек: бек — NodeJs, фронт — React, TypeScript и там и там.

Я не хочу отрицать важность специализации вообще, но в данном конкретном случае ответ очевиден: нужно перебросить кого-то с фронта на бек. Да, это будет неэффективно, да скорее всего в бекенд-коде, который напишет фронтендер будет больше проблем, но альтернатива то еще хуже: часть команды будет зашиваться, пока другая — простаивать. Если вы дочитали до этого места и уже готовитесь написать гневный комментарий о том, что «бекенды же бывают разные и в том числе такие сложные, что ваще капец и такой финт ушами не пройдет и только всех замедлит и сделает еще хуже», то не спешите не сдерживайтесь, пишите прямо сейчас (больше мнений в комментах!). Так вот, это был простой бекенд пишущий и читающий в/из базы данных. Никаких особенно сложных штучек-дрючек там не было...

Может быть я старомоден, но сегодняшняя специализация порой видится мне чрезмерной. Раньше все было как-то проще: ты либо умеешь программировать, либо нет. А сейчас все кругом ищут кибер-ниндзю с опытом работы исключительно на фреймворке X не менее пяти лет (хотя фреймворк X существует четыре года). Если ты работал с фреймворком X всего три года, то с тобой не о чем разговаривать: ты — джун. Ага, т.е. известному английскому банку не впадлу нанимать на Java-проект кандидата с десятилетним опытом на .NET’е, потому что они считают, что важны фундаментальные знания, а не знания конкретной платформы (ну напорется он пару раз на стирающиеся дженерики и сравнение строк через ==, почешет репу и перестанет так делать), а ООО «Рога и Копыта Интернейшнл» может работать только с теми, кто пять лет ковырял фреймворк Х. По-моему это фигня. Кстати, тот парень в банке, что перешел с .NET'а на Java сейчас там числится синьором и находит горы проблем в мердж-реквестах разработчиков, пишущих на Java значительно дольше него.

Знать все на свете невозможно

Не сказать, что разные точки зрения на вопрос «что лучше: вширь или вглубь» существуют только в программировании. Например американская система здравоохранения предполагает две ученые степени: MD и DO. Если копнуть глубже, то мы откопаем холизм и редукционизм, как две крайние точки зрения на вопрос является ли целое совокупностью всех его составных частей или чем-то большим. Аргументы в пользу узкой специализации уже привел @fillpackart. Я приведу свои в пользу расширения сознания.

Фулстеки не должны «знать все». Фуллстек — это человек, неплохо (не превосходно!) разбирающийся сразу в нескольких дисциплинах. Кстати, у врачей это называется «терапевт» или «general practitioner». Куда вы попадаете первым делом в медицинском учреждении: к хирургу, к психотерапевту, может быть к гастроэнтерологу? Или к терапевту? Это нормально: нужны как узкие, так и широкие специалисты. Это не хорошо и не плохо, это просто по-разному.

Большинство задач, решаемых большинством разработчиков далеки от rocket science. Давайте честно: сколько у вас типовых тасков, а сколько творческих? Как часто требуется знание деталей реализации низкоуровневых системных API?

T-Shaped — фуллстек здорового человека

Между экстремальными «только вширь» и «только вглубь» существует еще и T-shaped: кто запрещает развиваться в том, что нравится больше всего, но подтягивать до базового уровня еще несколько дисциплин. T-shaped команды гораздо легче находят общий язык среди своих членов и гораздо гибче и устойчивее ко внешним воздействиям. Пришел горящий инцидент с прода, коллега заболел(а), произошло что-то незапланированное? Команда готова подстроится. Да T-shaped специалист скорее всего не сможет выполнить сложные задачи из смежных областей. Простые задачи, возможно, сделает хуже и/или дольше эксперта, но он их сделает, черт возьми! Работа не остановится потому что узкий специалист недоступен по той или иной причине.

Пусть большую часть работы по фронту выполняет фронтендер, настраивает выкладки — админ (или devops, не знаю как теперь правильно), а бекенд пишет бекендер. Но что если этот специалист здесь и сейчас недоступен? Неужели нельзя внести правку в конфиг или починить небольшую багу самому? Я думаю, что во многих случаях вполне себе можно. Как вообще бекендер и фронтендер будут разговаривать, если они не понимают специфики работы друг друга?

Отличия дуал-классов от мульти-классов в AD&D

Посмотрим на развитие специалиста через призму AD&D. В первых редакциях правил персонаж всегда должен следовать одному классу. Назвался воином — полезай в кузов никакой тебе магии стихий. Знай орудуй двуручным мечом. Потом появились «мультиклассы», скажем воины-маги или жрецы-монахи. Довольно быстро стало ясно, что прокачать мультикласс — та еще задачка, ведь опыт делится между двумя классами, поэтому в то время как «чистый» воин уже десятого уровня, воин-маг набрал только пятый уровень в каждом классе.

Можно конечно бесконечно вырубать крипов и за бесконечное время подняться до необходимого уровня, однако все мы смертны и хотелось бы тратить отведенное нам время более занимательно. Поэтому появилась новая концепция дуал-классов. Вы фиксируете уровень в одном классе и продолжаете развиваться в другом. Этот сценарий уже гораздо интереснее. На сколько я помню, во времена Icewind Dale 2 отлично работал дуал вор-маг. Уровень вора останавливался в районе шестого (или около того), а дальше прокачивался маг. На первых уровнях от заклинаний мага все-равно толку мало, а вор шестого (или около того) уровня уже спокойно разбирался с большей частью замков и ловушек, а вместо того, чтобы обворовывать NPC их можно было просто убивать и забирать тот же самый лут + опыт за убийство неписей впридачу.

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

Да, я помню, что у дуал-классов в AD&D еще есть нюансы и ограничения, но в контексте статьи это неважно. К тому же это ограничения правил AD&D, а не реальной жизни;)

Вширь и вглубь

Будьте T-shaped или дуал-классом (как угодно) и развивайтесь вширь и вглубь. Просто вместо того, чтобы бездумно кидаться на любую новую технологию или фреймворк, с умом инвестируйте время и выбирайте те дисциплины, которые дополняют и усиливают друг друга (в английском есть глагол to synergize, который я хотел употребить, но в русском ничего друг с другом не синергируют/синергизирует,... ну вы поняли о чем я). Скажем, Rust не будет лишним, если у вас хорошие знания в C или C++, Kotlin проще учить вторым языком к Java, JavaScript подойдет, если вы работаете с вебом, а случись так, что C#, F# и JavaScript вы уже знаете (мой случай), TypeScript и учить-то толком не придется.

Концепция синергии навыков и умений отлично реализована в Divinity Original Sin 1 и 2. Эти RPG не основаны на правилах AD&D, так что там нет классов и игрок волен выбирать почти любые умения для каждого из персонажей. Просто некоторые комбинации оказываются лучше других, потому что они усиливают друг друга. Скажем, воину лучше всего дополнительно научиться навыкам некромантии, а рейнджера можно замесить с рогой, чтобы получить ассасина.

Правда некоторые билды в Original Sin 2 таким макаром оказались сломаны. Скажем, если Фейн качается в некроманта, берет пару скилов из соседних веток, с помощью маски меняет расу на эльфа... все заканчиваю с примерами из игрушек:)

Почему архитекторы?

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

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

Бывает, что архитектурные вопросы решаются коллегиально. Однако в конечном счете все-равно есть человек, за которым остается последнее слово когда команда не может прийти к консенсусу, и который осуществляет контроль за соблюдением достигнутых договоренностей. Архитектор должен говорить на одном языке как с бизнесом, так и с разработкой и обладать авторитетом у тех и других, чтобы у лидов не возникало вопросов к его компетентности и соблазна саботировать достигнутые решения об архитектуре. Бизнес в свою очередь должен быть уверен, что выбранная архитектура адекватна решаемой задаче, а не высосана из пальца, потому что вся команда хочет поиграть в микро-сервисы/блокчейн/<вставьте своё>. А для этого придется много чего знать и уметь.

Логические ошибки оригинальной статьи

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

Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё… Так я создал себе культ пренебрежения деталями. Пусть в деталях копошатся джуны, которые не могут в абстракции... Всё вокруг одинаковое, и я увидел закономерность. Теперь, когда мне нужно поработать на каком-нибудь нелепом питоне, я говорю: «дайте немного времени на беглое чтение спеки, и я готов работать с этим говном на уровне senior...

Всего лишь два с половиной си-подобных языка программирования (TS - суть C#, натянутый на JS, так что за полноценный ЯП считать не будем) и три паттерна: MVC, MVVM и Flux (если вы уже знаете CQRS+ES, то Flux чем-то новым и прорывным казаться не будет) и случился Даннинг-Крюгер. К мидловости, синьорности или фулстековости всё это отношения не имеет. Детали бывают важны, просто нужно определиться в каком стеке и в каком объеме. Где здесь основной фокус: веб, десктоп, мобильная разработка? Кажется, что в этом наборе лишние WPF и Xamarin. Достаточно было сосредоточиться на веб-разработке и появилось бы время уделить внимание деталям.

Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте так не делают. Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты. Обычно это помогало, но в этот раз остался осадок.

Не знаю кто именно в TS так не делает, что там был за дизайн и почему реакция коллег свелась к высмеиванию, а не к конструктивной обратной связи вида «давай здесь переделаем вот так, а вот здесь эдак, потому что у нас такие-то цели и мы их достигаем так-то». В любом случае, когда я слышу, что вопросы проектирования обсуждаются в терминах нравится/не нравится, то сразу напрягаюсь, потому что вспоминаю про Культ Карго. Не бывает правильных или неправильных решений вне контекста. Копирование архитектурны с предыдущего проекта без анализа текущей ситуации — тревожный звонок, потому что в IT условия каждого проекта могут варьироваться в достаточно широком диапазоне. В TS поддерживаются классы, в том числе абстрактные. Что смешного в абстрактных классах? Ну и вишенка на торте обвинить коллег в бездарном идиотизме. Это безусловно очень взрослая и профессиональная реакция. Именно так люди и становятся синьорами.

Затем началась черная полоса. Фигак! Я не знаю, что там за типы индексов в SQL. Бам! Забыл, когда вызывается статический конструктор в шарпах. Упс! Я не могу правильно реализовать IDisposable без гугла. Пытаюсь мутировать стейт в реакт компоненте... «Я научился быстро учиться» оказался неправдой. Я учился не быстрее, чем все остальные. И мне потребовалось слишком много времени, чтобы это понять... Мой скилл оказался как обоз — лебедь, рак и щука пытались тащить его в разные стороны. Я не стал автоматически сеньором во всем. Я просто стал мультимидлом, посмешищем для сорокалетних сеньоров одной технологии. И тогда я пришел к выводу, что выбирать путь фулстека — ошибка.

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

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

Конечно, если взять двух однояйцевых близнецов и одного из них заставить по восемь часов в день пять дней в неделю программировать, а другого — играть на гитаре, скорее всего первый станет неплохим программистом, а второй — музыкантом. По крайней мере так я себе объясняю, почему программист из меня лучше, чем гитарист, ведь на программирование я тратил около восьми часов в день в течение пятнадцати лет, а музыка всегда была и остается хобби:) Часто ли ставят такие эксперименты с близнецами и повторимы ли результаты таких эксппериментов в реальной жизни? Кто-то готов тратить на работу четыре часа в день, а кто-то — двенадцать. Кстати, не факт, что тот, кто посвящает работе двенадцать часов в сутки обязательно перегорит и в итоге будет несчастлив. Бывают очень увлеченные люди, а бывают те, кому и четыре часа втягость.

Есть ли прямая связь между затраченным временем и успешным успехом? Любой педагог скажет, что всех студентов можно условно разделить на три группы:

• те, кто научаться независимо от качества программы и преподавателя

• те, кто не научатся не при каких обстоятельствах

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

На качество обучения и запоминания вообще влияет куча всего. Если вам интересно, как учиться эффективнее и успевать больше, посмотрите лекцию Память и обучение Аси Казанцевой и запись вебинара Джедайские техники 2.0 Максима Дорофеева. Это, безусловно, не единственные и не самые полные источники информации об обучения и о личной эффективности, зато оба видео несут понятную практическую пользу прямо здесь и сейчас.

Последние пять лет у меня была возможность наблюдать за тем как учатся студенты: я преподаю курс по выбору в Казанском Федеральном Университете. Курс имеет ограничение на количество студентов, потому что в сутках всего двадцать четыре часа, а еще я много сплю. Знаете, что я наблюдаю? Чем выше средний балл по всем предметам, тем лучше студенты занимаются у меня на курсе. Обратное тоже верно. Иными словами, троечники учатся спустя рукава по всем предметам, а отличники успешны не только в программировании, но и в математике, истории и философии. Таким образом нет прямой зависимости между прошедшим времени и полученным знаниями студента в одной или нескольких областях. Ещё интереснее то, что нет прямой зависимости между знаниями и тем, на сколько хорошо человек будет работать, но об этом в другой раз.

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

Смотри выше, нет не любой и нет, не шарит. А если шарит, так это же хорошо! У этого человека есть чему поучиться. Это неиссякаемый источник личного роста, а не самобичевания.

Если хочешь оставаться фулстеком, тебе придётся заставлять себя читать релиз-ноуты какого-нибудь TypeScript, заодно ещё и пробуя их в деле — даже если не хочется. Причём ты всё ещё будешь недосягаемо хуже разраба, который каждый день пишет исключительно на тайпскрипте.

Пожалуй, это единственный частично-верный тезис. Новые версии языков, фреймворков, технологий больше не вызывает былого щенячьего восторга. Здесь все просто: бесполезно гнаться за всем и сразу. Выбирайте основную специализацию, а остальные навыки поддерживайте по мере необходимости. Лайфхак: если пару лет не заниматься Реактом, то можно пропустить пару десятков версий и посмотреть state of the art на момент, когда Реакт снова потребуется. Ну завезли туда хуки вместо классов, ну и что такого. Классы же не выпилили с концами, просто стало немодно их использовать. Не надо лезть на амбразуру, бить себя в грудь и бросаться проектировать фронтенд после долгого перерыва. Пообщайтесь с лидом, уточните почему в проекте сделано так, а не эдак. А фронт-лид наверняка может чему-то научиться по беку у вас. Реализуйте свои сильные стороны и просите помощи где вы слабы, а не кройте всех несогласных х-ми по любому поводу и без. Будьте t-shaped (или дуал-классом) и станете фуллстек-синьором или милордом, как больше нравится.