Вопрос тимлидам

Хорошо что ты не такой

я ж говорю, хорошо что ты выше этого
good for you

Лям в гривнах сейчас любой помидор делает.

1) Никого вообще не штрафуют, потому что человек сразу увольняется, и вместе с ним — все, кто про такое услышал.
2) Первый 3 месяца любой программист только вникает в проект, и выгоды с него мало.
3) Джун будет вникать не 3 месяца, а 6 или 9, и потом еще допускать глупые ошибки. И все это время — спрашивать разное странное у окружающих, чем отрывает их от дела.
Поэтому обычно (всякое бывает — бывают и очень толковые джуны) найм джуна тормозит проект.

Те, кто чистят — уволятся.

Хотя модели можно и извлечь из голов сеньоров и хранить, скажем, на SSD

В банке с формалином.

Rust был такой идеей. Не получается. Большая часть ошибок — из-за того, что правила «правильности» настолько сложные, что никто их не может держать в голове, или сформулировать. Для всей программы целиком. Поэтому делают по модулям, а эти модули могут не слепиться в кучу. Или один модуль ожидает от второго одно, а второй делает навыворот. Или если птица накакает — у статуи рука отваливается, а без птицы — держится.

когда 1000 простых правил — это невозможно понять

Если бы ты еще придумал план, как ему выбраться из жопы — было бы вообще супер!

По закону Брукса найм любого человека тормозит проект, а в критический момент приводит его к коллапсу.

не мое, но и правда — правда

Есть только одна роскошь

Роскошь человеческого общения.

не важно кто задал вопрос.
например на доу мой нышний акк моложе на лет 5 предыдущего.

важннее — кто отвечающие.

я вас помню, по другим темам :)
не специально, а просто — толковое писали, поэтому — за вас и в этой теме, и поэтому из п 2 :)

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

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

я не о себе, и каких либо регалиях, зарплаатх, крупных проектах, и прочих фаангах.

Мнение — хоть просто в коде, больше 100 строк, — видно

И когда чел, так написал более 50ти постов в разных темах — тоже видно.
Поэтому я уверенно говорю
«Я ж самый долбо-б, все по моим постам на доу и видно.»

И по Вашим, даже в этой теме. Ну, тем, кто нарывался на эту проблему конечно.
в реале, сегодня один и спросил, на мой ответ о «тимлидствую», с указанием своиз деталей.
он — и как?? я- да ну нах. справился конечно. как тот дед внучеку — «растреляли нас». но — да ну нах второй раз

а куда денешься? лид фронентд сказал стейкам — не, я все, нашел лучше
QA — ищи.
и т..д.

И такое бывает. Хотя, если проект начинается с нуля и собираешь команду сам — то смысл брать кого попало? Берёшь того, кто проходит планку собеса.

Він його кожного дня дивиться

Но это не спасает от того, что дев тупил или написал полную х-ню.

Так код ревью и не ставит задачу убедиться в работоспособности решения. Задача проверить код стайл ну и общую эффективность (ну, если видно сложность решения O(n3) — значит, что-то с решением не так, наверное ))) )
Для проверки работоспособности есть QA команда.
А перед тем, как отдать задачу в QA, дев должен сам проверить задачу ну хотя бы на базовом уровне и убедиться, что решение рабочее, а в идеале — написать юнит и интеграционные тесты на это решение и только потом отдать в ревью.
В случае, если дев пишет нерабочую х-ню и делает вид, что так и надо, я оч любил риджектить таску обратно с коментом «not ready for QA». А в случае повторения инцидента — отсылал письмо на него с копией на весь менеджмент, до которого мог дотянуться в стиле «уважаемый X, я заметил, что ты отдаёшь неработающие задачи на верификацию (список тикетов). Это не слишком эффективно с точки зрения процесса и отнимает время у QA команды. Пожалуйста, проверяй базовую работоспособность задачи до того, как передать нам». Мало кто хотел получить ещё 1 такой подарок )))))))

Сколько ты знаешь тестировщиков, которые могут поймать мемори лик например?

Лично ловил 2 раза. И ловится он не так, а тестами стабильности. Например, ты гоняешь перф тесты и замечаешь, что 1-е 5 мин у тебя rpc, допустим, 100, а потом он начинает падать. Ты задаёшь себе вопрос, а что это было? И начинаешь обрезать сценарий до тех пор, пока не найдёшь тот API колл или комбинацию коллов, которая приводит к замедлению энва. И вот это отдаёшь как баг.
Тикет «я там что-то наклацал не пойми что» — за такое как QA лид лично по рукам бью. Или stable steps — или заводи на себя, поймёшь, как воспроизвёл — давай задачу на разрабов. Допустимы штуки типа «воспроизводится X раз из Y» — но степы должны быть.
Проблема мемори ликов для тестровщика не в непонимании, что это такое, а в отсутствии надёжных инструментов, которыми можно воспользоваться для blackbox. Для того, чтобы это поймать — есть же всякие там профайлеры, статические анализаторы кода — кто мешает их использовать для whitebox? Добавь триггеры на пуш в гит, чтобы без пофишенных ошибок статических анализаторов мердж не проходил — и не надо перекладывать эти ошибки на QA, которым эти ошибки ловить, по сути, нечем почти :)

Тю, а в чем собственно говоря опасность? Типа «есть свободные девы вместо тебя» или что?

Опасность в том, что менеджер верхнего уровня вставит фитиль менеджеру проекта, тот вставит его тим лиду, а тот — девелоперу. Чем больше стадий пройдёт звиздюлина — тем крупнее она будет. Ну и да — пару таких звиздюлин — ПМу будет проще найти следующего, от которого жопа болеть не будет ))

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

Фантастика какая-то. Обычно такое могут только девы сделать, потому что понимают что такое АПИ колл и все такое. Это мне автоматизатора нужно выпрашивать?

