Я именно тот 40+ летний синглстек, который упоминался в нашумевшей статье. Когда я вижу таск, где бэкендер упоминает dTo, к которому нужно написать обвязку на фронте… Я запланировано выхожу из себя. Во-первых, я хорошо работаю, когда злой. А тут такой случай. А во-вторых (и это главное), я не хочу знать, что такое ДэТэО, где оно лежит и как с ним работать. Мне нужен только путь, метод, параметры и набор ответа. В терминах HTTP/REST. Я не хочу лезть в код бэка. Я даже не хочу догадываться о том, что исходя из имени класса dTo, можно легко вычислить путь.

Это вопрос уважения. Я не лезу в кухню бэка. А когда сам ставлю задачу на бэк, то чётко расписываю интерфейс (опять же в терминах REST) и кратко описываю, зачем оно мне надо и как собираюсь использовать. Как это реализуют на бэке – это не моё дело, как я реализую работу фронта и где расставлю кнопки – не их.

Вы уже поняли, о чём пойдёт речь в статье? Так вот – немного не о том. Я работаю синглом. Но на самом деле, я мультистек. Притом работал и давал результат сеньором и тимлидом во фронте, бэке, фуллстеке, системном и даже бизнес-анализе. И рад, что у меня такой бэкграунд.

Что в нём хорошего, и как я до такого дошёл под катом.

Поехали.


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

Я считаю, что при возможности стоит поработать в нескольких областях. Особенно в молодости, когда мозги незабитые, и нет ответственности перед семьёй и детьми. Тем более, что при смене стаза почти не теряешь в зарплате, а в долговременной перспективе только выигрываешь.

P.S. Я пишу в основном о сеньорах, но всё можно спустить и на ступень ниже (у меня мало опыта работы мидлом).

PPS. Я использую термины технология и платформа (как синонимы), для языка программирования и/или фреймворка. Это не случайно в контексте статьи. «Глубокое знание языка» часто ничто, перед глубоким и практичным знанием библиотек (возможно, если не брать LISP/Hackel или С++ с извращениями). Поэтому скажем Python+Hadoop, Python+CV и Python+ML – это разные технологии/платформы, на мой вкус. Конечно, часто люди имеющие знания в компьютерном зрении, как минимум, интересуются машинным обучением, а то и распределёнными вычислениями. Но… чтобы стать классным специалистом на этих трёх платформах, совсем не достаточно быть спецом на одной.

  • Знания устаревают
  • Привычка учиться
  • Диверсификация
  • хайп
  • Целое помогает частностям

Итак.

Время жизни технологии


Любая технология живёт в среднем 5 лет* (*фантазии Автора). Потом либо её вытесняет что-то другое. Либо технология переходит на версию 2.0, декларативно идеологически совместимую с предыдущей, а не самом деле…

На самом деле, приходится учиться заново. Более того: приходится ломать себя, отказываться от комфортных наработок и привычной логики. Это больно, сложно и бесит. Когда простая задача (в версии 1.0), в версии 2.0 требует адских костылей и тонны кода. Потом, конечно, обнаруживаешь, что задачу можно было решить более чем просто. Проще, чем в 1.0. Просто не так, как привык.

В любом случае, есть пятилетний цикл, за который знания и наработки порядком обесцениваются. Поэтому, в разработке постоянно приходится учиться. Бежать, чтобы только оставаться на месте, как а «Алисе в стране чудес». Остановился, отстал и востребованность падает.

И что обидно, что учиться приходится рывками. Сидишь себе, кодишь без роздыху, нарабатываешь приемы, изучаешь тонкие фичи и «стандартные хаки». А там… раз! Новая версия. И половина знаний уже не нужна потенциальным работодателям. А значит, и со своим работодателем будет сложно построить разговор, начинающийся с: «тут на рынке такая ситуация …»

Ибо это будет чистый блеф. Ведь на нынешней работе, продолжают успешно и активно использовать некогда хайповую платформу. Которая постепенно становится дерьмом мамонта. И ты становишься всё более и более классным специалистом… по дерьму мамонта. С перспективами только в разгребании оного, которого в мире становится всё меньше и меньше (но не на твоей текущей работе).

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

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

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

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

Следовательно, работодатели готовы потерпеть и непрогнозируемые задержки от граблей и возможную боль от костылей. И готовы брать на сеньорские позиции текущих миддлов с расчётом, что они быстро вырастут. Особенно, если эти миддлы уже бывали сеньорами и показывали результаты. Поэтому собеседования часто не по технологиям, а потому, что раньше делали, какие проблемы были и как решали* (*Автор так думал на момент начала работы над статьёй, потом походил по собеседованиям с «напишите сортировку на листочке» и сейчас в задумчивости).

