Full-stack-разработчики. Новый тренд или реальная потребность компаний?

image

По словам Адама Шапли, full-stack разработчики востребованы как никогда, т.к. в компаниях требуют от IT сотрудников целый ряд навыков. Мы в свою очередь тоже замечаем, что все чаще получаем от наших клиентов запросы на поиск full-stack разработчиков.

Если вы разработчик, вы можете быть либо front-end, либо back-end специалистом. На первый взгляд, сосредоточиться на определенных навыках имеет смысл, т.к вы можете представить себя на рынке как эксперт в одной области. Однако полная разработка быстро набирает темпы, и full-stack разработчики становятся очень популярны в некоторых компаниях. Исследование Stack Overflow 2017 показало, что данный тип разработчиков не только самый востребованный, но и самый популярный.

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

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

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

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

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

Какими навыками должен обладать full-stack разработчик?


Такие разработчики должны понимать целый ряд инструментов, языков и систем:
Очень важно понимать HTML / CSS и JavaScript, и, как только вы освоите эти языки, вам понадобится освоить языки для back-end для управления базами данных, аутентификации пользователя и т.д.

SQL и Java пользуются спросом в данный момент — или вы можете изучить Node.js. Затем вам нужно будет понять основы баз данных и веб-хранилищ. Итак, выберите систему баз данных (например, MySQL) и один веб-сервер (например, Apache), а также протокол HTTP и как включить REST в ваши HTTP-вызовы.

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

Как разработчикам получить опыт в full-stack разработке?


Существует множество онлайн-сообществ и курсов, которые помогут вам ускорить работу со всеми упомянутыми технологиями. Например, GitHub — отличный ресурс.

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

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

Как бывает на практике…


Мы работаем с рядом крупных и средних по размеру компаний, и не всегда количество лет опыта в full-stack разработке является критерием выбора кандидата. Так, например, у нас был поиск сильного full-stack разработчика на синиорскую позицию для одной известной компании, хотели человека с большим послужным списком и багажом знаний и опыта. Поиск шел долго, клиент хотел «увидеть рынок» максимально широко прежде, чем принимать решение. Через несколько недель поиска нам удалось по рекомендации одного из кандидатов выйти на юного (с точки зрения опыта) специалиста, который в лучшем случае мог бы претендовать на роль джуна в команде. Тем не менее молодой человек оказался очень хорошо подкован с точки зрения знаний технологий, с легкостью прошел техническое интервью с руководителем, а также продемонстрировал высокий уровень мотивации на работу в этой компании, благодаря чему его таки взяли в команду, хоть и не на грейд старшего специалиста. Так что не только опыт в крутых компаниях, но и знания теории в сочетании с прозрачной мотивацией могут привести к успешному трудоустройству.

В рамках этой статьи мы в общих чертах обрисовали путь к full-stack разработчику, при этом остается вопрос актуальности этого направления. Мы со своей стороны ощущаем потребность в таких специалистах, при этом от кандидатов слышим разные точки зрения: одни считают, что лучше быть экспертом в определённой области (front/back), другие же уверены, что за full-stack разработкой будущее.

Only registered users can participate in poll. Log in, please.

А что думаете вы?

Hays Russia
4.16
Company
Share post