Та ну... Никакой фантастики. Любой автоматизатор, из тех, кто умеет чуть больше, чем княпать селениум тесты — знает, что это. Автоматизаторы, которые на перф тестах — те поголовно знают.
Та даже половина продвинутых мануальщиков, из тех, кто знает, что такое SoapUI / Postman, смогут такое воспроизвести, если ты им объяснишь, чего искать. Но там объяснить сначала придётся, скорее всего. Если не было опыта написания кода до этого — то термина memory leak они могут и не знать )

Это потому что их крайне тяжело продать заказчику )
Будет больше спрос — появится больше вакансий, и рынок подтянется. Толковый автоматизатор сможет месяца за 3..4 доучиться.

Ну, автоматизаторов продавать научились. Уже хорошо. Из них какая-то часть умеет и знает больше, чем общая масса — совсем уже неплохо. Осталось научиться продавать норм подходы на общих основаниях — и будет вообще замечательно.
В продукте — уже получается, последние несколько лет наблюдаю очень даже технологически толковые подходы в тестировании, намного круче, чем запустить руками джобу в дженкинсе с хардкоженным энвом.

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

Продуктов на всех не хватит.
Но можно свалить на тракторе, что и поддерживает динамическое равновесие в системе.

А еще посчитай, сколько толковых девов свалило...

Насколько помню систему ротации в люксе, глобале — она не отменяет собес при миграции с проекта на проект. Соответственно, никто не мешает фильтровать тех, кого тебе предлагают. А при попытке давления со стороны менеджмента типа этих или никаких — можно и зубы показать: найти другого лида им будет сложнее, чем пару исполнителей. Кроме того, у следующего лида будет кулдаун ну минимум в месяц. А если бы они хотели и лида с бенча взять — не искали бы тебя. Значит, проект минимум месяц-2 будет на холде, чего менеджменту хочется ещё меньше. Поэтому согласятся на нормальный набор команды, никуда не денутся.

Давайте порассуждаем.
На проекте есть пул технологий. В общем случае для того, чтобы быть эффективным, тим лид должен ну хоть немного разбираться в каждой из них. Есть исключения из этого правила, например, тим лид — это фронтенд дев без знания бека вообще или QA инженер (такой опыт у меня был лично), но они всё-таки крайне редки и требуют специфический подбор команды.
Давайте рассмотрим общий случай.
Что проще: найти лида с опытом технология_1 + технология_2 + технология_3 + опыт менеджмента + опыт построения процессов или найти исполнителей по типу технология_1 + технология_2?
Теперь рассмотрим частный случай.
Ищем лида с опытом технология_1 + менеджмент, но получаем гемор с нахождением исполнителей по технология_2 и технология_3 (или их комбинации), притом таких, которые на менеджмент не претендуют, иначе можем получить конфликт в команде. Ну и вишенкой: тим лид не сможет оценить этих исполнителей, патамуша тупо никогда с этими штуками не работал и не сможет понять, вешают ли ему лапшу на уши на собесе или нет. То есть, для собесов придётся привлекать спецов с других проектов, чему, конечно, они будут очень рады.

А по факту кого найти проще — ну так смотря что у тебя есть на руках — вполне может быть что в данный конкретный момент есть 2 свободных плюс-минус подходящих лида и не одного гребца.

Дык нету же!
Смотри. Начинается проект. Находят лида. Пока он сменит проект — пройдёт месяц.
Других свободных лидов уже нету — к этому моменту они уже нашли другую работу.
То есть, не сработаешься с этим (а это ну ещё неделя минимум) — ищи другого. И он тоже месяц будет переходить. А ещё ты его месяц будешь искать. Итого: 3 месяца + 1 неделя как минимум фтопку. Тебе как манагеру такое счастье надо?

Бывает. Ну, значит, пусть он это г и гребёт, не жалко :)
Тогда у тебя нету рычагов давления и возможности опротестовывать удобные менеджменту решения. А значит, по факту ты — не лид, а старпом, тупо передающий по цепочке команды капитана. Из такого проекта надо валить, искать здесь нечего.

Высказать мнение как минимуму может каждый.

Конечно. Но если тебе насильно втюхивают гребцов, даже если ты с ними поговорил и твоё мнение «нет» — это прямое вмешательство в твою зону ответственности. И тут надо настаивать на том, что ты лидишь команду, а не манагер над тобой. Пусть он решает свои проблемы, а ты — свои. Предложил — спасибо, не вопрос. Я пообщался с кандидатами, моё мнение — нет. Если ты считаешь по-другому и риджектишь мою экспертизу — значит, ты в ней не заинтересован. Значит — рули командой сам, я передастом не буду.

То есть давить то в принципе можно, но не всегда и не по любому поводу

Конечно. Я не могу, к примеру, указывать вилку ЗП для кандидатов — это не моя зона ответственности. Но если я её знаю — я могу посоветовать её изменить, исходя из своей компетенции, если она нуждается в корректировке с моей точки зрения. Но тут — да, я могу только советовать, давить — не могу.

Проблема с возможностями давления это не передавить ими свои собственные долгосрочные отношения.

Абсолютно согласен. Но есть и другая сторона медали: поддашься на прямой прогиб — и дальше об тебя будут ноги вытирать. Надо соблюдать баланс и смотреть, какую стену пробить можно, а об какую расшибёшь себе лоб. Например, если это энтерпрайз и все тесты уже лет 15 как пишутся на джаве, а ты внезапно хочешь пайтон — наверное, у тебя ничего не выйдет. А вот если это стартап, где тестов пока нет, зато заказчик посмотрел 2 видоса о том, как клёво писать тесты на котлине — твоя прямая задача переубедить его, аргументируя как минимум тем, что автотестеров на котлине искать ты будешь, пока проект не закончится.

Иногда проще +500 сам знаешь где, чем лоб об стены бить