И в этот момент, можно сделать хитрый финт ухом. Взять и не пойти работать на платформу 2.0. Можно поискать (и найти работу!) на совсем другой платформе.

Да ну! Бред же, скажете. Так не бывает. Хмм,… я много раз так делал. И, в отличие от героев известного телешоу, у меня получалось.

Да, иногда, приходится жертвовать з/п или возможной прибавкой к ней. Да, нужно потратить время на изучение технологии и попробовать хоть что-то поделать. Придётся знатно побегать по собеседованиям и получить пачку отказов. Но рано или поздно работу находишь… Кстати, несколько раз было, что те, кто сперва мне отказывали – потом неоднократно перезванивали и заманивали разными плюшками.

Теперь вопрос – а зачем таки менять платформу? Самое вкусное оставлю под конец статьи, но и тут есть что сказать.

Что лежит на поверхности:

  • безнадёжное устаревание технологии или выход технологии из «зоны хайпа»
  • банальная скука и замыленность

Просто через какое-то время технология, приносившая надёжный хлеб с маслом и икрой, может сдуться. Да так мощно, что и на хлеб ей заработать непросто. А то и не сдуться, а фактически помереть. И часто это нам демонстрируют в ещё институте, устраивая обучение некроплатформам. Я в 96 году застал Clipper и Supercalc (начал было писать, что это такое, но написав огромный абзац, стёр его – статья таки не по археологии, а ещё в 96году, оба эти продукта надо было преподавать археологам). А мы вместо того, чтобы усвоить урок (что ничто не вечно в IT) бурчали на преподавателей-дерьмомамонтоведов.

И даже если технология далека от смерти, она может просто выйти из «зоны хайпа». То есть рынок может массово отказаться от технологии и перейти на что-то иное. Я даже не буду приводить примеры – сами можете вспомнить их массу, даже если в IT всего пару-тройку лет.

В случае, если технология «померла», теряешь в зарплате и становится сложно найти работу.

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

Выход тут один – выбирать из «пула хайпа» наиболее интересную для себя платформу и нырять в неё с головой. И это менее сложно, чем пытаться выжимать профит из стремительно устаревающих знаний и умений (мой опыт говорит так). И, что самое забавное, это интересно. Приходится напрягать мозги: читать, разбираться, формировать инструменты и решения под свои задачи. Меня от такого часто просто прёт не по-детски. И, заметьте, этот квест за деньги работодателя.

Да иногда, бывает, что новая технология совсем не заходит. Постоянно втыкаешься в барьеры и ограничения технологии. Но изучение нового, как минимум в 2 из 3 случаев – это гораздо интереснее «клепания формочек».

Дело в том, что на той работе, где ты давно, где тебя любят и уважают, есть одна проблема – колея. Ты сам её построил и имеешь с неё много гитик. Знаешь, как работает система, наработаны приёмы и инструменты, которые позволяют её расширять пусть не бесконечно, но в горизонте года точно. Знаешь, что планирует бизнес, знаешь какие новые системы будут сделаны на основе твоих разработок (бизнес любит готовые быстрые решения) и…
И это … скучно. Потому что колея. По которой бизнес мчит в финансовые дали, а ты просто обеспечиваешь поступательное движение локомотива ну и, иногда, капитальный ремонт… привокзального буфета.

И даже если ты поменяешь работу, но не сменишь технологию, то… Вот ты приходишь на новое место, где люди пытаются делать смесь фуникулёра с броненосцем. А тут ты: давайте не будем подвешивать рельсы на секвойях (тем более, что пока не все секвойи выросли). Лучше используем шпалы типоразмером А1* (*реальный типоразмер) и рельсы марки МТ-ЛБ-70РХ* (*случайный набор букв и цифр). Можно быстро сделать узкоколеечку для прототипа, потом, если что, перешьём полотно.

Все дружно удивляются, вдохновляются, аплодируют. Назначают тебя главной рок-звездой и идут пилить секвойи на шпалы указанного типоразмера. А тебе… уже на этом этапе становится скучно. Ты-то шёл делать фуникулёр, но он не нужен для перевозки угля и палок. И ты опять строишь привычную колею, разве чуть в ином пейзаже.

