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

Заказчик не называет это словом «качество», а говорит «экономия». Следим за логической цепочкой:

1. качество это удовлетворение потребностей клиента
2. фулл стек не может сделать качество, потому что ему не хватает знаний, код полон багов и/или нереализованного функционала
3. продукт не качественный

Функционал либо удовлетворяет ожиданиям клиента, либо нет, и абсолютно всё равно сколько он вложил денег.

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

применение аналогий в качестве аргумента — классика демагогии

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

почему количество терапевтов значительно превышает количество узкоспециализированных кардиохирургов?

нужно закрывать дыры?

и зачем вообще нужен младший медицинский персонал?

я думаю на этом можно прийти к консенсусу ― фулл стек это младший «мед.» персонал, который занимается поддержкой, залатыванием, но никак не «лечением»

медики между собой часто исключают хирургов — из врачей.

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

позаказная разработка.

читай аутсорс/фриланс

1. не к чему придраться, придерусь к орфографии
2.

отношение фукционала к затратам. чем это отношение выше — тем продукт качественней.

― бред сивой кобылы. Качество с любой позиции это способность удовлетворять обусловленные или предполагаемые потребности потребителя. Функционал либо удовлетворяет ожиданиям клиента, либо нет, и абсолютно всё равно сколько он вложил денег.

Тезис выше про экономию, а не про качество. Вспоминаем:
media1.tenor.com/...​0482f7b941c5a6e/tenor.gif

Сколько бы терапевтов (фулл стек в мире медицины) вы не взяли на сложную операцию на сердце, КАЧЕСТВЕННЕЕ сделает узкопрофильный кардиохирург.

увольнять их и нанимать двух бекендеров?

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

Из моего опыта общения с зарубежными продуктовыми компаниями:

• Full stack === специалист про всё и ни про что. Таких берут на поддержку или допиливание продукта, когда мало денег.
• Почти всегда стараются находить узконаправленных специалистов, чтобы делать качество, а не количество.
• Тайтлом «full stack» там не гордятся, и в резюме такого не пишут ― это считается дурным тоном. Обычно рассказывают про опыт в front-end и back-end, но позиционируют себя в одном направлении.

Full stack разработчик ― явление популярное в outsource, потому что заказчики сюда приходят не тратить деньги. Как говорилось в самой статье:

умеет делать все, но недостаточно хорошо

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

Для этого можно нанять двух разных специалистов или одного Full Stack разработчика. Последний вариант позволяет сэкономить время на коммуникацию

...и деньги на зп

mon.gov.ua/...​ya/osnovni-zminy 2019.pdf

проєкт, проєкція
(так само як ін’єкція, траєкторія, об’єкт та інші слова з латинським коренем -ject-)

figmaplugins.slack.com

Наличие опыта в open source не гарантирует увеличение инвойса, но повышает шансы получения работы. Остается только подавать резюме на вакансии с х2, х3, х4 ЗП. То есть не бывает такого, что ты приходишь на собеседование на позицию за 5k, рассказываешь про свою жизнь на GitHub и получаешь новый оффер на 10k. Вывод — ходить на собеседования на 10k.

Примеры из реальной жизни № 1
Собеседование на JS бекенд разработчика, в украинскую аутсорс компанию. Упомянув что я активный контрибьютор в Node.js, мы пропустили вопросы а-ля «как устроен eventloop» и перешли сразу к более узконапраленным вопросам по проекту. После обсуждения деталей конкретно их реализации и вопроса «есть желание работать с таким?» техническое собеседование было пройдено.

Пример из реальной жизни № 2
Собеседование на JS разработчика в зарубежный стартап.
История почти повторилась, только мне не пришлось ничего упоминать, потому что Senior, который меня собеседовал, нашел меня в репозитории Node.js

Спасибі, цей коментар органічно доповнює статтю 👍
Погоджуся, є така ложка дьогтю, але для мене вона виглядає досить незначною, можливо через мій оптимізм

🤗

dou.ua/...​rums/topic/27013/#1567046

> Пріоритет ПОВИНЕН визначатись шляхом поділу версії на мажорний, мінорний, патч та передрелізний
... шляхом поділу версії на мажорнУ, мінорнУ, патчевУ та передрелізнУ («версія» — іменник жіночого роду)

Тут мова не про версію, а про ідентифікатор:
Пріоритет ПОВИНЕН визначатись шляхом поділу версії на мажорний, мінорний, патч та передрелізний ідентифікатори

Дуже дякую за детальний розбір. Додам всі зміни протягом декількох днів

Переводить нужно, вопрос только в том «МАЖОРНА» vs «другое слово»

Насчет официального стиля пожалуй соглашусь

Додав два пункти крім «НЕ БАЖАНО», бо не впевнений, що без приставки «НЕ» слова матимуть такий самий сенс. Наприклад:

БАЖАНО та НЕ БАЖАНО
СЛІД та НЕ СЛІД
ВАРТО та НЕ ВАРТО

Как насчет:

У світі управління програмним забезпеченням існує таке поняття, як «dependency hell» (пекло залежностей).