Знаешь, мне редко попадается начальство, с которым не выходит поругаться)
Здесь был тот случай.
Ну и фактор, что начальство далеко, и мы сами себе хозяева на квартире вместо офиса. И нет дедлайнов. И никто не говорит, как кодить или тестить. То есть, нужен результат, а не процесс.

Конечно. Тоже вариант. Зачастую так и делаю, если стен много, а лоб уже болит :)

Не :)
Я так не делаю.
Я могу индивидуально порекомендовать человека на повышение, могу попробовать договориться за какой-нить бонус, если вся команда без исключения пахала овертаймы, чтобы успеть к сроку сдачи — но договариваться типа дайте ВСЕЙ команде райз — не, оч странный стиль :)

У нас нет прямой миграции. Все идет через internal mobility. А здесь будет не только стандартные ТИ и РМИ, но проект точно получит фидбек от предыдущей комманды.
Система довольно динамична, потому при малейшем желании роста в хард или софт скиллах == эта возможность у человека будет — так и private internal mobility — когда проект перехода ищется без нотификации тим лида и менеджеров...

Хотя у нас на BCM как правило беруться только сениор+...

то смысл брать кого попало?

да проще некуда: сроки и бюджет.

Так я же дальше написал: берёшь тех, кто проходит планку, поставленную собесом. Остальных риджектишь сразу. Мне проще начать с половиной команды, попутно добирая остальных, чем застаффить все позиции кем попало, а потом думать, что с ними делать.

Бывает ситуации — что бери кого дают. И иногда даже приходится брать кого не хочеш по прошлым проектам. Вот такой бизнес — системный, с системой типа: «срочно — писец — ааааа». Альтернатива — отказаться от проекта совсем. Стоит отметить что это, как не странно, далеко не самая большая проблема которая может быть. Реальная засада с менеджерами — чудаками на букву М, в особенности на стороне клиента. Которые постоянно пытаются «скастить рейт» пытаясь работать без: энвов, тестировщиков, аналистов, ПМ-ов или подсовывать своих «специалистов», устраивать на проекте «аджайл» (это такой «процесс» где клиент сам все за всех за эстимейтил, намалевал диаграмму Ганта обозвав ее продукт роудмапом и директивно требует уложится в намеченные им сроки ещё и назначая исполнителей на задачи) но при этом делая громкие заявления — «мы конкурируем с Amazon.com». В таком «замечательном проекте» текучка кадров такая что — возьмёшь кого дают, пока сам не разбежишся в разные стороны.

Бывает ситуации — что бери кого дают. И иногда даже приходится брать кого не хочеш по прошлым проектам.

Да, был в такой ситуации. Урок выучен, больше в эту яму постараюсь не падать :)

«срочно — писец — ааааа»

Да не вопрос. Бюджет до 90-го перцентиля. С моей стороны: собесы хоть до 12-ти ночи с 2x оплатой овертаймов. Любой каприз за деньги заказчика ))

Которые постоянно пытаются «скастить рейт» пытаясь работать без: энвов, тестировщиков, аналистов, ПМ-ов или подсовывать своих «специалистов»

Оооо, об этом в другом топике писал. Это боль, да... Ну, тут надо, чтобы ПМ проекта был на стороне команды и вместе объяснять заказчику, почему без вот этого мы обойтись ну никак не сможем. Если ПМ будет на стороне заказчика — из этого проекта лучше сразу свалить, свои нервы лечить дороже. Ну и частично это можно ещё на этапе интервью угадать, узнав, какой состав команды планируется и какой квалификации, есть ли команда на стороне клиента, какой объём задач, сроки. И если видишь, что там писец — лучше даже не влазить в это, сколько бы тебе лично не пообещали.

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

Та ну... В такое г лучше сразу не лезть. Разве что это 1-й опыт лидства и ещё не знаешь, на что смотреть.

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

А что за анекдот?

Понравилась ассенизатору девушка. Но есть проблема — запах. Обратился к приятелю — тот посоветовал одеколон «хвойный лес», купил надушился приходит к другу протестировать. — Ну как запах — Как будто кто то в бору насрал.

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

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

какой танец надо выполнить чтобы прод сам поднялся

Ха! В який шаражкиній конторі Ви працюєте?
Між мною та продом:

• SIT
• UAT
• PCT
• PXT
...а інколи шось ще... Загалом, є стандарт PCI DCC який забороняє одній людині розробляти код та його підтримувати в проді.... Цей стандарт обов’язковий, наприклад, для VISA-NET...

Ви прекрасно зрозуміли про що я.

Думаю вам складно комунікувати з командою) і навпаки.

«Якщо вас оточують одні ідіоти, значить, ви центральний.» Народна творчість

Нет.

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

Диалог по стилю похож на «уточку и лебедя»:

Озеро. Лебеди разминают крылья.
Красавец-лебедь картинно становится в позы культуриста, растягивая каждое сухожилие, поигрывая мускулами.
Подходит маленькая серая уточка, мнется, начинает (жалобным, слегка писклявым, дрожащим голосом):
— Коне-е-е-е-е-ечно... Наверное, на Юг полетите?..
Лебедь, басом, красиво выгибая спину:
— Ну, да, на Юг. Ага. Там тепло, да.