На самом деле, наработанные решения – очень круто. Для бизнеса. Работодатель внезапно получает то, о чём влажно грезил долгое время. И осыпает тебя если не плюшками, то безмерным уважением. Да, это тоже то, что стоит ощутить в жизни. Но, опять же, скука и … ограниченный горизонт для использования «солидных наработок». Бизнес готов использовать и очень устаревшие решения, если они дадут быстрый профит. Но тоже до поры до времени.
Я, попадая в долговременную колею, замечал за собой резкое снижение продуктивности и мозговой активности. Меня любят, ценят,… а мне приходится со скрипом заставлять себя работать.

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

Хотя… ладно, по-противоречу сам себе. Работа в колее, несколько напрягает меня лично, поскольку привык быстро думать и принимать решения (пусть не всегда верные). Мне нравится решать задачи. Находить крутые или хитро-компромиссные решения, а то и с понтом предлагать заколачивать костыли (оговариваясь, что вообще-то так нельзя). А вот реализовывать решение – это уже скучновато.

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

Однако, при работе в колее у рок-звёзд (я нескромен) заметно падает результативность, просто потому, что для успешной работы (в колее) нельзя полностью сосредотачиваться на работе. Нужна параллельная мотивация. И начальство начинает косить глазом: как так? На некоторые фичи уходит столько же времени, за сколько запилен прототип, сразу же ушедший в прод. К этому нужно относиться с пониманием или опять же… думать о смене работы.

Привычка учиться и любопытство


Разработчику приходится учиться постоянно. Да, это относится к любой профессии. Помню про тоже самое мне говорил стоматолог. Но стоматолог вряд ли столкнётся с ситуацией, когда в течение пары лет 80% клиник внезапно перейдёт на квазерный портализатор вместо бормашины. А за место у оставшихся бормашин (не выкидывать же) хитрые работодатели будут платить гроши.

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

Мозг, это единственный орган, способный развиваться в любом возрасте. И по скорости развития (и, к сожалению, деградации) делает любой бицепс как Ту-160 воробья.

И чем больше нагрузка, тем лучше форма (до определенного предела, конечно). Обучение новому – это как раз вид нагрузки, который наиболее благоприятен мозгу. Чтобы сравнить: это как таскать мешки с картошкой на даче или «вес» в тренажёрке. Нагрузки по объёму сопоставимы, а по «вкусовым ощущениям» — нет. Ну, если ты не садоводофил, конечно.

И чем больше учишься, тем лучше оно получается. Плюс, во время тотального обучения не удаётся работать на всю катушку – в какой-то момент не хватает матчасти и приходится сменять «пахоту» на гайды. Это как раз даёт отдых мозгу от совсем не полезных однообразных нагрузок, особенно в авральном режиме. Я, разбирая свой код, написанный в режиме 60-80 часовой рабочей недели, был в неком удивлении. От того, что не использовал не только новых, но вообще любых известных мне инструментов, которые не имели мощной наработанности. Не было ресурсов мозга не только на то, чтобы подучить, а хотя бы вспомнить. Ну, кроме тех вещей, без которых вообще никак нельзя было продвинуться.

Как говорят многие институтские преподаватели: высшее образование даёт две вещи – терминологию, чтобы разговаривать со специалистами и… умение учиться. Но последнее, не навсегда, а пока им пользуешься.

Да глубокому специалисту по идее могут платить больше, чем широкому, но мест с мегазарплатой для «узких» мало. А вот «широкие» легко находят работу, потому то и выбор есть и жаба не душит, если зарплата «всего лишь немного выше рынка».

Диверсифицирование себя любимого


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

И это не только шанс поменять стаз, но и сделать это без отрыва от производства. И, возможно, получить зарплатный/карьерный рост или долю в бизнесе. Просто потому что в команде не было бэка/фронта/дата-сайентиста, тебе было интересно попробовать, а люди были рады, что кто-то хотя бы попробует.

Я уже упоминал раньше про грабли и костыли. Ценность и рост специалиста – это владение инструментом. Без хождения по граблям роста не будет, хоть обчитайся умными книжками и гайдами.

И последнее по порядку, но не по значеию


Делая часть, часто полезно представлять целое. Если у тебя есть опыт работы с бэкендер, то работая фронтом ты лучше представляешь, что ты можешь получит/отдать серверу. Что для тебя легко сделают, а что потребует серьёзных усилий. Бэкендер с опытом фронта лучше понимает, какие данные и в каком виде ждёт от него фронтендер.

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

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

Плюс вожделенная для многих возможность.

Возможность работы фулл-стеком