Comments 164

    +4
    Существует множество онлайн-сообществ и курсов, которые помогут вам ускорить работу со всеми упомянутыми технологиями. Например, GitHub — отличный ресурс.

    Серьезно?

      +21
      Я туда заходил, нормальный такой сайт. Исходники разного софта есть, некоторые даже с комментариями. В общем, рекомендую.
        +1
        Надо будет посмотреть как-то…
        0

        Уже хорошо что кадровики про такое слышали :)

          0

          Почему?

            0

            Потому что наши думали что JS и JavaScript разные вещи :(

              +3

              Некоторые наоборот, думают что Java и java Script это одно и тоже

                0

                И что, знание о наличии GitHub как-то помогает в этом вопросе?

                  0
                  Мне один раз кадровик доказывал, что JavaScript — это Java для работы на клиенте, которая даёт пользователю возможность работать с базой данных напрямую, без использования сервера и поэтому ни Java, ни сервера вообще не нужны. Нужен только клиент. После этого я решил не идти на работу в эту компанию.
            +4

            Следует упомянуть один распространённый путь в fool-stack разработчики. Компания периодически сокращает штат, перераспределяя обязанности внутри команды, пока не останется он, fool-stack developer.

              0
              Fool в данном контексте должно относиться к developer, а не к stack :)
                0

                Именно так я и отношу, к себе. Можете в профиле проверить :)

                0
                fool stuck developer
                  0

                  Велик и могуч английский язык! Кстати, есть какая-то непоследовательность — front-end, back-end, но full-stack. Надо тогда уж full end developer.

                    +4

                    Both-end developer.

                0
                Итак, HR-специалисты в двух предложениях рассказывают нам о том, как стать full-stack разработчиком (без каких-либо ссылок на исследования, графиков, обзоров и сравнений, о чем вы вообще?). Потрясающе познавательная статья, спасибо HaysRussia!
                  +6
                  … А еще он должен уметь летать.

                  PS
                  Измученные лица на картинке с тремя программистами, безмолвно кричат: «Бегите, глупцы»)
                  +1
                  Тут от нагрузки зависит. Full stack он обычно может быстро на коленке и все, но не глубоко.
                  Это значит что если у вас проект огромный и ошибка на 0.5% производительности или не сделать нормальную верстку для экзотического браузера — убытки больше ЗП, то вам нужна специализация. Если у вас начальная стадия проекта, трафик около ноля, то тут скорость разработки выходят на первый план. И тут full stack очень хорошо вписывается.
                  В итоге все просто, в большом матером enterprise попытка нанимать full stack — это просто тренд. В небольших компаниях и стартапах — потребность рынка.
                    0
                    Тут от нагрузки зависит. Full stack он обычно может быстро на коленке и все, но не глубоко.

                    Я, пожалуй, возражу. Если не брать в расчет специализацию по какому-то одному продукту (а-ля «разработчик MongoDB с опытом разработки самой MongoDB, или хотя бы контрибьютор проекта Mongoose»), то, ИМХО, нет никаких сложностей освоить оба направления на глубоком профессиональном уровне. Успешный программист ведь обычно всю свою карьеру только и занимается тем, что изучает новые направления и инструменты.
                    +5
                    Это от жмотства такие тенденции. У нас есть еще одна тенденция — попытка набирать разрабов и инженеров инфраструктуры в одном флаконе. Чистый идиотизм на марше.
                      +1
                      Хуже всего то, что они их называют (почему-то) devops-инженерами, даже не понимая что это значит. Раньше их называли админами локахоста и избегали, а теперь ищут…
                        +2
                        Я честно говоря сам не понимаю, откуда такое название. Были всегда инженеры инфраструктуры. Разработчику банально нет времени заниматься инфраструктурой, собирать код в докеры и т.п. Это уже задача инженеров — выкладывать в продакшн, мониторить, смотреть что там с масштабируемостью и т.п.
                          0
                          это отдельная профессия, вообще-то. попробуйте на конференции поездить — там разъяснят.
                          если вкратце, то это мутант, получившийся от скрещивания админа и разработчика. причем может вырасти как из одной профессии, так и из другой.
                          относительно «нет времени» точка зрения крайне субъективная. как по мне — плох тот разработчик, который не понимает как его код запускается. это как писать приложения без знаний что такое JMM. да и курить бамбук со словами «я жду пока мне настроят» как минимум стыдно.
                          кроме того решается еще одна задача — некоторым разработчикам банально страшно давать доступ к критическим ресурсам, а доступ может быть необходим. выполнят по ошибке форматирование диска. имея навыки админа этот человек врятли совершит подобную ошибку.
                          можете подробнее поискать лекцию Димы Чирухина с JPoint2017. Может быть уже открыли всем.
                            0
                            Прошу прощения. Речь об ОЛЕГЕ Чирухине. (headbang)
                              0
                              как по мне — плох тот разработчик, который не понимает как его код запускается. это как писать приложения без знаний что такое JMM. да и курить бамбук со словами «я жду пока мне настроят» как минимум стыдно.

                              Полностью согласен! Это если говорить о небольших проектах с относительно небольшим функционалом.
                              Если говорить о проектах побольше, посложнее и помудрёнее, то там всё не так однозначно и по большому счёту каждому знать как разворачивается продукт было бы лишней информацией. Зачем верстальщику интерфейса знать как разворачивается Django через uwsgi или mod_wsgi? (риторический вопрос)

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

                              Как показывает практика — название профессии на это не влияет. И чаще всего разработчик который делающий «rm -rf /» и код пишет соответствующий.

                              Как по мне, то devops-инженер это либо руководитель проекта, имеющий достаточную компетенцию, либо это что-то вроде fool-stuck`ов в команде до 3-4х человек работающих над маленьким продуктом.
                                0

                                более точное определение дал как раз Олег Чирухин, о котором я выше написал. Это отросток архитектора. архитектор знает большую систему на уровне хай-лвл (по большей части именно в силу объема), девопсы знают как это все связано, то есть являются своеобразными хранителями знания. это НЕ разработчики, но и не админы в общем понимании.


                                Зачем верстальщику интерфейса знать как разворачивается Django через uwsgi или mod_wsgi?

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


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

                          0
                          При чём тут жмотство? Фуллстек программист за единицу времени не делает аналогичную работу фроненд и бекенд программистов за ту же единицу времени. Я не первый раз слышу подобную чушь и ересь, и искренне не понимаю, у вас ребята с логикой всё в порядке?

                          Знать и уметь больше это сегодня не круто и не модно?
                            +2
                            Знать и уметь больше это круто и модно. Вопрос в другом — такого знающего припашут работать ровно за ту же зарплату в двойном обьеме или как минимум захотят и будут требовать. Не сталкивались? Вы счастливый человек.
                              –1
                              Я не зря спросил про логику. Какой ещё двойной объём? Давайте так, допустим вас нанимают на работу программистом и уборщиком, вы всерьёз полагаете, что вам надо будет одновременно заниматься и уборкой и программированием? Если это действительно так, то это маразм. Если вы думаете, что это так, то это тоже маразм. Фуллстек, это значит, грубо говоря, пол дня вы будете делать одно, пол дня другое. А в случае с двумя программистами фронт и бек, пол дня оба будут делать свою работу, и пол дня дружить свои решения друг с другом, именно про это работодатель думает с точки зрения оптимизации, и жлобство тут не при чём ни разу.
                                0
                                Я говорю же — вам повезло с работодателем.
                                  –1
                                  У нас весь коллектив смеялся, когда на собеседовании один кандидат спросил: «а за фуллстек будут платить в двойном объёме?». Учитывая, что в фуллстек коллеги перешли из узкой специализации по собственной инициативе, а начинали некоторые кто с бек, кто с фронт. Просто это банально неудобно, когда ты видишь решение лишь одним глазом. Также разработчиков принято посвящать в детали предметной области и раскрывать им полную картину того, над чем они работают, кому это нужно, как это будут использовать и так далее. Воспринимать разработчика как инструмент с одной резьбой — вот это издевательство.
                                +1
                                Вопрос в другом — такого знающего припашут работать ровно за ту же зарплату в двойном обьеме или как минимум захотят и будут требовать.

                                А почему «в двойном объеме»? В обычном рабочем дне 8 часов. От фуллстеков кто-то где-то требует работать по 16 часов, что ли?
                                  +1

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

                                    0
                                    Я все же думаю, что никакой корреляции между отношением к разработчикам в компании и требованиям к фуллстекам нет. Если в компании задачи в принципе оцениваются по срокам неадекватно, то ваша специализация роли уж точно не играет.
                                      0

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

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

                                          — мне нужен фулстек.
                                          — ок. 200 тысяч.
                                          — но мне только пару кнопок на сайте подправить — половина ваших знаний мне не нужна!
                                          — аааа… ну тогда я буду работать за 30 тысяч.
                                            0
                                            оклад фулстека все же выше

                                            То, что full-stack разработчики много получают — миф. Знать все области на уровне сеньора крайне сложно, это штучные специалисты. Большинство full-stack разработчиков — это широкие мидл. Вот они и получают где-то между мидл и сеньором, ближе к сеньору всё-таки. Данная прибавка лишь отчасти за навыки. В основном, это страховка компании для понижения рисков потерять специалиста, на котором многое завязано. ИМХО.

                                          0
                                          можно сделать за 2 силами двух узких специалистов

                                          Я допускаю, что 2 специалиста могут сделать проект быстрее на 20-30%, но что в 2 раза быстрее… к сожалению не встречал такого.
                                            0
                                            ну что вы… это ведь столь же очевидно, как способность 9 женщин родить ребенка за месяц =)
                              +1
                              А еще очень много совсем мелких стартапов, которым попросту не нужно в штат несколько специалистов по простой причине — не смогут загрузить работой одновременно всех. Тяжелых задач порою у них совсем немного, зато поверхностное знание ML'а, фронтенда и бэкенда в одном лице — именно то, что им нужно для прототипирования.
                                0
                                В стартапах лучше вообще не работать, если ты не совладелец. Ни денег ни перспектив ни гарантий что он не лопнет через месяц.
                                  0
                                  Я более 10 лет работаю исключительно в стартапах, поработал уже в пяти, сейчас иду в шестой. Из этих пяти, один уже не существует (его поглотила другая компания после покупке), у второго закончились денги и он закрылся, третий доживает последние дни. Остальные два отлично себя чувствуют. Везде работал от одного до трех лет.

                                  1. Про деньги
                                  Мне всего один раз платили на 10% ниже рынка (я сам согласился на это, т.к. проект казался очень интересным). И тут я с вами согласен, если предлагают деньги ниже рынка, и ничего не предлагают взамен, то лучше отказаться (но это всего лишь мой личный опыт). Все остальные стартапы платили либо верхнюю планку по рынку, либо выше.

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

                                  3. Про гарантии
                                  Этот момент мне правда не ясен. Если посмотреть на большие компании, то там тоже нет никаких гарантий. Вот недавно Oracle, например, уволил всех кто занимался Solaris, причем просто в один день. Или как Microsoft увольнял тысячами.
                                  С другой стороны поиск работы для хорошего специалиста — неделя, а учитывая что скорее всего после стартапов у людей больше опыта, то и берут на работу их охотнее.

                                  Это конечно же мой личный опыт.
                                    0
                                    Подписываюсь под каждым словом.
                                      0
                                      3. Что не ясно? Стартап лопнул и вы на улице и часто без денег. Всех, кого уволил Oracle — все получили денег небось за полгода или год и спокойно найдут себе новое. Плюс корпоративная пенсия. Ну и когда есть семья начинаешь задумываться, как оно будет…
                                        0
                                        По закону, даже при банкротстве сотрудников все равно должны предупредить за 2 месяца и выплатить всю зарплату, отпускные и эту компенсацию (у меня знакомый бухгалтер сейчас ликвидирует завод и там вот как раз всех потихоньку увольняют со всеми выплатами и процесс этот не разовый, а идет уже пол года).

                                        Ну и опять же, стартап это небольшая компания, врятли получится скрыть проблемы (по опыту, это очень хорошо видно). Ну и конечно же нужно оформляться только в белую и смотреть что у вас правильный оклад, а не оклад в 10тр и все остальное это премия (вашь КО).

                                        И последнее, вы же не от зарплаты до зарплаты живете. Очень важно сделать себе подушку на пару месяцев, всякое бывает.
                                          0
                                          Это по закону. А по факту — например на моей позапрошлой работе выдавили десятки человек за месяц перед годовой премией. А остальные потом сами разбежались. Да, в нормальных компаниях бывает и так как вы пишете, но бывают и ситуации что денег нет и неизвестно где они.

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

                                          Подушка в наших условиях нужна на полгода, а еще лучше год — поиск новой работы даже для разработчиков не всегда быстрое дело (иностранцев на работу берут гораздо туже, чем местное население).
                                            0
                                            выдавили десятки человек за месяц перед годовой премией

                                            Согласитесь, что премия это всетаки не зарплата, а некий бонус который не обязателен.

                                            деньги в стартап приходят раз в месяц из другой страны, где зарегистрирована «основная» компания. И вот они в один день не приходят.

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

                                              По крайней мере в РФ, если премия прописывается в договоре, то и причины по ее невыплате должны быть там. Иначе это уже можно выколупывать через суд.
                                          0
                                          Вот как раз таки в USA по закону вас могут вышвырнуть в течении, ээээ 3 минут. После того как вам сказали что вы уволены вы обязаны встать и уйти.
                                          Все остальное это по желанию компании. А в больших компаниях обычно действуют тупо по букве закона.
                                    +5
                                    а также протокол HTTP и как включить REST в ваши HTTP-вызовы.

                                    простите, что?
                                      0
                                      А вот. Человек, что не умеет включать REST в HTTP не может считаться полноценным фуллстэк-разработчиком.
                                      +2

                                      Frontend+backend — это ни о чём вообще. Настоящие разработчики должны уметь


                                      • Писать frontend (HTML+CSS+JavaScript, labview).
                                      • Писать backend (Python+circuits).
                                      • Настраивать Web‐сервер (nginx) и вообще ОС (Raspbian).
                                      • Разводить печатные платы (Altium).
                                      • Припаивать на них элементы.
                                      • Писать программы для фрезерного станка, вместе с инструкцией для оператора. Потом служить этим самым оператором.
                                      • Уметь скрутить/спаять всё это вместе.
                                      • Писать программы на для микроконтроллеров (C, компилятор «как повезёт»).
                                      • Писать программы для FPGA (labview/VHDL).

                                      С 1989 так существуем и ничего.

                                        0
                                        ничего себе, а кто же тогда допиливает 1с и настраивает комп директору? не набираете же для этого отдельных людей?
                                          0

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

                                        0
                                        Простите мне мою серость, но кто такой Адам Шапли?
                                          0
                                          Ещё можно предложить вариант — фулл стек на фронте. Т.е. выяснение требований -> прототип -> дизайн -> вёрстка -> клиентская логика. Имхо, тоже достаточно востребованный универсал получится, который разом убирает кривотолки, недопонимания и войны между заказчиком-дизайнерами-верстаками-разрабами. Также такой спец сразу сможет внятно рассказать главному архитектору про будущие модели и потоки данных. И также такой спец сможет реализовать крутые спецэффекты, основанные на канвасе или свг, т.к. понимает что и как конкретно нужно отрисовать и как потом с этим работать в коде.
                                          Но такой вариант получается в основном, только когда технический специалист (фронтендщик) решил более глубоко изучить дизайн. А не наоборот из дизайнера во фронтендеры. Много есть мнений, основанных на положительных историях, что хороший дизайнер тот кто обладает техническим образованием, а не художественным.
                                            0

                                            … то есть давайте объединим разработчика с аналитиком? Требования на бэкенд тоже он писать будет?

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

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

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

                                                    Более адекватно, чем кто?


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

                                                    Это работа аналитика, а не разработчика.


                                                    После чего он же сможет более адекватно, чем аналитики/менеджеры/продукт-оунеры

                                                    Почему вы думаете, что разработчик может более адекватно, чем аналитик, выполнить работу аналитика?

                                                      0
                                                      … Чем дизайнер.

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

                                                        То есть вы думаете, что разработчик может делать работу дизайнера лучше, чем дизайнер. Серьезно?


                                                        мой первый пост — это было лишь предположение наделить фронтендера навыками не в сторону бек-а, а в сторону дизайна.

                                                        Во-первых, это отдельная специализация, непростая. Во-вторых, тогда откуда берется сбор требований?

                                                          0
                                                          То есть вы думаете, что разработчик может делать работу дизайнера лучше, чем дизайнер. Серьезно?

                                                          «Работа дизайнера» — это понятие весьма многогранное. Вы какую работу дизайнера имеете в виду?
                                                            0

                                                            Это вопрос не ко мне, а к человеку, который написал "Имел ввиду, что «фулл-стек на фронте» более адекватно [чем дизайнер] сможет выпонить подготовительную работу дизайнера"

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

                                                                А что у вас дизайнер делает между разработчиком и пользователем? Ему там не место.

                                                                  0
                                                                  А что у вас дизайнер делает между разработчиком и пользователем? Ему там не место.

                                                                  А где ему место? Дизайнер, как и все остальные проектировщики, всегда работает между разработчиками и пользователями. Я имею в виду не написание стилей CSS и тому подобные вещи, которые являются частью процесса разработки, и могут делаться параллельно с написанием кода. Я под работой дизайнера подразумеваю проектирование интерфейса и аналогичные штуки, которые делаются до разработки, а не во время. Он может не коммуницировать непосредственно с пользователем. А может и коммуницировать в каких-то случаях. Но так и или иначе, дизайнер в этом процессе все равно лежит на пути проекта от пользователя к разрабам.
                                                                    0
                                                                    А где ему место?

                                                                    Рядом с разработчиком, конечно.


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

                                                                    … а проектировщики — они тоже не работают между разработчиками и пользователями. "Между" могут быть аналитики, продакты и QA. А весь дев-тим — он на одной линейке.


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

                                                                    Эм, итеративная разработка и прочий аджайл, не?

                                                                      0
                                                                      … а проектировщики — они тоже не работают между разработчиками и пользователями. «Между» могут быть аналитики, продакты и QA. А весь дев-тим — он на одной линейке.

                                                                      Разработчик работает с проектом после того, как над ним поработали архитекторы, UX-дизайнеры и т.д. Значит, они все находятся перед разработчиком в той цепочке, которая ведет от хотелок заказчика к получению готового продукта.
                                                                      Эм, итеративная разработка и прочий аджайл, не?

                                                                      Баловство всё это. Если в команде есть чувак, в задачах которого стоит рисовать диаграмки/макеты, по которым другой чувак будет что-то писать, то либо в каждом забеге первый будет работать перед вторым, либо первый не нужен.
                                                                        0

                                                                        Смотрите, как здорово получается. С одной стороны, вы настаиваете на водопадной модели. А с другой стороны, вы считаете, что какие-то ее участки — только, заметим, ей и навязанные — избыточны. Может просто надо модель сменить?

                                                                          0
                                                                          Смотрите, как здорово получается.

                                                                          У меня так здорово не получается. У вас какие-то слишком далеко идущие и неочевидные выводы получились. В какой модели вообще допускается, что проектировщик может работать параллельно с разработчиком? Я имею в виду, естественно, работать параллельно над одной и той же фичей проекта, а не над разными.
                                                                            0
                                                                            В какой модели вообще допускается, что проектировщик может работать параллельно с разработчиком?

                                                                            В той, где emergent design.


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


                                                                            Я уж молчу про такую святую обязанность "проектировщиков" как публичный API.

                                                                              0
                                                                              начали реализовывать, поняли, что что-то не так, поправили архитектуру,

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

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

                                                                                К сожалению, данная нам (мне) в ощущениях реальность такова, что эффективно можно спроектировать архитектуру недели на две. Потом половина требований поменяется и вперед перепроектировать.


                                                                                Так что вопрос из "как бы спроектировать с минимум переделок" давно перешел (для меня, опять же) в "как бы спроектировать, чтобы переделывать было дешево".


                                                                                Сама по себе последовательность работы «проектировщик — разработчик» при этом никуда не делась, и никаких изменений не претерпела. Просто они чаще стали коммуницировать.

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

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

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


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

                                                                И на чем оно основано-то?


                                                                И ещё раз скажу — такому человеку будет проще реализовать крутые интерактивные спецэффекты

                                                                Мда. Дизайн — он не про это немножко.

                                                                0
                                                                То есть вы думаете

                                                                Речь же про full-stack. Это примерно то же самое, что сказать "То есть вы думаете, что фронтенд-разработчик может делать работу бэкенд-разработчика лучше, чем бэкенд-разработчик". В целом может и нет, только разработчики на оба края никуда не денутся.

                                                                  0

                                                                  Неее.


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

                                                  0

                                                  Ниразу не fullstack разработчик. Поясните пожалуйста, а зарплату вы таким как за двоих платите?

                                                    0
                                                    Тоже этого никогда не понимал. За двоих — это только при очень грубом делении на back и front :) У нас, например, только backend может делиться на 3-4 области, каждая со своей спецификой, и требующих отдельных специалистов…
                                                      –4
                                                      Один программист хорошо знает циклы, но не знает условия, другой хорошо знает условия, но не знает циклы. Собеседуете человека на вакансию программиста и желаете, чтобы он умел работать и с циклами и условиями, и попробуйте не рассмеяться ему в лицо на «а зарплату вы таким как за двоих платите?». В общем, детский сад какой-то.
                                                        0
                                                        ну как двоим это перебор, но почему их оклад должен быть как у обычного спеца?
                                                        если человек знает 2 области (реально знает, а не так поверху шуршит) — он более ценный специалист, позволяющий как минимум балансировать нагрузку команды и в совсем идеальном мире знать весь продукт на уровне взаимодействия между компонентами).
                                                        уж молчу о том, что освоение навыков это время и силы. желающие сэкономить работодатели могут брать студента и прививать ему навыки до нужного уровня несколько лет.
                                                        в моей практике бывало, что надо очень активно влезать в чужую область чтобы найти источник проблемы. навыки фронта в этом случае сильно выручали, хотя никогда не позиционировался как фуллстэк. а вот без этих навыков сидел бы и ждал пока придет фронт, сядет рядом и расскажет что же он там такого наворотил. поле для маневра у фуллстэка шире.
                                                        +2
                                                        Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, побросать навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать.

                                                        Специализация — удел насекомых.

                                                        Роберт Хайнлайн, Достаточно времени для любви, 1973

                                                        :)
                                                          0
                                                          Ага, конечно. Врачи, например. Нахрен им специализация, тело одно и все должны делать.
                                                            0
                                                            Уметь не значит постоянно заниматься этим и разбираться в предмете глубоко. Фуллстек программист не обязан иметь глубокие познания во всех сферах разработки абсолютно.

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

                                                              Это уже какая-то маргинальная ситуация.

                                                              Для меня очевидно, что, например, программист, знакомый только с одним языком программирования, с одной ОС, с одной БД — это всего лишь заготовка.

                                                              У меня, например, в активе 5 языков, и ещё столько же в пассиве (то есть если припрёт, смогу что-то написать).

                                                              Но это не значит, что я должен одинаково хорошо разбираться во всех тонкостях JQuery и PL/SQL одновременно. Иметь крепкое представление о том, что происходит вокруг — да, но это другое.

                                                              При этом — да, несмотря на довольно узкую нишу в бэкенде, приходится иногда и JS поправить, и XSLT ковырнуть. Но назвать себя full-stack, тем более выполнять одинаково хорошо всё на всех уровнях — да в пень.
                                                                0
                                                                Не совсем понимаю тогда в чём вы видите проблему. Возможно вам довелось столкнуться с ситуацией, когда вас за одно и тоже время попросили сделать и фронт и бек, что являются лишь дуростью руководства.

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

                                                                Узкая специализация означает, что человек ни морально, ни принципиально не готов покинуть свою вотчину, а в тяжёлых случаях он даже не понимает как оно там на другом берегу вообще работает.
                                                                  0
                                                                  Узкая специализация означает, что человек ни морально, ни принципиально не готов покинуть свою вотчину, а в тяжёлых случаях он даже не понимает как оно там на другом берегу вообще работает.

                                                                  Можно ещё вспомнить о Козьме Пруткове и флюсе :)

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

                                                                  А что подразумевается под full-stack с точки зрения и HR, и работодателей, я плохо представляю. Во всяком случае сейчас. На рубеже веков — да, это было необходимостью :)
                                                                    0
                                                                    Тяжело рассуждать в отрыве от контекста конечно. Но скажите, вы считаете абсурдными утверждения об «двойном объёме работы» для фуллстек программиста или нет? Почему-то именно такой позиции придерживаются «узкие специалисты». Я не понимаю почему. Про пристрастия понятно, это верно даже в отношении стиля кода, библиотек, и т.д.
                                                                      0
                                                                      вы считаете абсурдными утверждения об «двойном объёме работы» для фуллстек программиста или нет

                                                                      Нет, не считаю абсурдным.

                                                                      Потому что именно такие картинки в голове и рисуются: сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.

                                                                      Почему-то именно такой позиции придерживаются «узкие специалисты»

                                                                      Вы не путаете действительно специалистов со студентами-недоучками?
                                                                        0
                                                                        Забавно, что вы видите проблему в том, что некоторые вещи доводятся до абсурда, и сами же это делаете.

                                                                        Даже если опустить абсурдность ваших примеров, ок. Сегодня отфотошопь картинку, завтра положи асфальт. Интересно, а где здесь «двойной объём работы»?
                                                                          0
                                                                          Вы не путаете действительно специалистов со студентами-недоучками?


                                                                          Нет. Почему я должен их путать?
                                                                            0
                                                                            Потому что именно такие картинки в голове и рисуются: сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.

                                                                            Есть некая разница между «сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.» и «сегодня ты сделай REST-сервис, а завтра напиши к нему же форму для просмотра и редактирования». Причем разница принципиальная.
                                                                            0
                                                                            Допустим, проект требует M единиц работы на фронтентде, N на бэкенде, и C на интеграцию. Два специалиста выполнят работу M+C и N+C, один M+N и возможно сэкономит на C. То есть на одного приходится больше работы. В результате один или будет делать в два раза дольше или сэкономит дополнительно на M и N.
                                                                              0
                                                                              Два специалиста выполнят работу M+C и N+C, один M+N и возможно сэкономит на C. То есть на одного приходится больше работы

                                                                              Да, но ведь один потратит, допустим, две недели своего времени на N+M, а те два специалиста потратят на это пусть неделю, но потом их все равно нагрузят какой-то другой работой. Никто же не говорит о том, что бэкэндщикам и фронтэндщикам выделяют больше свободных часов на безделье в оплаченное работодателем время.
                                                                                0
                                                                                Как бы да, но одному тоже другую работу дадут. То есть у них одинаковые условия за исключением того, что один имеет больше знаний и делает всё, а другие только часть. И как-то редко бывает, чтобы сроки увеличивали в 2 раза из-за того что full-stack.

                                                                                Разве что всегда есть разделение — один занимается фронтендом, другой бэкендом, а на другом проекте возможно наоборот. Тогда норм.
                                                                                +1
                                                                                В итоге мы рискуем получить ситуацию, когда работа, которая должна быть проведена в этапе С — документация контрактов, описание API остается только в голове у разработчика. С тем же успехом можно требовать от программиста навыков тестировщика — сам написал, сам протестировал. Экономия же!
                                                                                  0
                                                                                  Документация это вопрос квалификации программиста и организации разработки. Ручное тестирование часто так и делается, до определенного размера проекта. А всякие юнит и функциональные тесты почти всегда пишут сами программисты.
                                                                  0
                                                                  Это кривой перевод?
                                                                    +1
                                                                    Статья ни о чём. На вопрос в заголовке не отвечает. На очевидные соседние вопросы — например, почему именно сейчас? — не отвечает тоже.
                                                                      –1
                                                                      Считаю, что спрос на full-stack спрос будет только увеличиваться. С увеличением уровня доступности информации, на первый план выходят способности к обучению, кто быстрее учится и познает, тот и будет на шаг впереди.
                                                                      Вообще не понимаю деление на front-end, back-end, люди которые умеют писать код и делать продукт, сделают одинаково хорошо и там и там.
                                                                      На личном опыте и не в одной команде видел как люди легко изучали технологии: базовым был C++, потом C#, потом HTML+CSS+javascript.
                                                                      В современном мире нет вопроса знаешь технологию или нет, есть вопрос, за сколько сможешь изучить.
                                                                        0
                                                                        В современном мире нет вопроса знаешь технологию или нет, есть вопрос, за сколько сможешь изучить.

                                                                        Если продукт надо писать сейчас, то очевидно, выгоднее те, кто технологию знают, а не будут изучать. Разве нет?

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

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


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

                                                                            Ага, давайте потратим несколько месяцев (всей команды) на шаринг знаний.

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

                                                                              >Ага, давайте потратим несколько месяцев (всей команды) на шаринг знаний.
                                                                              На самом деле не так много для инвестиций в знания профессионалов.
                                                                              А за какой срок вы создадите сплоченную команду в которой у каждого члена присутствуют нужные навыки?
                                                                              Вы либо никогда не нанимали, либо никогда не работали с профессионалами.
                                                                                +1
                                                                                ммм… эти профессионалы научили вас хамить незнакомым людям?
                                                                                полностью согласен с товарищем выше.
                                                                                то что человек у себя в резюме написал «знаю джаву» не тождественно «могу обучить». если бы все было так просто — дефицита на рынке не было бы. я вот джаву выучил за 2 недели) а последующие 7 лет просто ее доучиваю и оттачиваю. из десятков книг я видел только в одной описание бага банального синглтона на десереализации и путей его обхода. что, студент прочтет их все за неделю и будет знать такие мелочи? поработайте «в поле». а то веет диванным специалистом, чес слово.

                                                                                кроме того вы же сами написали — на собственном опыте ВИДЕЛИ как учат. попробовать не судьба самому? а то как заяц в мультике «вы не правильно топитесь».
                                                                                  0
                                                                                  Если почитаете внимательно слово «торомз» взято в кавычки, просто есть кто быстрее учится, есть кто медленее вы и коллега выше возможно из тех кто медленее, по этому для вас это кажется сложным.
                                                                                  Когда бизнес приходит и говорит, а давайте сделаем шаг резко в сторону и сделаем проект на веб.
                                                                                  ОК — не вопрос. Понятно, что при этом придется читать на работе и в свободное от работы время.
                                                                                  Помимо технологий есть знания ComputerScience, сети, межпроцессное взаимодействие, многопоточность, алгоритмы, паттерны(как в функц языках, так и в императивных) и многое другое.
                                                                                  Глубинные знания нужны если пишется что-то очень platform specific. Но опять таки все знания исходят от проблем, если вы сейчас например займетесь на выбор видеонаблюдением, алгоритмами, ИИ, антивирусами. За пару лет вполне можно получить профессиональные знания чтобы работать на равне
                                                                                    0
                                                                                    ой. еще и психолог. какой разносторонний человек.
                                                                                    уважаемый… у меня стопка грамот (в том числе и всероссийских) побольше, чем вы книжек за жизни прочитали… так что выводы ваши ошибочны. сдайте диплом психолога туда, где «купили» (я вас понял. раз в кавычках — это не считается). учусь я ОЧЕНЬ быстро и на опережение.

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

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

                                                                                  Да, конечно, я тормоз, и мне тяжело учиться. И, конечно, у меня мало опыта. Что еще?


                                                                                  На самом деле не так много для инвестиций в знания профессионалов.

                                                                                  Для проекта с планируемой продолжительностью в три месяца?


                                                                                  Вы либо никогда не нанимали, либо никогда не работали с профессионалами.

                                                                                  Конечно-конечно. Я, правда, создал с нуля отдел разработки в одной неизвестной компании, но, конечно, никогда не нанимал и не работал с профессионалами. И вообще сварщик ненастоящий, маску на свалке нашел.

                                                                                    0
                                                                                    >Для проекта с планируемой продолжительностью в три месяца?
                                                                                    Это не проект, это — дно.
                                                                                      0

                                                                                      Аргументируйте.

                                                                                        0
                                                                                        Потому что качественные и сложные проекты живут намного дольше.
                                                                                          0

                                                                                          Жизнь разработчика не ограничивается "качественными и сложными проектами".

                                                                                            0
                                                                                            Ну вот именно по этому вы и не понимаете востребованность full stack, когда например в IT компании 3-4 человека, которые умудряются писать backend на С++, frontend на html+javascript+css плюс еще и мобильные клиенты. А предыдущие проекты были на Java и C#, Sql и NoSql базы.
                                                                                            И задача состоит не в том, чтобы изучить инструмент, а в том, чтобы решить конкретную задачу не словив при этом какие-то лютые проблемы.

                                                                                              0
                                                                                              Ну вот именно по этому вы и не понимаете востребованность full stack,

                                                                                              Почему же, я вполне понимаю, почему кем-то могут быть востребованы люди, которые пишут хорошо на (одновременно) C++, C#, Java, JS и работают с SQL-а и NoSQL-базами.


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


                                                                                              И задача состоит [...] в том, чтобы решить конкретную задачу не словив при этом какие-то лютые проблемы.

                                                                                              В моей картине мира этот подход плохо сочетается с "качественными и сложными проектами", но что я знаю, с другой стороны?

                                                                                                +1
                                                                                                не в том, чтобы изучить инструмент, а в том, чтобы решить конкретную задачу не словив при этом какие-то лютые проблемы

                                                                                                А, понятно, с таким подходом действительно многие проекты становятся длиной более трех месяцев.

                                                                                0
                                                                                Если продукт надо писать сейчас, то очевидно, выгоднее те, кто технологию знают, а не будут изучать. Разве нет?

                                                                                Странно то, что тут проблема не в изучении. Языки/технологии стали скорее религией для большей части разработчиков. Попросить .net разработчика запилить nodejs приложение… да на тебя как на неверного посмотрят.

                                                                                Я вот в веб разработке параллельно веду два проекта на .net и nodejs, плюс есть pet project на python, так я особой разници между технологиями не вижу. Библиотеки/фреймворки очень похожи, в языках тоже разница минимальна.
                                                                                  0
                                                                                  Адептов религии сразу ф топку ) Есть разные инструменты надо уметь объективно оценивать плюсы/минусы и область применения.
                                                                                    0
                                                                                    Языки/технологии стали скорее религией для большей части разработчиков. Попросить .net разработчика запилить nodejs приложение… да на тебя как на неверного посмотрят.

                                                                                    А при чем тут религия? Вот приходите вы к .net-разработчику в компании, занимающейся .net-разработкой, с предложением "запилить node.js", а он просто оценивает, сколько тулинга придется поменять/добавить, и задает разумный вопрос: а зачем?


                                                                                    Я вот в веб разработке параллельно веду два проекта на .net и nodejs, плюс есть pet project на python, так я особой разници между технологиями не вижу. Библиотеки/фреймворки очень похожи, в языках тоже разница минимальна.

                                                                                    … а если не видите, то зачем использовать больше одного?

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

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

                                                                                        Расскажите это sentyaev, который рассказывает нам, что случается, если "попросить .net разработчика запилить nodejs приложение".

                                                                                          0
                                                                                          В общем случае ничего плохого не случается. JavaScript для .net-разработчика не чужд, научиться пользоваться промисами, и запомнить, что ваш код в nodejs однопоточен и надо избегать длительных методов — это ерунда для любого розовощёкого программиста. А все остальные вопросы легко находятся на stackoverflow.
                                                                                            0

                                                                                            … а нам говорят "на тебя как на неверного посмотрят"

                                                                                            0
                                                                                            Я не знаю кто там что рассказывает. Есть технология, есть её создатели которые создали её в определенных условиях для решения определенной задачи. Если вы понимаете эти условия — значит сможете адекватно применить инструмент. Понимание другого инструмента и умение его применять — означает постижение другой стороны.
                                                                                            Лаир чем больше вы меня минусуете, тем лучше я осознаю универсальность full-stack))
                                                                                              0
                                                                                              Я не знаю кто там что рассказывает.

                                                                                              Да я ж вроде сказал, кто.


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

                                                                                              Для этого, внезапно, надо уметь применять инструмент.

                                                                                          0
                                                                                          А при чем тут религия? Вот приходите вы к .net-разработчику в компании, занимающейся .net-разработкой, с предложением «запилить node.js», а он просто оценивает, сколько тулинга придется поменять/добавить, и задает разумный вопрос: а зачем?

                                                                                          Дело в том, что мне никогда не задавали вопрос «зачем», а сразу крестились и говорили — нет, нет, нет. Далее пример приведу.

                                                                                          … а если не видите, то зачем использовать больше одного?

                                                                                          Разные бывают задачи.

                                                                                          Вот например, пришел я как-то в компанию, а мне и говорят — напиши нам приложение, да такое, чтоб интерфейс был отзывчивый, чтоб такой был богатый, а то у нас очень много табличек и фильтров, и чтоб устанавливать не нужно было, и вообще мы к браузеру уже привыкли, и чтоб не silverlight, а то у нас на нем уже есть одно приложение и мы не знаем что с ним делать (разработчиков не найти), а еще у нас тут другая команда публичный rest-api только-только написала и мы скоро его клиентам предлагать будем.
                                                                                          Посмотрел я на апи, вроде норм, нужный функционал почти весь, чего нет можно и допилить. Ну я и предложил запилить SPA, оно и пишется быстро, да и проверить заодно насколько удобно с этим апи будет интегрироваться. За пару недель слепил прототип, CTO с бизнесом посмотрели, обрадовались. В общем дело пошло. Потом подключили пару ребят, они сначала конечно расстроились, но там был Angular который с Typescript, поэтому они расстроились не сильно, а потом им даже понравилось, но остальные команды смотрели на нас косо и старались избегать как прокаженных.
                                                                                          А теперь про религию. В один прекрасный дождливый Петербуржский денек начало наше приложение вести себя как-то не так. То POST валидацию не пройдет, то значени какое-нибудь в дропдауне не выбирается. Оказалось, что разработчики апи решили уменьшить размер json'ов и вырезали все дефолтные значения. Кинул я клич тим лидам из апи, собрались мы на митинг, и ситуацию эту я им рассказал.
                                                                                          Ответ был таков: «Проблема на твоей стороне.»
                                                                                          Я удивился, но спросил: «Это почему?»
                                                                                          — Потому, что у нас есть враппер апи на .net и там мы дефолтные значения при десериализации получаем.
                                                                                          А я им: «Ну так это понятно, но в javascript-то я так сделать не могу»
                                                                                          А они: «А мы тебе о чем говорим? Это проблема javascript, у нас все ок и включать дефолтные значения мы не будем»

                                                                                          Есть еще пример про то как одно упоминание electron вызвало пол часа флейма на тему какой язык программирования хуже.

                                                                                          А вот пример про надо сейчас. Нужно было написать отдельный сервис быстро за 2-3 недели, и был из свободный только фронтендер. Спросил у него напишет ли он на node.js этот сервис. Он сказал что напишет, и написал. Оказалось сервис нужный, работает отлично, через несколько месяцев решили что нужно развивать его быстрее, а помогать никто не хочет, говорят не будут писать на недоязыке.
                                                                                            0
                                                                                            Дело в том, что мне никогда не задавали вопрос «зачем», а сразу крестились и говорили — нет, нет, нет.

                                                                                            Ну значит вам не повезло с собеседниками. Сочувствую.


                                                                                            Кинул я клич тим лидам из апи, собрались мы на митинг, и ситуацию эту я им рассказал.
                                                                                            Ответ был таков: «Проблема на твоей стороне.»
                                                                                            Я удивился, но спросил: «Это почему?»
                                                                                            — Потому, что у нас есть враппер апи на .net и там мы дефолтные значения при десериализации получаем.
                                                                                            А я им: «Ну так это понятно, но в javascript-то я так сделать не могу»
                                                                                            А они: «А мы тебе о чем говорим? Это проблема javascript, у нас все ок и включать дефолтные значения мы не будем»

                                                                                            … и где тут религия? Вы выбрали инструмент, который по вашим же словам чего-то не может, почему это проблема другой стороны?


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


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

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

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

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


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

                                                                                                  0
                                                                                                  Я же специально не обсуждаю квалификацию таких разработчиков, это тема отдельного большого спора, например вот.

                                                                                                  … который протух шесть лет назад. Спасибо, нет.

                                                                                                  0
                                                                                                  Эм, а чего вы хотели

                                                                                                  Я же изначально высказал мнение о том, что проблема не в изучении.
                                                                                                  Мне вот грустно, что вместо программистов, большинство компаний нанимает .net разработчиков, js разработчиков (да потставьте любой язык или фреймворк).
                                                                                                  И вместо того чтобы изучать базовые вещи как алгоритмы, структуры данных, паттерны и т.д. изучают .net, java, angular и т.д.
                                                                                                  Ведь «архитектура» приложения или системы не зависит от платформы/языка/фреймворка.

                                                                                                    0
                                                                                                    Я же изначально высказал мнение о том, что проблема не в изучении.

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


                                                                                                    И вместо того чтобы изучать базовые вещи как алгоритмы, структуры данных, паттерны и т.д. изучают .net, java, angular и т.д.

                                                                                                    … а будут изучать "фул-стек". Станет лучше?


                                                                                                    Ведь «архитектура» приложения или системы не зависит от платформы/языка/фреймворка.

                                                                                                    Это немножко неправда.

                                                                                                      0
                                                                                                      Это немножко неправда.

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

                                                                                                      Так в чем же моя неправда? Или мы просто о разном?
                                                                                                        0
                                                                                                        В зависимости от языка вы будете по разному делать валидацию, авторизацию, кэширование?

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

                                                                                                          0
                                                                                                          Да я другое имел ввиду.
                                                                                                          Валидация — грубо говоря проверять кол-во букв или диапазон значений.
                                                                                                          Авторизация — можно получить данные или нет.
                                                                                                          Кэширование — что-то вроде in-process или out-of-process.

                                                                                                          Или, например, есть «маленькая» разница между платформами, где один запрос — один процесс, много запросов на один процесс и, например, акторами.

                                                                                                          Это добавит/убавит какое-то количество инфраструктурного кода, но именно на «архитектуту системы» влияния не окажет.
                                                                                                          Все равно будут теже модули, и даже фунции/методы будут называться очень похоже.
                                                                                                            0
                                                                                                            Валидация — грубо говоря проверять кол-во букв или диапазон значений.
                                                                                                            Авторизация — можно получить данные или нет.
                                                                                                            Кэширование — что-то вроде in-process или out-of-process.

                                                                                                            Ну так это все и будет отличаться в функциональном и нефункциональном стилях.


                                                                                                            Это добавит/убавит какое-то количество инфраструктурного кода, но именно на «архитектуту системы» влияния не окажет.

                                                                                                            Да ну? Когда у вас много запросов на процесс, вы можете держать shared data в этом процессе. А когда у вас один запрос на процесс, вам надо shared data куда-то положить. Вот вам и еще один компонент.

                                                                                          0

                                                                                          Вопрос ведь не в том, чтобы изучить, а в поддержке знаний на актуальном уровне. И чем шире область твоих знаний, тем больше с этим проблем. Изучить новое не задача, проблема в том, кто будет поддерживать твоё изученное старое. И вот здесь крупным компаниям и нужен fool-stack для того, чтобы легаси код продолжал скрипеть с минимальными затратами. В моём случае это T-SQL, C#, VBScript, JScript, JavaScript, XSLT, CSS и небольшой палеозоопарк фреймворков и библиотек.


                                                                                          Есть другой full-stack, который на фрилансе клепает типовые сайты магазинов, например. Как правило, это PHP + WordPress + CSS + JQuery или что-то вроде того. Вполне достойная работа.


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

                                                                                          0
                                                                                          В защиту фулстеков.
                                                                                          Фулстэк в основном, по моему опыту, это не про стартапы и продукты, а про корпоративщину.
                                                                                          Причем профиль компаний мало связанный с IT.
                                                                                          Почему? Краеугольный камень — время.
                                                                                          Зачастую, компания для своих внутренних нужд необходимы люди, для которых не надо ТЗ, максимум обсуждение на митинге.
                                                                                          Никаких ПМ-ов, лидов и архитекторов, вообще. Между тобой и заказчиком только кружка кофе.
                                                                                          У меня 80% задач ставятся даже не письменно, а устно, например:
                                                                                          — Помнишь проект ХХХ? Вот надо сделать также, только в другую сторону от контрагентов, ок? В пятницу тестируем. — или
                                                                                          — Видел ХХХ, ты глянь в исходниках как написали YYY, нам нужно вырезать его в виде нового проекта под другие нужды.
                                                                                          Короче, делаем новый UI, переносим данные на новую структуру, делаем синхронизацию в обе стороны, 4 дня хватит? — Вот и все ТЗ (последнее тз этого утра). Ты сам в голове видишь и UI, и данные, и бэкэнд.
                                                                                          Сам выбираешь технологии. Бизнесу наплевать, что ты там используешь, Angular + NodeJS или React + C#, хоть JQuery + PHP. Ему важен результат, сейчас.
                                                                                          Хуяк-хуяк и в продакшн, но с максимальной, личной отвественностью. За ошибки бьют очень и очень больно.
                                                                                          Слово рефакторинг под запретом, совсем, ну дома если хочешь посиди, поковыряй.
                                                                                          На такие позиции берут именно таких людей, которым не надо ТЗ, не надо описывать как оно должно выглядеть, как должно функционировать, и он должен делать это быстро и качественно.
                                                                                          Все остальное — красиво, много, долго, внешний и очень важный продукт, это отдается на аутсорс.
                                                                                          Если проект по плану меньше полугода, то отдается внутренним фулстекам.
                                                                                          В нашей компании в данный момент 4 фулстек разработчика и ни одного фронтэндщика, хотя мы честно пытались нанять уже два года как и не смогли.
                                                                                          Все уходили, им не понятно как так можно работать.
                                                                                            +1

                                                                                            В чём выгода такого full-stack для бизнеса в лице менеджеров понятно. Но раз уж это слово в защиту. Зачем начинающим программистам стремиться к такому "счастью"?

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

                                                                                                Программисты любят решать задачи, это так. Отсюда совсем не следует предпочтение full-stack. Большие задачи проще решать группой.


                                                                                                Выбор технологий самим разработчиком — во многом миф. Потому что "краеугольный камень — время", "хуяк-хуяк и в продакшн", "глянь в исходниках", "результат сейчас", "рефакторинг под запретом" и т.п… Но иногда случается. Тогда к нашему зверинцу добавляется новый зверёк :)

                                                                                                  –1
                                                                                                  Большие задачи проще решать группой.

                                                                                                  Я так и написал.
                                                                                                  Все остальное — красиво, много, долго, внешний и очень важный продукт, это отдается на аутсорc


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

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

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

                                                                                                Ну смотря как напишешь.
                                                                                                отвечать за чужие ошибки (кто-то поменял функцию, а сломалось у тебя)

                                                                                                Опять же, проект твой и только твой.
                                                                                                А понятие фуллстек тут ни при чем.

                                                                                                Вы похоже не читали, что я написал. Совсем.
                                                                                                  0
                                                                                                  Значит что-то сам не спросил, или не понял. Дело в разработчике.

                                                                                                  Да-да-да, всегда виноват исполнитель.


                                                                                                  Проблема в том, что телепатию завезли не всем, а работа аналитиком — она, того, сложная.

                                                                                                    0
                                                                                                    Тут есть тонкость. Именно этого качества и ждут таких разработчиков.
                                                                                                    Которым, или такого ТЗ достаточно для работы над проектом, или они задолбают вопросами заказчика до полного понимания проекта.
                                                                                                    Я сам когда опять вернулся на фулстек, с проектов где есть фронт/бэк, аналитики, пм-ы, архитекторы и преферанс с тестировщиками, очень по этому поводу переживал. Но это как ездить на велосипеде, быстро вспоминаешь как это.
                                                                                                    Даже было такое — заказчик нанял аналитиков (ввел в штат), чтобы описали ТЗ, пока они писали, требования менялись и менялись, аналитики писали и писали. И пока они писали ТЗ, конкурент, который начал разработку после нас (наш топ на конференции похвастался проектом), выпустил свой сервис, а мы нет.
                                                                                                      +2
                                                                                                      Тут есть тонкость. Именно этого качества и ждут таких разработчиков.

                                                                                                      "Этого качества" — это телепатии? Ну давайте я вам расскажу, как это бывает:


                                                                                                      Которым [...] такого ТЗ достаточно для работы над проектом

                                                                                                      "Конечно, такого ТЗ достаточно для работы над проектом," — думает наш программист, и идет делать "как в проекте XXX, но для проекта YYY с мелкими правками по месту". Все начинается с того, что проект XXX делал гениальный разработчик, уволившийся два года назад и уехавший в Австралию. И, поскольку он гениальный, он делал его на собственном диалекте лиспа (он все на нем делал, потому что ему так было удобно). Никаких требований на XXX нет, никаких тестов тоже нет, есть только исходники на этом прекрасном языке. Потом внезапно выясняется, что между XXX и YYY общего только автокомплит в формочке ввода адреса, который и имели в виду под "сделай как", но совершенно забыли сказать, что раньше адреса были по КЛАДРу, а теперь по ФИАС, и системы автозагрузки ФИАС, конечно, нет (и она входит в доработку). А, да, и еще забыли сказать, что все это делается только в защищенной системе обмена секретными данными, доступ к тестовой среде которой оформляется за два месяца.


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


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


                                                                                                      они задолбают вопросами заказчика до полного понимания проекта.

                                                                                                      … ключевое слово в котором "задолбают". Заказчик не любит быть задолбан. У него есть бизнес, который его задалбывает, ему не хочется, чтобы его еще и задалбывали программисты, которые денег не приносят, а только жрут. И тем более он не любит, когда эти программисты сомневаются в каждом его слове, переспрашивают по четыре раза, а потом говорят, что это предложение противоречит сказанному пять минут назад. Оно не противоречит, оно дополняет. Просто посмотрите на проблему с другой стороны. И еще прочитайте ФЗ-18, ФЗ-46 и ФЗ-282 (только обязательно свежую редакцию). И вот эти методические рекомендации, в них все написано. Они, правда, через месяц сменятся на новые, но вы же успеете закончить раньше, правда?


                                                                                                      [...]


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

                                                                                                        +1
                                                                                                        требования менялись и менялись… конкурент, который начал разработку после нас, выпустил свой сервис, а мы нет.

                                                                                                        Может у него требования не менялись?)

                                                                                                      +1
                                                                                                      Ты сам разработчик своего проекта, откуда там чужой код?

                                                                                                      А вдруг ты уволишься? Что делать компании? Она пойдёт к условной "Hays Russia" и попросит найти им full-stack разработчика. Зачем компании это понятно. Зачем молодому программисту в это вляпываться?


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

                                                                                                        +2
                                                                                                        Значит что-то сам не спросил, или не понял. Дело в разработчике.

                                                                                                        "Я же спрашивал у вас про то-то и то-то, вы сказали не надо — Не помню ничего такого, я тебе наверно про другое говорил". Что именно еще должен был спросить разработчик, если уже получил ответ, что не надо?


                                                                                                        ???? Ты сам разработчик своего проекта, откуда там чужой код?

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


                                                                                                        Ну смотря как напишешь.

                                                                                                        Ну как, без ТЗ и рефакторинг под запретом. А на тесты времени нет.


                                                                                                        Опять же, проект твой и только твой.

                                                                                                        Опять же, это может поменяться.
                                                                                                        Но да, если проекты настолько маленькие, то можно и так работать, если нравится. Только это не пример для подражания.


                                                                                                        Вы похоже не читали, что я написал. Совсем.

                                                                                                        Прочитал и не согласен с вашим определением full-stack програмиста. Full-stack != бардак.

                                                                                                    0

                                                                                                    Какой ему срок и подробный паек,
                                                                                                    конечно, особый вопрос,
                                                                                                    Но скверно, что он ни пехота, ни флот,
                                                                                                    ни к этим, ни к тем не прирос,
                                                                                                    Болтается, будто он дуромфродит,
                                                                                                    диковинный солдоматрос.

                                                                                                    (Р. Киплинг)

                                                                                                      +1

                                                                                                      Про себя в последнее время шучу: full-stack embedded developer :-)


                                                                                                      Прошивка на железо (ARM, правда FPGA часть всё же не я делаю) + Софт на PC /Windows, macOS, Linux/. Ну и ещё частично функционал PM, CM и технического писателя.


                                                                                                      Но это неплохо, пока ты работаешь в рамках одного продукта. Сейчас частично начинаю переключаться на другие проекты, если на одном ещё стек технологий перекрывается, то на втором уже другая архитектура появляется (C51), а на третьем вообще Android (драйвера, медиа стек, плюс раньше никогда с ним дела не имел). В общем голова малость начинает плыть.

                                                                                                      Only users with full accounts can post comments. Log in, please.