Уточка:
— Коне-е-е-е-е-ечно... А я ту-у-у-ут останусь... Замерза-а-а-а-ать...
Лебедь:
— Полетели с нами, да. На Юг. Ага. (тянет мускулистую ногу)
Уточка:
— Коне-е-е-е-е-ечно... У вас крылья во-о-о-о-о-он какие... А у меня ма-а-а-а-аленькие, я упаду, разобьюсь и умру-у-у-у-у...
Лебедь:
— Так мы тебя, того. Поддержим, да. Воздушные потоки, понимаешь.
Уточка:
— Коне-е-е-е-е-ечно... А в дороге я проголодаюсь, обессилею, и умру-у-у-у-у...
Лебедь:
— Ну, так будем ловить жуков. Да. Сочных жуков.
Уточка:
— Коне-е-е-е-е-ечно... Жуки большие, у вас клю-ю-ю-ю-ювы вон, какие, а у меня ма-а-а-а-аленький, я не смогу проглотить, подавлю-ю-ю-юсь...
Лебедь (похрустывая, разминает крылья):
— Так мы тебе их того. Разжуем, да. Будешь есть, нормально же.
Уточка:
— Коне-е-е-е-е-ечно...
Лебедь (выпрямившись, глядя на уточку):
— Так. Нахуй.

Кстати, можешь перепрыгнуть с прибавкой djinni.co/...​il/candidate_new_job.html

Зато указывал зарплату)))))

А хто буде робить хай лоад?

В С++ нет асинка

Таки да, есть. какая-то неведомая хрень, которая либо создаст новый поток, чтобы вызвать заданную функцию (что очень тяжело по ресурсам), либо вызовет ее в момент доступа к фючеру (нафига?).
Короче, я не въехал, кому такое надо.

Ну корутины как легковесная замена потоков вполне ничего должны быть. Чтобы не писать реактивный код на колбеках.

Почему? (я с ними не работал)

Ничего не понял. Наверное, опять отстал от жизни.

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

Вот тут побаловался с кодом dou.ua/forums/topic/32636

Прикольно, дякую!

Так дофіга use case’ів підходить. Бази даних працюють по своєму бінарному протоколу і тримають підключення «до побєди». В цю ж тему всякі key/val storag’і, memcache’і, і інші distributed hash tables. Для Ігр народ взагалі свій network стек пише, причому скоріш навіть на UDP замість TCP.

Ти про які саме ліби?

Так а хто ліби пише-то? :-) Моя теперішня компанія якраз БД і розробляє :)

Там народ заморачивался — то multiTCP, то еще что. UDP часто провайдеры режут. Сейчас, думаю, Гугл либов наделал, и стало проще.

Компания «ITExperts» (Кузмичь Софт) вдруг предлогает ЗП как Google. По опыту — даже на собеседование смысла идти нет — если врут уже в дискрипшене.

ITExpert is fast growing recruitment agency, specializing in quick and quality staff selection for our customers.

Это американцы пошли в ремот, а эксперты для них хайрят.

я в теме о медитации порывался запостить этот баян

потому что хобби — в этих тусовках «искателей духовности» превидел этих маугли (из аналогичного, когда он каа достал) перевидел

но, не постил и там,

правило ж описано в куче того что читывал, видывал меньше:
Отвечать надо то — что надо овечать спрашивающему.
(роль тим — лида — та же)

Как по мне, даже в теме о пользе медитации не было ни одного кому надо было напомнить. а в этой — ну, баги отвечающего тоже бывают :)

Проще всего вывесить белый флаг и выбросится заборт, ага

Ти вже в коментах нижче написав, що навіть у випадку ідеально зданого проекту ти не отримаєш додаткових бонусів ні будь-яких інших плюшок.
Чесно, поки не побачив жодної причини через яку ти мав би так рвати *опу і страждати.

Найгірше, що може трапитись — тебе звільнять якщо на проекті почнуться хронічні проблеми, затягування або баги почнуть рости в геометричній прогресії.
Але якщо ти такий кваліфікований тіп як тут пишеш, ти за тиждень знайдеш нову роботу, ще й може з прибавкою в ЗП.

Але скоріше за все, навіть такого не трапиться, галери менеджать не геть олені і вони розуміють, що проекти бувають успішні й не дуже, а кваліфікованих людей бажано тримати.
Коли галера бере проект, вона ментально готова до того, що він провалиться, особливо, якщо він «проблемний», а твій, очевидно, такий.

Найгірший сценарій, це проект почне сипатись і замовник піде від вас. Ну що ж, проведете ретроспективу, поговорите що було добре і що погано, напишете які висновки зробили і все. Ну максимум когось звільнять і на нього повісять всіх собак, але навряд тебе, бо тебе можна буде перекинути на інший проект і продовжувати збирати маржу.

Блін, як я раніше не розпізнав, що ти просто жирно тролиш)
Однозначно зачьот)!

Тільки так і роблю)

Тут вопрос же о том, что отвечать за код лично мне.

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

Проще всего вывесить белый флаг и выбросится заборт, ага

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

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

Возможно это сюрприз — но в общем случае и в 50 лет ведут себя почти точно так же как и в детском садике, разве что только без рукоприкладства — которое заменяется психологическим давлением издевками всякими и т.п. пассивно агрессивным поведением. Генетическое наследие Homo erectus и прочих наших предков в нас очень сильно. Есть инстинктивное поведение, которое работает в нас по умолчанию вместо энерго-затратного логического мышления, и хорошо предсказуемо. На этом построены целые системы работы с людьми: в космонавтике, правоохранительных органах, армии, рекламе и маркетинге и т.д.

Я RBT вообще не помню. Оно ни разу в жизни не нужно было. Будет надо — полезу в Седжвика почитать.

Угу, но RBT по памяти сделает студент или задрот, а thread pool — кто работал с низкоуровневыми штуками. В результате — имеем фильтр на 4 категории. Вам каких отсыпать?

std::map и std::set это и есть красно-черные деревья lol Иногда хоть и редко даже используются.

Так на собесе попросят их руками проворачивать.
И да, я не использовал std::map и std::set. Слишком дорого для эмбедеда std тянуть.

Если это микроэмбеддед, то во всех планах дорого — и в рантайме замусоривается память и код разбухает если включать rtti и exception да и либа сама не бесплатная.