О! Фуллстек – это круто. Звучит. Сразу представляешь как мир ложится к твоим ногам, очередь работодателей уходит за горизонт, девушки улыбаются на улице, а в качалке берешь вес на 30кг больше. На деле чуть-чуть не так.

Основная ниша фуллстека это маленькие фирмы и маленькие проекты. Да, часто маленькие по объёму, но не по важности. Где ты царь и бог всего кода. Сам сделал фронт, сам сделал мидл и сам запилил базу данных. И тут возможно два варианта:

  • тебя взяли на вырост системы
  • работодателя всё устраивает

И то и другое имеет перспективы. В первом случае, если бизнес попрёт, то, скорее всего ты станешь тимлидом. Хотя ситуации бывают разные, пара моих коллег искали себе падаванов, а находили начальников. Но, скорее всего, тимлидом останется человек, имеющий максимум знаний о системе, если у него есть хоть какие-то лидерские и организаторские способности. Ссно – вот и рост.

Во втором случае можно запилить ляльку и прозябать на поддержке. Работа не бей лежачего, но начальство не в курсе, что зарплаты в IT постоянно растут. А если и будет в курсе, то будет делать вид, что не в курсе. Но, если система действительно краеугольная для бизнеса, а бизнес адекватный, то чтобы не терять ключевого (и единственного специалиста) тебе могут сделать предложение… От которого сложно отказаться. Варианты, по возрастающей мотивации:

  • лояльный полудомашний график работы
  • з/п выше рыночной
  • доля в доходах
  • отрежут пальцы, если вздумаешь уйти

Но последнее встречается редко, хотя я слышал из первых рук такую ситуацию. Но, в итоге, пальцы резать не стали, пугали только. Скучно.

Собственно работа фуллстека может приносить много-много рулезов, но…

Немного горечи


Пришло время вишенки на торте. Но в моей вишенке синильной кислоты немного больше нормы.

И вот в чём дело. Переключение контекста. То, о чём мы очень любим говорить, когда летим по срокам во взятых задачах. Во всех двух взятых задачах. А оно и на самом деле существует. И больнее всего бьёт по фулстекам.

Наибольшие зарплаты, самая интересная работа и быстрый карьерный рост на переднем крае. Когда ты выходишь на грань неизвестного и начинаешь делать что-то, что вроде пока ещё никто не делал (ну или делал, но не писал про это в интернетах). Когда бизнес хочет чего-то, имеет на это деньги, но не знает, как оно должно выглядеть и иногда даже как именно работать. Либо когда у тебя противоречивые требования к интерфейсу и/или системе. И для того, чтобы продвинутся, нужно находить какие-то нестандартные ходы и решения.

В такой ситуации ты рано или поздно начинаешь биться в стену. Те самые противоречивые требования. Скорость против гибкости. Понятность против достаточности. Тут либо делать костыль на костыле в надежде когда-нибудь придти и разгрести. Либо уходить глубоко в творческий поиск, пробовать разные варианты и ждать озарения. А в реальности рулит баланс костылестроений и озарений. Но если костыли выигрывают с разгромным счётом, то проект становится мертворождённым. Поэтому так важны озарения.

А вот они обычно приходят, когда глубоко погружаешься в тему. Со всем контекстом. Необязательно всё время сидеть за монитором или над листами бумаги. Если ты погружен глубоко, то часто приходит фея-халява вся работа идёт в бэкграунде, а ты можешь просто гулять, кататься на велике, играть в хоккей, заниматься сексом, находиться в запое,… И щёлк! И вот оно – решение, такое просто и очевидное.

Но чем больше контекста ты переключаешь, тем озарений меньше. Поэтому судьба фулстека – это либо крепкие средние продукы, либо перекосы в одной из частей. Гениальный фронт и средний бэк, летающий бэк и косяки на фронте. Либо и то и другое огонь, но сроки летят.
Плюс проклятые буридановы ослы. Которые ходя вокруг тебя и пихают под руку, то под правую, то под левую: давай это лучше на фронте запилим, а нет-нет, на бэке будет лучше. Повбивал бы.

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

Выводы


Я ни на чем не настаиваю* (*наглая ложь). Но по мне опыт и важность фулстековости несколько переоценены. А мультистековость наоборот фатально недооценена. Но владение несколькими аспектами разработки – это большой плюс. За это не будут отдельно доплачивать, да и на собеседованиях это не всегда даст серьёзное преимущество. Но работать становится веселее и проще. Кроме того можно всегда утереть нос понтующимся коллегам бэкендерам/фронтендерам в доброй дружеской беседе под пиво или борщ. И да, я сам рассматривая резюме считаю опыт в нескольких стеках плюсом (если он серьёзный) и вам того же советую.

