Robur

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

Поэтому сначала ревью, потом тестирование.

Если прямо вот так сидят и не хотят переходить - то вводить более строгие правила по обновлению/добавлению библиотек и ноды.

что я бы сделал:
1. составить список проблем.
2. понять какие действия приводят к этим проблемам. Например обновление библиотек/добавление новых
3. написать как можно проверить что эти действия в каждый конкретный момент не сломали все. Например "если вы обновили библиотеку, то надо проверить что все нормально и в винде и на линуксе"
4. подумать как эти проверки сделать удобно. Может быть прикрутить в CI сборку под обе платформы на каждый коммит где затронули package.json, или обновлять либы только в отдельной ветке и просить проверить на другой платформе, и после этого только мержить.

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

В идеале конечно если проверка на то что все собирается под обеими платформами будет автоматическая после каждого коммита.

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

Я за последние 8-10 лет зафейлил большую часть сроков по таскам. Потом понял что проблема в сроках.

беру время с запасом, но часто и того не хватает.

Какой запас? Есть давно выведенный эмпирический закон - оценку опытного разработчика надо умножать на pi, если вы джун и сами время определяете, то 2*pi, если вы хотите работать хардкорно, и 3*pi если более близко к реальности.

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

Надо ставить реальные сроки. Но оценка - одна из самых сложных задач. Если только вы не клепаете конвеером одно и то же. Ну и анализ постфактум, то что реально можно улучшить-изменить, надо исправлять.

И не по теме, как относитесь к медлительным коллегам?

Если работают хорошо и ответственно - то хорошо отношусь, если работают плохо и через жопу то плохо.
Если медлительность объективна - то всегда есть причина и с ней можно поработать. Но не всегда даже и нужно.

Я например могу сделать что-то супербыстро, пока мне объясняют задачу, в стиле "х**к, х**к и в продакшен", но предпочитаю делать дольше но лучше. Поэтому таски закрываю позже чем мог бы, но это такой код и результат, в котором я и окружающие уверены. Он и через полгода будет хорош, и багов в нем на порядок меньше.

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

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

Если вам начинают сроки зажимать до неадекватных - надо разговаривать и объяснять что они неадекватные.

Если вам начинают увеличивать нагрузку и объем работы потому что вы "можете больше", то на это "можете больше" надо просить больше денег/плюшек. при условии что до этого все было адекватно конечно.

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

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

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

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

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

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

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

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

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

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

Собирайте локально, и вместо того чтобы заходить на сервер по ssh, отправляйте туда уже собранное через scp/rsync.
Зачем пушить это в гит чтобы тут же пойти и оттуда достать?