Мы одно время поставляли www.dinkumware.com — но у неё очень много проблем с совместимостью, скажем так, несмотря на то, что она сертифицирована и официальная совместима с С++ стандартом, добрая две трети софта с ней не соберётся, потому что хотят G++ std. Поэтому мы ушли в LLVM C++ std — она более человеческая, но даже с ней процентов 10% софта не собирается просто так, нужно постоянно её обновлять.

Когда я зашел на последний проект, рассказали примерно так (по памяти):
1) У нас раньше был STL, потом его выпилили и переехали на самописное. Прошивка уменьшилась на 1.5 МБ. Для сравнения, это примерно сколько весь Линукс занимает.
2) Мы пытались использовать исключения, и раз в неделю что-то падало, отловить не смогли. Отключили исключения — стало ок.
Чтобы понять проблему — в эмбедеде самое дорогое — флеш. Флеша в роутере 10-30 МБ, а оперативы — сотни МБ. И если код как-то можно уменьшить — то его нужно уменьшить.
Второй прикол — кросс-компиляция. Вовсе не гарантия, что крутые фичи будут нормально работать на каком-нибудь big-endian MIPS — там нет толп энтузиастов и блогеров.

Там еще все зависит от качества сборки тулчейна (либа то из тулчейна идет)

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

10-30Мб это овердофига с учетом squashfs с компрессией

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

Big-endian MIPS — это целая пачка досих пор выпускающихся роутеров. Довольно популярное в своих кругах железо

Вот только эти круги узкие, обычно писанные на С, и ни разу не энтузиасты С++20 или даже STL. А альфа-тестером либов в своем продакшне никто быть не хочет.

Вот применимость STL в хайлоаде ithare.com/...​sdoms-and-common-wisdoms

Рисуешь не бумаге, и потом пишешь код по тихоньку. Возможно еще дебажить придется — тогда нужно размалевывать дерево по дебагеру в ручную — по результатам тестового кода и смотреть что балансируется верно. Мне приходилось и в боевую писать само-балансирующийся интервальные деверья (в прод ушел AVL алгоритм правда), чтобы сделать кеш который по IP адресу выдает страну, и для кастомного распределителя памяти — чтобы по указателю найти slab блок к котором надо делать free. Конечно сложно все в голове держать, но при должной сноровке бумажке и ручке под руками — не боги горшки обжигают. А в STL есть вариант что можно статически станадртуную библиотеку слинковать. Для STL скорее всего кроме ::new для std::allocator ничего и не будет — аллокатор можно через шаблон свой подкинуть, например free list который просто из стекового массива выделяет блоки фиксированного размера, как у Алексанреску.

По деревьям — ни разу не попадалась задача, где они нужны. Обычно не такие объемы данных, чтобы заморачиваться чем-то кроме массивов или списков.

STL как ни линкуй — у тебя будет по вектору для каждого хранимого типа данных. На средненьком таком проекте — десятки раз включен код вектора. То же — со списками и остальными контейнерами. И нафига? Там везде идет переход по указателю для доступа к данным — то есть, оно еще и по кешу неэффективно.

Привести все к void*?
У меня типы обычно с доменом связаны.

Нафига?
Купить билет и назло кондуктору пойти пешком?

Естественно, велосипедить. Там кода на недели две писать и отлаживать, зато потом будет эффективно и без камасутры.

Если это C, то лучше взять вот этот набор макросов man.openbsd.org/tree.3 , код очень компактный и эффективный получается.

Кто тебе мешает нанять девочек?

А за что ты должен, кому и сколько?

Главное, чтоб не алименты.

Не совсем понял. Твой долг — не финансовый?

И что тебе мешает при этом нанять девочек?

Что тебе мешает нанять человека, который наймет девочек?

Капитана всегда могут выкинуть за борт. Если он соответствующе себя ведет.

Звісно не можуть, інакше їм би платили так, як Вам.
Тож тут радіти потрібно, що ніхто не може робити роботу на тому ж рівні, що і Ви — завдяки цьому ви отримуєте більше за інших.

За це Вам і платять вище, ніж іншим. Навіть не так. Через те і найняли настільки висококваліфікованого професіонала, як Ви, а не будь-кого іншого. Хто і хотів би заробляти стільки, скільки Ви, але не має настільки високої кваліфікації, як у Вас.
Результати роботи, які влаштовують, будь який дурень і не настільки висококваліфікований спеціаліст зможе використати. А от використати результати роботи, які не влаштовують, значно важче. Через те і наймається настільки висококваліфікований спеціаліст, як Ви, а не будь-хто інший. Щоб своєю високою експертизою перекрити слабкі місця команди.

Расскажите это, например, главному инженеру по строительству.

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

Лучше ругаться с линтером, чем раз в два дня джуну «носик вытирать».

вставлять исключения и проч.

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

Тоесть дно пробито настолько, что совсем нет никого кто так пахабно будет говнокодить? Документации мы уже выяснили что у вас нет и вы ее не пишите потому что по вашему мнению «ее никто не читает», объяснять как и что чтобы компенсировать отсутсвие документации — вы тоже либо не хотите (ибо кто мне за это заплатит) либо не умеете (все равно ничего не понимают). Так и сидите синьером-помидором тогда, королем ничего и начальником самого себя. Пока заказчик с менеджментом не примут «сложное решение». Как там у Дейкстеры — «любой дурак может написать код который понимает компьютер, профессионалы пишут код который понимают люди».

Якщо людину взяли на роботу, вона успішно пройшла співбесіду і ± нормально працювала до моменту, коли ти наважився писати цей топік, то ми вважаємо, що твої колеги ± кваліфіковані спеціалісти, що вміють робити роботу.

Що значить

не справился на должно уровне,

