По сути - дилетант широкого профиля
Fullstack разработчики минусуют
02.07.2022, 21:47
Теперь я знаю, что написать в своём резюме, спасибо.
Шутка была отправлена, её понятие на другой стороне UDP не ебёт!
отчасти, соглашусь, но и дилетантов узкого профиля дохуя
Нет, это неправда. Фулстек разработчки - это термин который использует работодатель который не хочет оплачивать узкоспециализированных специалистов и хочет нанять и кузнеца и жнеца и на дуде игреца за ОДНУ ЗП программиста, а потом ебать ему мозг за весь спектр задач.
Не совсем.
Во-первых нужно понимать для чего ты берешь фул-стек. Новый гугл он не напишет, а мелкую CRM осилит. Строго говоря для гугла и не всякий бекэнд-разработчик подойдет для серверной части.
Во-вторых фул-стек -- это список конкретных технологий, а не "знает весь бекэнд и весь фронт". Если человек знает один язык програмирования для бекэнда, один js-фреймворк и скажем хорошо работает именно с mysql -- можно ожидать от него адекватных знаний. Более того скажу что на бекэнде знать "все" тоже анриал. Например на C# есть asp.net (технлогия для сайтов), которая под собой подразумевает почивший asp.net Forms, не менее забытый MVC и актуальный Core с webAPI. Для старого легаси могут искать шарящего в Forms, для нового проекта будут брать человека "посвежее". Ну и в целом если человек говорит что "я бекэнд разработчик знающий C#, JAVA, Ruby, Python, JS Node, C++, C, Fortran, COBOL и Assembler" -- какие шансы что человек знает хоть что-то из перечисленого?
В-третьих "одна зарплата" тут не работает. Скажем проект на 1000 человеко-часов, и предположим что 500 это задачи для фронта и еще 500 для бэка. Если нанять одного человека, то он будет делать это 10 лет, что нахер не уперлось. Если нанять 10 человек, то продукт станет дороже на условные 10% (ибо нужен менеджмент), но выдадут за 1 год. И вот тут основная причина почему берут фул-стек: разделение задач 50/50 в момент написания продукта нет. В определеный момент может быть скоп задач только для фронтенда (либо наоборот), а нанимать/увольнять людей через каждый месяц не получится.
Вообще на любом проекте "знать язык программирования" это где-то только треть от того, что нужно для работы. Еще есть такая фигня как знание функционала (порой его части, так как сложный проект может менятся крупными частями за месяц в разных командах) и архитектуры проекта, опыт как (не) надо делать, организационый вопросы (почему нужно делать ревью, PR, ебаная документация) и умение правильно понять когда "оставляем на потом".
Во-первых нужно понимать для чего ты берешь фул-стек. Новый гугл он не напишет, а мелкую CRM осилит. Строго говоря для гугла и не всякий бекэнд-разработчик подойдет для серверной части.
Во-вторых фул-стек -- это список конкретных технологий, а не "знает весь бекэнд и весь фронт". Если человек знает один язык програмирования для бекэнда, один js-фреймворк и скажем хорошо работает именно с mysql -- можно ожидать от него адекватных знаний. Более того скажу что на бекэнде знать "все" тоже анриал. Например на C# есть asp.net (технлогия для сайтов), которая под собой подразумевает почивший asp.net Forms, не менее забытый MVC и актуальный Core с webAPI. Для старого легаси могут искать шарящего в Forms, для нового проекта будут брать человека "посвежее". Ну и в целом если человек говорит что "я бекэнд разработчик знающий C#, JAVA, Ruby, Python, JS Node, C++, C, Fortran, COBOL и Assembler" -- какие шансы что человек знает хоть что-то из перечисленого?
В-третьих "одна зарплата" тут не работает. Скажем проект на 1000 человеко-часов, и предположим что 500 это задачи для фронта и еще 500 для бэка. Если нанять одного человека, то он будет делать это 10 лет, что нахер не уперлось. Если нанять 10 человек, то продукт станет дороже на условные 10% (ибо нужен менеджмент), но выдадут за 1 год. И вот тут основная причина почему берут фул-стек: разделение задач 50/50 в момент написания продукта нет. В определеный момент может быть скоп задач только для фронтенда (либо наоборот), а нанимать/увольнять людей через каждый месяц не получится.
Вообще на любом проекте "знать язык программирования" это где-то только треть от того, что нужно для работы. Еще есть такая фигня как знание функционала (порой его части, так как сложный проект может менятся крупными частями за месяц в разных командах) и архитектуры проекта, опыт как (не) надо делать, организационый вопросы (почему нужно делать ревью, PR, ебаная документация) и умение правильно понять когда "оставляем на потом".
Чтобы написать коммент, необходимо залогиниться
