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

Спасибо

Ну и кроме этого всего конечно об этом нужно говорить со своим начальником. Чтобы он не угадывал что тебе нужно, а получал четкую и конкретную информацию

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

Спасибо!

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

Когда человек через полтора месяца не решил ни одну практическую задачу и все что я слышал "а кто у нас за это отвечает?" Взял его под давлением топов. Так то я теоретиков вижу на километр...

Спасибо!

Спасибо!

Проблема в том, что разрабы могут закрывать фичи хорошо здесь и сейчас, на на дистанции кодовая база может превратиться в 💩 Мне в голову приходит только какое-то перекрестное ревью с ребятами из других отделов (хотя не понятно насколько они хороши тоже)

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

Вы обобщаете ответственность за качество на компанию и создаётся впечатление как будто вопрос не решаемый.

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

У команды должен быть роадмап по технологиям, стэку. Как минимум 90%+ покрытие тестами. Командное ревью кода. Если уже все это есть, опросите каждого за стэк, зачем в его понимании они юзают то или иное и что бы он улучшил. Дальше просто попросите ту же нейросетку кратко рассказать за каждую технологию, зачем она, чем хороша, плоха. При желании можно дальше погуглить уже статьи какой стэк сейчас популярен. Сейчас с нейросетями гораздо проще добывать информацию, пусть она и не всегда отвечает корректно. Как минимум помогает понять вектор куда смотреть

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

Да, это уже другой вопрос)

Спасибо!

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