?
Якщо ти як тімлід, даєш таску своєму колезі в команді, колега не знає як її виконати або робить втричі довше ніж очікувалось, то тут декілька варіантів:
1. Херово описані вимоги, специфікації, Definition of Done. І ти як тімлід мав би проконтролювати аби це все було. Якщо цього нема або воно неналежної якості, то ти сам винен, що люди затягують, нема чого когось звинувачувати.
2. Таска занадто велика і абстрактна. Таски повинні бути не великі, чітко описані. Якщо ти бачиш, що людина затягує або що вона вже робить третій коміт, створюються простині коду і це ще не кінець, то таке треба ділити на сабтаски і ти як тімлід мав би проконтролювати аби це робилося, якщо цього не зробив — сам винен.
3. Таска реалізована і там виявилиля баги. Це абсолютно нормально, для цього існують автотести аби виявляти відразу і кюєї аби тестити. Якщо тестів нема, то ти сам зрозумів, хто винен.
4. Нереалістичні очікування. Якщо ти очікуєш, що всі в команді будуть перформити інженерні задачі на твоєму рівні, то це твої проблеми, що вони не дотягують. Як писали вище, на те ти і лід і тобі платять найбільше.

Робота ліда, це перш за все робота з людьми, контроль за процесом роботи, контроль наявності прописаних тасків, контроль наявності тестів, допомога колегам з тасками і захист їх перед менеджментом і замовником. А потім вже, якщо лишиться час, можна щось самому закодити.

...а потім вже, якщо залишиться час, можна і здохнути, але тільки якщо залишиться час і тільки потім)) бо якщо після того на проекті щось піде не так, ти ж розумієш хто винен, на те ти і лід)

Якщо лід не хоче виконувати функції і обов"язки ліда, виправдовуючи це тим, що він хоче виконувати інженерну роботу і лишатись лідом, то дайте відповідь, хто неправий в цій ситуації і що робити?

тут я погоджусь цілком, але ну це вже зовсім по іншому звучить, аніж лід всім «должен», за все відповідає і у всьому винен на тій підставі що «тижелід» і «тобіплатятьнайбільше») іноді коли

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

можна не ділити таску, а взяти іншу людину) випадки різні бувають, треба розбиратись якраз і працювати з людьми, саме так як ви пишете

В такому випадку я бачу три сценарії:
1. Спробувати підтягнути колег. Як мінімум, треба їм коректно вказати, що ти не задоволений перформансом. Після чого надати рекомендації як саме підтягнути цей перфоманс. Критикуєш — пропонуй, сама лише критика без конструктиву і незадоволення це токсичний шлях Ч(М)удака.
Ну і будь-яка критика завжди повинна бути наодинці, 1-1.
2. Звільняти і набирати кращих.
3. Звільнятися самому і шукати іншу більш кваліфіковану команду.

P.S. А ти впевнений, що вони дійсно нижче рівнем, а не тобі так здається? Раджу поговорити з менеджером. Можливо, менеджмент і замовник всім задоволені, а проблема існує лише в твоїй голові.
P.P.S. А можеш сказати, де саме ти працюєш)? Можна без конкретних імен аби не спалитися.

Спробувати підтягнути колег

з джуна до мідла — то за різними оцінками що бачив не тількі на власному досвіді
година в день витрати часу — і так від пів року до 8ми місяців

тобто 5 годин на тиждень свого часу. на 1го джуна.
а їх — 5 у команді.

давай!, підтягуй! :)

треба їм коректно вказати

так, але джун впевен що він вже мідл :)
а мідл — що сіньор.

Звільняти і набирати кращих

для цього спочатку сісти і намалювати грошей.

Звільнятися самому і шукати іншу більш кваліфіковану команду

якщо ти справді високого проф рівня — там буде те ж саме — більшість команди нижче тебе за рівнем.

бо ти- вище середнього рівня :)
при чому, вже теж відомо — синьору зараз теж непросто змінити роботу.
легше всього мідлам.

але так, команди різні, і можна пошукати іншу. дефіцит же програмістів.

У мене склалось враження, що дуже багато людей, включно з автором топіка, не хочуть визнавати, що головний обов"язок ліда це люди, а не код.
Тому ви описали, те, чим дійсно повинен займатись лід:

тобто 5 годин на тиждень свого часу. на 1го джуна.
а їх — 5 у команді.
давай!, підтягуй! :)

Одну годину на день ти менториш людину, інші 5-7 годин людина робить корисну роботу для проекту.
Тут елементарна математика: Якщо ти можеш за день поменторити 5 людей(навчити, підказати, порев"ювати), то вони ЗА ДЕНЬ зроблять 25 годин корисної роботи, а якщо ти будеш сам просто працювати, то за день буде 8 годин роботи. Нехай навіть 10 якщо овертаймити.

Ви можете заперечити мені, що якість роботи підлеглого буде набагато гірше, але на те ти і маєш витратити годину на людину, аби його вихлоп був співрозмірний з твоїм. І якщо правильно менторити, то з кожним місяцем ця година менторства на день буде зменшуватись.

Само собою, що такий режим не для всіх, але не хочеш так працювати, не йди в ліди. Хочеш просто продовжувати кодити — лишайся сіньйором, контрактором і все.

У мене склалось враження, що дуже багато людей, включно з автором топіка, не хочуть визнавати, що головний обов"язок ліда це люди, а не код.

так, peopleware

Ви можете заперечити мені

що, менторинг — то взагалі найостаннє що прийде в голову технічному спеціалісту.

і те що його, менторинг, мона і треба теж делегувати — те ж.

наприклад — кожен сіньор — зобов’язаний мати джуна :)
так прописати у кодексі команди, та відразу про це сказати на співбесіді.

та й мідл, якщо він справді мідл — вже може.

у CodeClub є приклади дітей, які пройшли 3 курси(1 курс — 12 занятть) Scratch — та самі вже вчать новачків :)

але не хочеш так працювати, не йди в ліди. Хочеш просто продовжувати кодити — лишайся сіньйором, контрактором і все.

