Все в этом мире работает по принципу Pump and Dump)
Даже эта статья вероятно написана, чтобы завлечь новичков на телеграм-канал, где закулисный инвестор, закупив предварительно дешевых монеток, всех агитирует устроить PnD этих коинов, ждет когда участники группы закупятся и сливает свои монеты)

А на какую циферку смотреть там надо?

Вопрос не в наличии проектов, а в страсти к программированию. Считаю вполне нормальным не иметь желания кодить по 16 часов в сутки, а заниматься этим лишь на работе. Собственные проекты — это конечно обязательно (как портфолио), если рабочий код показать не можешь и планируешь собеседоваться, но отсутствие pull requests считаю не критическим фактором, ибо не всем нравится идея свободного ПО (лично я предпочитаю коммерческие продукты)

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

Типичное заблуждение)
Если я люблю есть сладкое, это не значит, что я буду его есть ежедневно по килограмму. Я в восторге от шоколада, но не готов питаться только им)

А без вуза фундаментальные знания получить нельзя?)
Ну и основная масса вакансий по программированию не предполагает наличия глубоких знаний у соискателя (1С и CMS). Нужен просто человек, который сможет обслуживать и сопровождать систему.

Вы меня извините, но в комментариях гремучая смесь снобизма, позерства и проявлений однобокого мышления. Те, кто кичится своим высшим образованием, фундаментальной базой и умением системно мыслить — где ваш научный подход к исследованию вопроса? Человек утверждает, что ему образование не нужно — протестируйте его знания и сделайте вывод. Оперируйте фактами, а не домыслами и стереотипами, якобы только вуз способен сформировать правильное мышление. Есть немало людей, что разбираются в алгоритмах на высоком уровне и без образования, как и масса выпускников престижных вузов, не способных отличить linked list от array.

И снова повторю любимую фразу программистов: it depends…

Вот не соглашусь с вами.
Мне всегда нравилось программирование, но в мои юные годы небыло ни интернета ни компьютеров особо. Первый ПК у меня появился в 16 лет и я начал изучать MS-DOS и Assembler. Небыло в то время в свободном доступе ни информации ни видосов на ютубе, как сейчас, в следствие чего программирование осталось лишь как хобби, а основную профессию выбрал в иной сфере (тогда менеджеры, экономисты и юристы в тренде были). И теперь по вашему получается, что все, кому не повезло родиться во времена высокоскоростного интернета и общедоступной информации, обречены работать по выбранной в до-айтишную эпоху профессии и не стремиться попасть в отрасль что им действительно нравится?

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

Проблема в том, что те кто назначает зарплаты врачам — не лечится в России)
А простой народ… ну так подорожник в полях растет)

50 процентов статей — это пиар)
Себя, своей библиотеки, предмета своего обожания.
Остальные 50 процентов: переводы чужого пиара)

… А еще он должен уметь летать.

PS
Измученные лица на картинке с тремя программистами, безмолвно кричат: «Бегите, глупцы»)

С вертикальным ритмом есть две основные проблемы: тег small и img:

1) У вас базовая высота линии 24px, размер шрифта параграфа — 14px. Следовательно, чтобы ритм не сбивался, необходимо у small сохранять высоту линии и уменьшать размер шрифта. В браузере small имеет размер 0,8 относительно базового font-size. В нашем случае это составит около 10px и тогда межстрочное расстояние чрезмерно увеличивается.

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

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

Абсолютно не согласен. Получается пустой лист бумаги — это также дизайн система. Он будет развиваться вместе с проектом и постепенно наполняться)

Документирование и приведение примеров построения интерфейсов по вашей дизайн системе позволяет наладить мост между разработчиками и UI дизайнерами

Я попросил пример построения интерфейса, но в ответ услышал лишь «дизайн система не может быть перенесена в браузер».
Разговор у нас шел в контексте веб-дизайна, поэтому должно быть очевидно, что Фроста упомянул именно в этом качестве.
Давайте так: скажите, что по вашему есть дизайн система и за что я плачу деньги, когда нанимаю человека ее создать? Что за продукт я получаю в итоге?
Картинку с кнопочками по сетке?

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

Что такое сервисное руководство и UX-составляющая?)
Дизайн-система создается, в первую очередь, для унификации UI и чтобы дать разработчикам библиотеку готовых паттернов. Вот так примерно это выглядит на схеме от Брэда Фроста, одного из первых людей, кто стал продвигать идею дизайн-систем в массы:

У автора поста я не увидел системы. Не увидел полноценный продукт.
У Гугла есть material design style guide. Вот это полноценная дизайн система. Там описано как это должно работать на разных устройствах, как элементы перестраиваются при смене ширины браузера, сколько миллисекунд длится анимация на каждом устройстве и так далее. Я задал вполне уместный и элементарный вопрос — как создатель системы продумал адаптивность. Если он планирует только рисовать кнопочки, то это не система, а обычный UI Kit)

А как работает взаимодействие через object?
Если «стекло разбивается», то значит можно через условный hover менять цвет линий SVG иконки?

Я говорю о другом: в конечном итоге эта дизайн-система будет переноситься в браузер (не будем рассматривать вариант с другими платформами). Как Вы предлагаете в браузере реализовывать эту систему? Есть лишь два пути — растягивать клетки (fluid) или переключать артборды (adaptive) через брейкпоинты в медиа-запросах. Первый вариант нам не подходит, судя по всему. Остается второй. Что делать с артбордом на ширине экрана в 500px? Центрировать или прижимать к левой/правой стороне экрана?

Сначала меня удивило, как так аккуратно получился у Вас вертикальный ритм при высоте линии в 24px и размере шрифта 14px. А теперь понял — это скрины с редактора, типа Sketch. Там высотой линии считается расстояние между базовыми линиями соседних строк (интерлиньяж). В CSS все это работает немного иначе: текст центрируется по вертикали внутри линии, а следовательно в браузуре не получится уже так красиво.

Я еще давно писал в Adobe и создателям Sketch, просил добавить в редакторы браузерный line-height, чтобы на макете было сразу видно как он отобразиться в браузере, но никакого ответа так и не получил… А фича то очень актуальная.