Ivan Bogachev

Как по мне, CCS-in-JS очень специфичная штука, хотя в продакшене можно встретить довольно часто.

Местами, его использование оправдано, например:
- При работе с динамически выделяемыми css свойствами, например когда обычный calc уже не справляется
- При очень сложном динамическом лейауте
- При темизации компонентов и вообще существовании такой концепции как "Тема" внутри вашего проекта.

Тем не менее, минусов как по мне не меньше:
- Проблема кеширования, такие стили не могут быть закешированы, т.к генерируются на лету и требуют того чтобы браузер распарсил ваш компонент и добавил стили в DOM. + Как результат намного больший размер финального бандла проекта.
- Хаос в файлах, когда приходится держать вместе компоненты и их стили. Опять же решаемо, но те проекты которые я видел, которые используют концепцию CSS-in-JS по большей части фигачат обычные статические стили, просто используя js нотацию, а изначально задумка была не в этом. Для такого, давно придумали более эффективные решения.
- Отвратительный DX при дебаггинге.

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

Через strokeDashoffset не получится сделать анимацию рисования пунктирной линии. Можно для линии сделать маску и ее уже анимировать.

Никогда ещё эта картинка не была так кстати!

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

https://paveldogreat.github.io/WebGL-Fluid-Simulation/

А как можно создать REPOSITORY.github.io без создания организации или нового пользователя с названием равным репозиторию?

Никак.

То в в одном проекте на Laravel используется встроенный query builder, то Eloquent

одно другому никак не мешает. тут надо исходить из задач.

Максимально используем встроенный в Фреймворк функционал, так же построители SQL запросов. Типа Eloquent или встроенный query builder.

это верно.

Использовать встроенный шаблонизатор.

это не понятно.

Нельзя использовать в проектах свои самописные модули.

это тоже не понятно.

На самом деле весь регламент сводится к двум вещам:
1. общепринятый код-стайл и требования к документации.
2. все что угодно, что команда считает для себя приемлемым.

например так:

git clone git@github.com:user-name/base-repo.git project-name
cd project-name
git remote remove origin
git remote add origin git@github.com:user-name/project-name.git
git push -u origin master

В приложении должен быть один и только один источник правды. На роль такого источника очень хорошо подходят хранилища состояний, предоставляемые такими библиотеками, как redux/mobx/vuex/...
Если в приложении несколько источников правды, то раньше или позже между ними возникнет конфликт, который приведет к трудноотлаживаемым багам.

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

Я все починил, теперь ваша карьера и ориентация в порядке!
Не благодарите.

Интенсивной работы в день 5-6 часов максимум. Больше - только на ограниченное время, с обязательной компенсацией отдыхом. В офисе 9-18 работают в целом так же, кулер, поболтать, что-то обсудить 10 раз в день, почитать статьи. По моим личным ощущениям на удаленке работа интенсивнее, даже с учетом меньшего количества часов. Поэтому работаю по часам и на ставке больше чем в офисе на 8 часовом рабочем дне.
Пробовал помодоро - не зашло.
Бывает что накапливается и какие-то дни работа вообще не идет - даю себе отдохнуть, могу поработать часа два-три.
Что-то новое изучаю иногда в формате перерывов - поработал - почитал. Так как график и учет времени гибкий, это не считается рабочим временем, и совесть не мучает. Могу посередине дня отдохнуть пару часов если совсем не идет, или сходить прогуляться или еще что.
Свои проекты сначала пилил "по вечерам и выходным", особенно когда работал 9-18 потом понял что так не пойдет, на долгий срок это провальный подход, поэтому сейчас больше работаю как часть рабочего времени. Уменьшаю основную работу (при этом естественно уменьшается доход).

Самое главное - правильно оценить свои силы и исходя из этого решать сколько куда их потратить. Может у вас сил хватит и на работу и на проекты и на хобби и еще перед сном почитать - без проблем, делайте все это. А если их не хватает даже на 8 часовой рабочий день - стоит это признать и не пытаться себя нагрузить сверх меры, получите новый срыв. Или отказаться от чего-то или искать другие способы кроме как "работать больше". Тут главное быть честным с собой и не "добавлять себе очки".

В целом выгорание не зависит от объема работы - объем работы влияет на усталость, на выгорание влияет нервное напряжение и оно может быть и при 2 часах работы в день а может и не быть при 10.
Если у вас реально начинается истощение - то определитесь это усталость или выгорание, если усталость - то организовать рабочее время и контролировать нагрузку, может даже в ущерб доходу, свое состояние очень важно.
Если выгорание - то надо искать причины, если их не устранить - то ничего не поможет.

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

Если картинку скачивает браузер, значит её может скачать кто угодно. То есть - НИКАК!