Мне нравилось менять технологии, узнавать что-то новое. И это почти не сказывается на зарплате.

Да, и в статье я немного наезжаю на фуллсттеков. На самом деле, когда я начинал писать статью (точнее через месяц после того как я вернулся к первым наброскам) у меня был прекрасный преоффер на фуллстека. Прекрасный всем, кроме з/п, по которой мы так и не договорились. А я так надеялся написать про фулстеков гадостей, а в конце статьи сказать, что я таки теперь фулстек. Но, увы, фронтенды рулят* (*по результатам моей мании величия и текущего основного стека).

Комментарии (56)


  1. JustDont
    11.06.2019 12:35
    +1

    Спасибо за статью. Да, всё так. Сам такой же, выводы о профессиональном росте и специализации сделал (последние — лет 6 назад) именно такие.


  1. HanryCase
    11.06.2019 12:55
    +1

    Я далеко не сеньер, но все же думаю чо фулстек это плохо, нельзя знать всего, а с циклом технологии в 3-5 лет тем более. Сам такой внутреннее любопытство постоянно двигает меня вперед, поработал в свое время экономистом, аналитиком, админом, бекендером, сейчас делаю фронт. Плохо когда фронтендер не понимает как работает бекенд или наоборот. Что бы достичь понимания надо сделать пару задач(проектов) на фронте\беке. Развиваться надо во одном направлении, но с пониманием смежных областей, например, если ты фронт, помимо понимания бека, надо еще понимать бизнес на который работаешь, его внутренние чаяния, желания, процессы итд.


    1. Spunreal
      11.06.2019 16:36
      +1

      Это относится не только разработчикам. То, что вы описали, это концепция T-Shaped скиллов — en.wikipedia.org/wiki/T-shaped_skills


      1. mclander Автор
        11.06.2019 16:56

        Спасибо интересно


  1. DexterHD
    11.06.2019 12:59
    +1

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

    Учить на мой взгляд нужно фундаментальные вещи, такие как: Архитектура Современных Компьютеров, Операционные Системы, Сети, Базы данных, Принципы построения языков программирования, Архитектуру ПО, Системный анализ, etc…

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

    С этим пониманием с одной технологии/платформы/стека на другую при надобности вы сможете перескочить в промежутке 1-ого года.

    К тому же в таком случае не будет подобного рода проблемм:

    А во-вторых (и это главное), я не хочу знать, что такое ДэТэО, где оно лежит и как с ним работать. Мне нужен только путь, метод, параметры и набор ответа. В терминах HTTP/REST.
    Потому что и DTO и REST и HTTP — термины вне технологий вне фронтэнда/бэкэнда, вне языков программирования.


    1. mclander Автор
      11.06.2019 13:06

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


      Иногда раньше иногда позже. Все зависит от того, есть ли в текущей команде хорошие практики или надо до них доходить самому.


    1. retran
      11.06.2019 13:10
      +2

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


      1. mclander Автор
        11.06.2019 13:12

        Ну фронт и бэк есть и у десктопных клиентов

        Плюс разные роли скажем аналитик и программист, но могут быть два в одном )


        1. retran
          11.06.2019 13:40

          Ну фронт и бэк есть и у десктопных клиентов


          Настолько разные, что «десктопный фронт» и «десктопный бэк» стали «типа разными» профессиями?


          1. mclander Автор
            11.06.2019 13:45

            Всё зависит от величины проекта, а больших проектах есть разделение по функциям разработки. И грязными лапами в бд не всем дозволяется ковыряться)


            1. retran
              11.06.2019 15:04

              Вы не ответили на мой вопрос.
              К слову, что такое «бэк десктопного клиента»?

              Мне кажется, вы опять пытаетесь свести вопрос к очень ограниченному подмножеству проектов и отвечаете в рамках этого подмножества. Я же как раз говорю, что не надо так делать.

              Например, я работаю в десктопном проект на ~20кк строк (достаточно большой?) и у нас нет базы данных (реляционной во всяком случае).


              1. mclander Автор
                11.06.2019 15:33

                Если в вашем проекте нет разделения ролей это не значит, что во всех проектах так. Вот взять граф редактор, кто-то делает ui, кто-то работой с файлами разных форматов, кто-то с плагинами для обработки картинки. И все являются крутыми, но узкими специалистами. Фронт бэк — это всего лишь роли, они могут быть и называться как угодно. В проекте также все могут быть универсалами, но это зависит и от проекта и от людей


                1. retran
                  11.06.2019 15:42

                  … и вы начинаете противоречить собственной же статье.

                  UPD Я повторю вопрос — все эти роли настолько разные и требуют настолько разного набора знаний, что вырождаются в отдельные профессии, как это происходит в вебе, и требуют написания таких статей?


                  1. mclander Автор
                    11.06.2019 15:50

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

                    Вы критикуете термины бэк и фронт, но это просто хороший пример разных стеков.


                    1. retran
                      11.06.2019 18:24

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

                      Причем тут вообще энтерпрайз и машинное обучение если вы же говорите о стеках?


                    1. retran
                      11.06.2019 18:26

                      К слову, что же все-таки такое «бэк десктопного клиента»?


                      1. lexey111
                        11.06.2019 19:13

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

                        1) Десктоп-клиент держит в себе встроенный веб-сервер, к которому подключаются браузером саб-клиенты для специальных задач.

                        2) Да собственно апп-сервер и есть бэк декстопа в multitier, нормальная практика, хоть и устаревшая по нынешним временам.


                        1. retran
                          11.06.2019 19:33

                          1) Так десктоп-клиент имеет бэк, или он реализует бэкенд для других клиентов?

                          2) Бэкенд в multitier — это просто бэкенд.


                          1. lexey111
                            11.06.2019 19:41

                            1) Почему «или»? «и». Имеет бэк (пул апп-серверов и за ним субд-сервера) и сам является бэком для веб-клиентов (планшетов).

                            2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.

                            И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).


                            1. retran
                              11.06.2019 19:55

                              Дело в том, что бэкенд не является частью клиента. Суть архитектуры клиент-сервер в separation of concerns. Соответственно, да, бэкенд может быть ДЛЯ клиента, но он никоим образом не является частью клиента и здесь нет никаких значимых различий с вебом.

                              А теперь смотрим на исходное сообщения, к которому я привязался с целью выяснить что же все таки понимает под фронтендом и бэкендом автор статьи:

                              Ну фронт и бэк есть и у десктопных клиентов


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

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

                              И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).


                              Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?


                              1. lexey111
                                11.06.2019 20:12

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


                                Да чёрт его знает, у меня уже ощущение, что мы все говорим об одном и том же, но спотыкаемся на терминологии.

                                Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?


                                Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).


                                1. retran
                                  11.06.2019 20:19

                                  Не очень понимаю, что вам мешает на C++ рисовать формочки, а на Delphi писать dll. И даже класть формочки в dll. И что тут извратного и принципиально разного?


                                  1. lexey111
                                    11.06.2019 20:36
                                    +1

                                    Ну, например, VCL, наличие и качество компонентов и удобство RAD. А также разница в скорости билда сибилдера и дельфи — дело было в ранних 2000х, на всякий случай, тогда это было очень-очень заметно. В приципе dll и сервисы писались у нас тогда время от времени и на Delphi, но для кросс-платформенных модулей вариантов, прямо скажем, было немного.

                                    А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…

                                    И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.

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


                                    1. retran
                                      11.06.2019 20:44

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


                                      1. lexey111
                                        11.06.2019 20:52
                                        +1

                                        … а человек, разбирающийся (действительно разбирающийся) в фундаменталке, называется евангелистом и к практической работе его лучше не допускать. Хотя для всяких PoC он реально незаменим.

                                        Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.

                                        Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)


                                        1. retran
                                          11.06.2019 21:11

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


                                          1. mclander Автор
                                            11.06.2019 22:40

                                            Проблема не в фундаменте проблема в деталях. Человек в фундаменталкой сделает все хорошо, человек с наработанностью ещё и быстро. Плюс чтение кода. Есть общепринятые идиомы и лайв хаки. Погруженный спец их читает влет. У меня 7 лет программирования на перл. Но меня $ и @ бьют по глазам после перерыва. Неделя погружения. И они лучшие друзья


                      1. VolCh
                        12.06.2019 11:01
                        +1

                        Если клиент построен на принципах близких к MVC, то M — бэк


                        1. mclander Автор
                          12.06.2019 11:57

                          Ага, у меня в голове что то такое крутилось, но сформулировать не смог)


                        1. retran
                          13.06.2019 13:02

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

                          Но диалог пошел по другой ветке.


      1. S-e-n
        11.06.2019 13:13
        +1

        Ну тогда уж и понимать, что не все работают в энтерпрайзе.


        1. retran
          11.06.2019 13:40

          А причем тут энтерпрайз?


          1. S-e-n
            11.06.2019 14:32
            +1

            К тому что в энтерпрайзе также существует множество ролей, не существующих вне его.

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


            1. retran
              11.06.2019 15:04

              Соглашусь.


  1. Peter03
    11.06.2019 16:14

    у меня мало опыта работы мидлом
    Можно раскрыть детали? Реально интересно, без подколов.
    Основная ниша фуллстека это маленькие фирмы и маленькие проекты.
    И бодишопы, чтобы продать можно было куда угодно и за больше денег.
    Но по мне опыт и важность фулстековости несколько переоценены. А мультистековость наоборот фатально недооценена.
    С моей точки зрения «мультистековость» надо как призыв в армию, обязать поработать админом, тестером, в операционной поддержке и матёрое легаси сопровождать. И только потом в разработчики, ясность взгляда и память о пережитых мучениях будет всю оставшуюся жизнь делать тебя лучше.


    1. mclander Автор
      11.06.2019 16:55

      1. Я очень быстро вырастал до сеньора. Поэтому мидлом быть не успевал, даже когда усраивался вроде как мидлом.
      2. Не понял
      3. Админом нафиг — настроить чтот могу, когда нет на кого свалить, само тестером приходится быть. Но это не то чем нравится заниматься. Поэтому и не призываю, к тому что не люблю сам. Но это немного другое.


      1. Peter03
        11.06.2019 17:06

        1. Вырастал до сеньора по должности? или по факту?

        2. Вы никогда в бодишопе не работали? Там где тебя продают консалтером к клиенту. Там как раз ценится пойти в любой проект на любую позицию. Так что если ты фуллстек, тебя можно продать куда хочешь, на любое направление. Меньше сидишь на бенче, больше прибыль.

        3. Так я не про то что люблю или нет, а про то что это расширит кругозор для того чтобы стать хорошим разработчиком.


        1. mclander Автор
          11.06.2019 17:28

          1. И по факту и по должности. По факту на тебя наваливают как на сеньора, как только понимают, что ты тащишь. А по должности фиксируют, что на тебя можно столько валить, чтоб продолжал тащить.
          2. Настолько нет, но в одной конторе был и аналитиком и разработчиком вебприложений и разработчиком низкоуровневых библиотек. Практически не сходя с одного этажа.
          3. Тоже верно, но тут совсем другие приёмы и склад ума. Хорошие админы часто отлично программируют, но вот попытки заюзать их в пользовательских приложениях… Мрак и угар, угар и мрак.


  1. vagon333
    11.06.2019 16:42

    Понимаю позицию автора, но не принимаю.

    Для меня full stack, это прежде всего увлекательная работа, когда просыпаешься с мыслями о решении сложных задач.
    Мне важно понимать большую картину, насколько эффективно решается задача, где мы лажаемся с архитектурой или организацией, как исправить и вписаться в сроки и спецификацию.
    По моему опыту, когда каждый работает строго по спецификации, без понимания большой картины, происходят over-engineering и gaps.

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


    1. mclander Автор
      11.06.2019 16:47

      Если бы я претендовал на истину, писал бы не спорные статьи, а учебники.


      Спасибо за мнение.


  1. dss_kalika
    11.06.2019 16:59

    Любая технология живёт в среднем 5 лет* (*фантазии Автора).

    Каждый раз когда я это читаю я слышу как у меня за спиной улыбается начальник SQL-разработки…


    1. Rusty_Fox
      11.06.2019 19:22

      Тоже хотел написать про SQL. Как раз имею бекграунд именно в области СУБД. Со временем пришло понимание, что много где могут закрыть глаза на пробелы в знании определенных технологий за вменяемое понимание основы большинства проектов — базу данных.


      1. mclander Автор
        12.06.2019 12:06

        Согласен, но посмотрите на обрастание БД фичами. Да таблицы и индексы 40 лет не менялись, но когда идёт борьба за производительность, знание новых специфических фич рулит


        1. dss_kalika
          13.06.2019 11:11
          +1

          Там этих фич — одна в пять лет. И то — сомнительная )
          Правильно и по канонам построенная архитектура (по канонам 15-летней давности) решает практически все проблемы с производительностью.

          Неправильно построенную — костыли из фич надолго не спасут.


          1. mclander Автор
            13.06.2019 11:38

            Моя любимая поговорка "реальные данные всё испортили". Если проект приносит денежку, то он начинает обрастать всякой фигней. Которая может разрастись и по объёму и по нагрузке. И банальных индексов уже не хватает. Нужно денормализовывать таблицы, плодить обвязку, использовать кэши БД и хитро выраженные индексы последних версий. У меня коллега очередного оракла ждал как маны небесной, поскольку там была какая-то кукарямба, решавшая его проблемы из коробки.


            Но в целом да, прямые руки и архитектура без хаков востребована всегда и не только в БД


    1. mclander Автор
      12.06.2019 12:03
      +1

      Ключевое слово в среднем)


  1. evilelf
    11.06.2019 17:18

    у меня мало опыта работы мидлом

    сеньором видимо тоже не много


    1. mclander Автор
      11.06.2019 17:19

      Видимо, да)


  1. darkfriend
    11.06.2019 17:18

    У меня полностью отличается мнение от автора.
    Я мультистек-разработчик, работаю в большой компании и занимаюсь 3 хайлоад (~15k rps каждый) проектами. Являюсь одним из важнейших членов команды.

    Я считаю, что люди разные, одни любят развиваться и учиться, другие нет.
    Те кто не любит развиваться/учиться, обычно всеми силами пытаются это хоть как-то оправдать.

    Каждый синглстек — это тот самый чувак на заводе, который так и продолжает крутить свою гайку для Лады (но уже в программировании).


    1. mclander Автор
      11.06.2019 17:19

      Ну я примерно о том же и писал)


  1. SbWereWolf
    11.06.2019 17:44
    +1

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


  1. Exponent
    11.06.2019 18:17

    Тоже девелопер 40+, думал в 23 когда начинал что в 40 уже молодые меня заменят, а я останусь без работы, но оказалось что система подоготовки специалистов за это время стала хуже и работы за глаза. Тоже пробовал делать диверсификацию и в дополнение к .net платформе изучил и java. Тоже получаю удовольствие от того как делаю, а не что делаю. Автор прав насчет колеи, попадешь в такой проект и останавливаешься в развитии. Счас взялся за reactjs, очень много работы предлагают.


    1. arheops
      11.06.2019 21:00

      Система подготовки не лучше и не хуже.
      Скорее даже лучше, ибо больше материалов.
      Просто у вас 17 лет стажа, а у них — 2. Вспомните себя, посмотрите на ваши решения тех лет(хоть что-то работает еще?)
      У меня, например, самая старая развернутая система — 15 лет и там мрак с мой сегодняшней точки зрения.


  1. dempfi
    12.06.2019 00:17

    Очень смущает ваша точка зрения о существовании какого-то сеньорити в рамках конкретной технологии/платформы. Быть сеньором не значит иметь глубокие знания в конкретной технологии. Сеньоры с глубокими знаниями в конкретных технологиях просто встречаются сильно чаще именно потому что они сеньоры (как антропный принцип). Вообще говоря, я уверен что можно быть сеньором не обладая глубокими знаниями ни в одной технологии/платформе, а обладая знаниями в математике CS и культуре работы в цикле ресерч -> продукт.


    По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.


    Более интересный путь развития о котором я очень мало слышу, но в который верю — это прокачка понимания культуры программирования и решение бизнес-проблем через нее. С логически последовательной культурой программирования можно построить и поддерживать успешный (с точки зрения разработки) продукт в новой для себя области без каких-либо знаний технологий в этой области.


  1. mclander Автор
    12.06.2019 12:18

    1. Так и есть. Сеньор человек, который во вменяемые сроки решает сложную задачу самостоятельно. Знать тему глубоко не обязательно, если можно решить простыми приёмами, пусть не оптимально по коду и производительности.


    2. К сожалению, общее понимание бизнес процессов и реализации это тема расплывчатая. Такому не учат потому что это слишком сложно. Когда вы понимаете бизнес процесс, это не значит, что сможете его автоматизировать, поскольку есть ограничения текущей реализации. И каждый раз они свои. И пониманию этих ограничений, и возможностей КОРРЕКТНО их обойти, как раз способствует "работа на земле". У меня бывало, продашь бэкенду идею сделать так чтобы мне хорошо было. Они: да ну, это костыль. А у вас как, вот так? Да! Ну так это у вас костыль, не? Ой!



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


    1. VolCh
      12.06.2019 17:12

      Для начала неплохо знать вообще о существовании бизнес-процессов в принципе и понимания, что многие, если не все, операции принадлежать одному или нескольким. А то налепят CRUD интерфейсов и "вот все данные учтены — что хотите с ними, то и делайте".