так.

взагалі то купа всього є, на цю тему. і курси є, для тімлідів.

але питання у топіку звучить більше як про психічний стан, коли відкриваються очі на те что більшість людей — йолопи. просто йолопи, на все життя, без шансів порузумнішати.
навіть ти сам, як охолонеш від цієї картини побачиш у дзеркалі — йолопа :D
тільки на іншому рівні.

цей стан проходило віками чимало людей, в різних областях.
рецепти тому усякі є.

більшість людей — йолопи. просто йолопи, на все життя, без шансів порузумнішати.

Об"єктивно — це неправда.
Суб"єктивно — це когнітивне викривлення в очах того, хто так думає.

Коли чую щось подібне, згадую як звільняли Джобса з Епл, Діснея з газети з посади аніматора, як Адольфа не взяли в школу мистецтв і купу інших випадків.
Певно в очах звільнявших вони виглядали останніми йолопами в світі)))

Об"єктивно — це неправда.

як раз це — об’єктивна правда.
а суб’єктивна — всі люди рівні, мають право ..., заслуговують на повагу, ..., ..., ...,

Суб"єктивно — це когнітивне викривлення в очах того, хто так думає.

так, так.
про це й мова — йолопи в команді впевнені що то у ліда когнтивне викривлення, і починається...

як і всюди в інтернетах — тільки но скажи що більшість — йолопи, то й почуєш собі діагнози :)

Певно в очах звільнявших

Звільнення, як і рівень доходу — не мають відношення до того йолоп чи не йолоп.

як раз це — об’єктивна правда.

В такому разі, якщо ви стверджуєте що є якась об"єктивність — надайте метрики.
1. Дайте визначення йолопа на проекті.
2. Надайте метрику і як це виміряти до якої границі людина все ще є йолопом, а після якої перестає бути таковим.

В такому разі, якщо ви стверджуєте що є якась об"єктивність — надайте метрики

з певного часу я вирішив не витрачати час на науковірців :)

Дайте визначення йолопа на проекті.

коли ви не йолоп — то ви самі це бачите.
коли йолоп — роз’яснення не допоможуть

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

ви самі це бачите

роз’яснення не допоможуть

Апогей нашого апофеозу при визначенні об"єктивності))) ну-ну)

об’єктивне — це те що існує незалежно від стану нашого зору.
те що більшість щось не бачить, і не розуміє пояснень про те що вона не бачить
не робить це — суб’єктивним.

для дитини більшість звичайних речей у яких живуть її батьки — не інсує. і поясненнь вона теж не зрозуміє

Проект не у тебя горит, а у заказчика.

А ты тут при чем?

Є навіть аксіома, що з якості, часу та ціни можна зафіксувати не більше двох параметрів. Я так бачу, що вам зафіксували ціну і час, а вы марно намагаєтесь зафіксувати ще й якість? Я б робив усе можливе, щоб просто реалізувати функціональні вимоги і отримати оплату. Потім по можливості переписувати, якщо за це заплатять.

Значит, они будут гарантировано писать хуже.

Так и ты пиши хуже. Проблему нашел.

А ты сбоку на плоту проплываешь?

Ну с таким настроем денег точно никто не даст

Elderly :-)

Ну потому как такой вопрос мог возникнуть только у ЧСВ с полным отсутсвием софтскилов как таковых. Я ХЗ как пройти комитет на тимлида (или собес) при полной проф непригодности к позиции. Бывают конечно исключения — но тогда ментора приставляют, отправляют на тренинги и т.д. А полный анонимус профайл — как бы намекает, тем более что его нельзя зарегать такой уже. Остаётся только тролинг с целью поймать батхерт аудитории.

добивают до года и валят

бывает что и до года не добивают ибо сил терпеть издевательств и морального унижения нет. К сожалению наблюдал очень часто. Я описал подобный менеджмент в одной из своих статей.

GlobalLogic?

Мені щось саме звідти пруть найвеселіші співбесіди, де той, хто питає, вважає, що його варіант розв’язку єдиний існуючий, а хто не здогодався — студент.

и как его правильно при этом менеджерить.

Нафига? +500 же через дорогу

Ну тогда −500 и менеджеру удачи обуздать текучку

старики нередко ведут себя как дети. хотя и старше.

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

так что тут надо выбирать — не любите детей — не идите в педагоги :)

можно конечно найти же зрелую команду, но это сложно. их у нас мало.

еще вариант — не работать в крупных компаниях.
а работать в маленьких.

Вот наоборот как раз, скорее младшие, которые разбросал игрушки по полу и не знает что делать.

это легче, чем

А пубертатные они хотя бы мотивированные, просто без вектора.

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

договариваться с подростком — требуется больше усилий.

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

а так на маленьких галерах нет ни возможностей роста, ни настроенных процессов, ни сложных проектов.

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

думаешь для тебя все делается в мире?)

Проджект-менеджер, якому я завдячую тому, що він мені, на той момент (2014 рік) досить хаотичному ліду, прищепив процесне мислення, казав, що навіть не настільки цінна здатність зробити самому, як навчити людей навколо себе, виростити їх.

І де він зараз?

І де він зараз?

Head of Delivery.

Ты кстати предлагал помощь в виде консультаций?

Постоянно.

К тебе часто обращались?

Иногда настолько часто, что работу работать некогда :)

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

Тут есть ещё одно правило — 3 дня без прогресса — проси помощи. По крайней мере извести всех заинтересованных лиц в том, что у тебя простой.

Не пиши, а переписывай?

Да никогда :)

Или задалбывать на код-ревью

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

А потом чувака снимают с проекта на другой, и что тогда?

Ну тогда это не команда, а сброд котов.

На твое правило у меня есть опыт из жизни — чувак 3 недели говорил «я занимаюсь, немного не получается»

