"Энциклопедия профессора Фортрана". Будучи школоло перечитывал несколько раз. А разворот на этой картинке использовался для игры в работу на компуктере )

Даже замороженными ссаными тряпками?

Тк запрещает.

Можно ими премировать!

Контр офер всегда не очень, как по мне

Да нормально
Но если в 1,6 - то как-то сильно недооценивали раньше 🙄

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

нематериальная мотивация

Хм. Тут надо подумать

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

вот-вот, похоже на то

Говорил по этому поводу, аргумент "ну ты же не просишь"

Доброе утро!
Вопрос про шаринг знаний в кросс-функциональной команде.
Есть Back, Front, QA, DevOps. Команда в целом самодостаточна, куда лучше двигаться, чтобы каждый специалист все глубже и глубже копал в свою специальность, или после определённого уровня всем в команде стоит активно двигаться в сторону T-shape.
К примеру Front или QA начинают активно работать с кубами, или там QA сам фиксит мелкие баги в коде у Back/Front, а Back/Front фиксит тесты QA под мелкие изменения?
Кто что думает? Бывали случаи когда t-shape приводил к чему-то плохому?

Привет, двигаться туда, куда это более выгодно команде и прожекту. Если нужна глубокая экспертиза, например, сложность задач непрерывно растёт, то в сторону «копать», если нужно делать овердохрена мелких задач на разных направлениях 24/7, то в сторону прокачки в разных направлениях. Если нет такой полярности - то можно и так и так. Т-шэйпед не проблема, пока уровень задач и требования к их качеству находится на уровне t-шэйпед. В ногу выстрелить в любом случае может. Ну и надо понимать, что в общем случае  тот же фул-тайм-девопс может решать задачи лучше, чем парт-тайм-девопс-фронтенд, поэтому придётся какой-то контроль прикручивать за деятельностью тишейпедов, если вы не стартап, который хочет поработать год и умереть.

Сложный вопрос, контекст очень важен.

Я бы добавил, что круто, когда есть проактивное прокачивание ребят. Чтобы оно было, надо понять, какие роли и в каком объёме нагрузки вам понадобиться позже могут

собственно, Роман это и говорит:

> Привет, двигаться туда, куда это более выгодно команде и прожекту.

кажется, что дешевле предложить помощь в росте и развитии, а после и осуществить этот рост и развитие, в том направлении, что выгодно и вам и человеку; чем контролировать типа “эй Вася туда не лезь"

Сейчас полярности нет, в долгосрочной перспективе есть возможность склониться в ту или другую сторону. Это зависит и от бизнеса и от команды.
Контроль за деятельностью T-Shaper это просто кодревью специалиста в этой области. Первые н раз он потратит чуть больше времени на объяснения, потом будет хватать пары комментов в ревью, затем какие-то вещи будут проходить ревью без замечаний.

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

ну и ещё добавить хочу, что если уж дообучаете людей, то не используйте код ревью для этого