Нууу? И какая твоя была реакция? После трёх дней говоришь hands off, садишься рядом и просишь его показать что не получается.

вот что должно получится (но там лицензия не ок), пожалуйста, разберись, почитай доки, сделай как надо" — не, вот тебе копипаста

Просто похоже тебе джунов насовали. Так аутсорсеры делают, проще одному человека платить выше рынка, чтобы он пас котов на проекте, которым платят ниже рынка.

Типа уже не проблемы или как?

Смотря где, если девелопер сделал линейный поиск, где элементов заведомо меньше 1000 — хер с ним, и т.д.

Тут прибежит ПМ и скажет что юниттесты не проплачены, иди нафиг.

Просто найди себе другую работу.

чувак 3 недели говорил «я занимаюсь, немного не получается»,

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

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

Дейли стендап ПМ проводит, и там за 2 часа никто ничего не запомнит.

2 часа дейли стендап? Я конечно не знаю специфики, но по-моему у вас что-то с процессами сильно не так.

Что за система? В azure devops такого точно нет.

Обычная джира.

20+ человек,

Моё утверждение остаётся. По-моему у вас что-то с процессами сильно не так. 20+ человек в команде это, извините, рок-концерт, а не команда.

2 години — це 25% робочого часу. Плюс після такого мітингу десь пів години потрібно тільки щоб відійти і переключитися на робочі задачі. Чи не здається вам що проблема поганого коду може критися тут, тому що час розходується не ефективно. До речі: при естімейті задач ви враховуєте такі довгі стендапи, чи просто набираєте задач на всі 8 годин і потім скиглите на проблему поганого коду і не компетенції ваших тіммейтів?

А зачем подтирать, когда у вас фиксед-прайс?
Для него же есть паттерн про х-х-прод

Ну они перестанут приходить, когда сдадите проект. А до того — найдите самого опытного инкостылятора, и вручайте ему CRы.

Надоели — перестань туда смотреть. Назначь ответственного за смотрение в код.

За код отвечать заказчику, который его получит по фиксед-прайз.
Тебе отвечать только за то, как снаружи твоя команда выглядит.
И, как говорят эльфы, хочешь быть начальником — умей делать вид.
dou.ua/...​ign=reply-comment#2079659

Отвечаю на второй вопрос:
Если ПМ мешает делать вид, и лезет в дела команды — нагрузи его всеми своими задачами. Делегируй ему все, что от тебя хотят подчиненные и заказчик. Пока он или выбросится за борт, или перестанет лезть в дела твоей команды.
Когда ПМ устранен — начинаешь балансировать нагрузку. Ставишь спокойный темп внутри, а наружу говоришь, что все работают по-полной, и если еще подгрузить — будут увольняться, и проект завалится. Чтобы не быть голословным — порекомендуй 2-3 лучших разработчиков знакомым рекрутершам.
А когда ужас-ужас, и все горит, и начальство в обнимку с жареным петухом — тогда попросишь ребят поднажать (а они могут, потому что дуркой маялись все время на пол-нагрузки), за неделю будет результат кое-какой, а ты — герой всей конторы, и фаворит СТО и СЕО поочередно.

Це сам Стас Домбровський до нас завітав www.youtube.com/watch?v=ir5rj2yYH_8

Вообще-то, тим или тех лид может работать с командой 5 человек. Тимлидство на 10 забирает 100% времени, и на код вообще не останется. 20 человек по всей эмпирике работают неэффективно из-за тормозов коммуникации.

Мне интересно как другие переживают свои выходы из зоны комфорта и смирение с п-цовой реальностью

Выходить из зоны комфорта просто для того, чтобы смириться с дискомфортом — это странная активность, если честно.

Ну да.
То, что нас не убивает, делает нас сильнее. (Ницше)

Или — убивает :D

Выгоревший тимлид — это куда чаще чем выгоревший синьор
Сами синьоры выгорают вобщем-то по тем же причинам — ответственности, делегирование функций лида получают :)

требования в большинстве случаев неопределенные.

а выгорание обычно от — ответственности

Я всегда привожу пример из Кена Кизи, «Над кукушкиным гнездом»
Об одном персонаже, что качался у окна днями со словами «Я устал, я устал»

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

Выгорание — это не от количества работы. От количества работы — усталость, переутомление.

Вихід з зони комфорту і БДСМ трішки різні поняття. Описані процеси більше на останнє схоже

Тобто в вас:
1. не береться копасіті команди, а плануються завдання на кожного окремо? Виходить хтось закрив менше задач від запланованого, по якійсь причині, можливо від нього і не залежній, і на нього накидають більше задач на наступний спрінт... вибачте, але як ви хочете отримати хорошу якість при такому підході?
2. нафіга команді лід, який не може повпливати на адекватність взятої кількості задач в роботу? якщо проблема з ПМ не вирішується то можливо і ліда не треба, а просто тоді дати команді можливість нагавняжити проект до стадії «шоб якось робило» зате влізти в терміни і бюджет?

Я же сказал — главное не микроменеджить, иначе можно зашиться. Ставишь глобальную задачу, глобальный дедлайн, даёшь день-два на анализ и декомпозицию задачи на субтаски и естимейты по ним. После корректируешь его естимейты в свои (только в сторону увеличения) для подачи наверх. Каждый откорректированный, но пройобаный эстимейт отражается в годовом репорте. Если фейлов много, то это может сказаться на ежегодном пересмотре зарплаты. Вызываешь на ковёр и популярно объясняешь, что в шею тебя никто сильно не толкал, ты написал месяц, а сделал за три — это твоя неаккуратность, разберись что ты сделал не так и так больше не делай.

А, ну это у вас судя по всему не какая-то стандартная ситуация с тим лидами и скрамами, а какой-то ад-хок процесс, в котором у вас прямо не тимлидские полномочия (вроде ковра и пересмотра зарплаты).