Comments 44
Классический - "подписываюсь под каждым словом". Виртуальный +
Пришел в компанию ведущим специалистом , через полтора года - руководитель направления . Итог - выгорание и всё, что описано в статье.
Год как ушел с руководящей должности обратно в технические специалисты. Сто тысяч раз сказал себе - молодец. Ничего не потерял , только приобрёл . Особенно в техническом профессиональном плане . Столько нового интересного сделал , что даже немного жаль потерянного времени.
P.S. Добавлю еще одну проблему тимлидерства - необходимость общения с манагерами . Для меня это было самым сложным , особенно если не было поддержки и прикрытия сверху. Нервов было испорчено - много, скажем так .
Беря новые обязанности нужно не забывать снимать с себя старые. У меня тоже есть опыт когда нужно было делать все и сразу, кукушечка отлетает очень быстро.
У меня не было старых обязанностей , только новые . Направление росло очень быстро - в год примерно 5 новых сотрудников . Я техниной почти не занимался уже через год. Строил процессы и дискутировал с архитекторами и прочими, как они себя называют руководителями. Повторюсь , эта часть работы было самая сложная и неприятная .
Насчет кукушки , да . Не дай бог повторения ....
Год как ушел с руководящей должности обратно в технические специалисты
Я бы вообще в джуны пошел. Хочу просто делать что мне скажут, ни о чем не думать, и ни за что не отвечать. :))
Обычно такое желание приходит после выгорания. Но не полного, а до состояния угля для мангала. Т.е. само не горит, но разжечь можно ненадолго
Сегодня меня разожгло, когда я открыл код проекта с работы и первое что увидел это был конструктор класса с 23 (двадцатью тремя) параметрами.
не верю!
Ну а почему бы и нет. Это ведь все равно, типа, все, DI создаёт и вставляет. А тесты мы не пишем, поэтому о том что придется для такого класса создавать 23 mock-object мы не думаем. И такого понятия как "связанность" ("coupling") мы по своим понятиям не признаём. Понадобился сервис - отключай мозг и пихай его в конструктор.
Может это была dtoшка record большая)
А я верю. Видел сервис примерно с 15 параметрами в конструкторе. И самое интересное, что так сделали не потому, что всем пофиг, а потому что вот такой сервис, который много всего объединяет. Плодить классы, которые будут включать другие классы, только чтобы уменьшить число параметров, не стали. И да, тесты есть и там все 15 параметров замоканы.
который много всего объединяет.
Понятно, да...
не верю, что такое реально протестировать, если только не для галочки coverage поднять
Может быть что и реально, т.к. все 15 сервисов в каком-либо отдельном методе используются вряд ли. Но все равно это надо декомпозировать. Потому что говнокод. Я вот вообще не понимаю этого рефлекса: "Создать еще один класс??? Не-не-не-не. Деды наши вообще без классов обходились."
Ну так, а нахрена еще один класс, который по сути будет оберткой над параметрами и не будет содержать логики? Ибо она там сквозная, с участием всех 15 сервисов. Больше классов богу классов? Да, переписать наверное это все можно, но очень сложно и дорого. Т.к. эти 15 сервисов еще много где используются. И ради чего? Чтобы было так, как какой-то дядька сказал?
Классов без логики не бывает (если это не совсем уж "ghost object"). В данном случае логика будет, например, группировать вызовы разных классов в один. Aka паттерн "фасад".
Да, переписать наверное это все можно, но очень сложно и дорого.
Ага. Потому что сразу надо было писать нормально, а не: "Напишем сейчас через попу, позже переделаем". Я уже давно убедился - либо что-то делается нормально сразу, либо оно так всю жизнь потом г**ном и остаётся. Никто, никогда, и ничего "потом" переделывать не будет.
В данном случае логика будет, например, группировать вызовы разных классов в один. Aka паттерн "фасад".
Можно, но зачем? Вы получите класс, который используется только в одном месте. По феншую такой класс надо будет покрывать тестами. Но получается, что вы тестируете часть функционала, которая сама по себе никому не нужна (как и отдельные тесты на нее). Гораздо проще сделать просто метод внутри класса (что и сделано)
Я уже давно убедился - либо что-то делается нормально сразу
Вы же не первый год в индустрии. Так бывает, только когда система не развивается. Т.е. примерно никогда. Естественно, что эту красоту придумали сильно позже, когда все уже было не только спроектировано, но и реализовано и вполне себе работало. В остальном вы правы, никто много ресурсов на это тратить не захотел.
Но чтобы в зарплате при этом не просесть, да? Извините, у нас на складе есть только дауншифтинг в зарплате при выросшем спросе за работу.
Чем выше уровень принятия решений, тем больше шансов эффективно распорядиться ресурсами разработки в интересах бизнеса. Тимлидство - про это, про искусство принимать решения, а не про "перекладывание задач"
Я просто оставлю это здесь : тимлид на собесе.
Судя по жалобам, создается впечатление, что ТС повезло оказаться в роли тимлида, хотя в этом и не было необходимости. В целом, роль тимлида в разных компаниях — это нечто абстрактное. Вот одно из определений:
Тимлид — это IT-специалист, который руководит своей командой разработчиков, хорошо разбирается в технических аспектах, участвует в создании архитектуры проекта, проводит код-ревью, а также берется за выполнение самых сложных задач. С таким определением возможности для роста просто огромны.
Теперь о финансах. У нас, например, зарплатная сетка довольно жесткая. Senior Software Developer имеет грейд IC4, а Staff Manager (упор на менеджмент) и Staff Engineer (техлид) считаются IC5, хотя это разные ветки развития (напоминает выбор пути в игре типа Diablo). И даже если ты суперценный IC4, зарплата у IC5 все равно минимум на 20% выше. А если тебе не нравится и ты хочешь уйти, то это уже головная боль для Staff. Наша компания продуктовая, мы занимаемся SAAS, но наши VIP-клиенты — это почти боги. Наш Staff Manager мечтает о более простой работе, где можно было бы просто посмотреть код, провести ретро или на дейликах спросить “как дела?”. Но вместо этого приходится объяснять крупнейшему клиенту, почему мы уже на три месяца опаздываем с выполнением его запросов. Или другому клиенту — почему у него все тормозит (хотя у него единственного шард в пару терабайт, а у остальных клиентов в десятки, а то и в сотни раз меньше, и все работает в пределах нормы). А в этом году средний менеджмент решил поиграть в оптимизацию и поставил задачу сократить процессорное время со 100 тысяч часов до 20–10 тысяч как бонусный эффект от текущих разработок к 2025 году. И, честно говоря, лучше бы отказаться от этих 20% прироста зарплаты. Уровень ответственности и риск получить по шее совсем другой. Зато, если все получится, можно рассчитывать на бонус.
Тимлид - это уже управленческая должность, которая отличается от, в основной технической, программиста, поэтому многим переход дается тяжело, оно и понятно.
Как и программистом может быть далеко не любой человек, а только имеющий технический склад ума, склонность к обучению и интерес к этому, так и для тимлида необходим определенный психотип.
Я с начала этого года перешел на должность тимлида и ни чуть не жалею. Да, поначалу пытаешься и программировать и команду направлять и разруливать все между отделами, тут надо понимать, что программировать можно только, если на это остается время.
И считаю, что на этой должности нельзя жаловаться. Тут как раз-таки надо разруливать боль и кривые процессы в компании.
Вы занимаетесь рутиной и перекладываете карточки за разработчиками? А вы уверены, что бизнес хочет платить 300+ к за перекладывание карточек? Может это может делать тех поддержка или сами разработчики?
У вас целый день уходит на совещания и вы больше ничего не успеваете? А почему вы не сообщаете об этом бизнесу? Что, возможно, нужен еще один тимлид, а разработчиков следует поделить, выделив направленности?
Надеюсь, вы поняли посыл. Тимлид уже не жалуется, а приоретизирует и решает вопросы.
Тут как раз-таки надо разруливать боль и кривые процессы в компании.
Только вот административного ресурса для этого у тимлида почти что нет, а виноват, в случае чего, сами понимаете кто. Всё это за + 20-30 К руб. к зарплате? Не-не-не, нафиг-нафиг.
Тут как раз-таки надо разруливать боль и кривые процессы в компании.
А если руководство не понимает , что процессы кривые ?
"Мы разработаем новый процесс , но менять ничего не будем". (С)
Бизнес очень хорошо понимает язык денег. Если вы пришли с обоснованием в духе
- сейчас мы работаем так вот и у нас уходит на это 4 ч в день
- если перестроим процесс, то будет уходить 2 ч в день.
- т.к. занято сотрудников 5 в этом процессе, то получим экономию в 5 * 2 * 22 человека часа в месяц
- один час стоит столько-то, на выходе такая-то сумма
Если приходить с голой идеей, типа "а давайте теперь по-другому", то к этому вряд ли отнесутся серьезно.
А если руководство самодуры, то в такой компании в принципе не стоит работать ни на какой должности.
У вас есть положительный опыт использования такого обоснования?
- сейчас мы работаем так вот и у нас уходит на это 4 ч в день
- если перестроим процесс, то будет уходить 2 ч в день.
А потом программисты понимают что их просто прикололи делать в два раза больше работы за те же деньги, и, выяснив, благодаря кому, устраивают тимлиду темную после работы :)))
Я не знаю как там Запад, но в реалиях СНГ у тимлидства есть еще одна негативная черта. Тимлиду очень часто не дают собрать команду под себя, нанимать и увольнять по своим соображениям. Это низводит должность до мальчика для битья с обязанностями без прав.
Мне постоянно стучатся HRы c "ищем тимлида" - и у всех как на подбор отличная команда, приходи и кайфуй! А кто их нанимал? По какой методике? А почему старый тимлид ушел? А почему из команды никого не вырастили? А заранее с командой поговорить можно? Нельзя? Ну успехов.
Простите, а вы как хотели? Коллектив - это такой-же актив компании, как и оборудование, станки, и прочие самолеты. Коллектив - не ваша собстенность.
Вас приглашают для управления этим активом и генерации прибыли с помощи этого актива.
Не понимаете этой простой истины? Ну успехов.
Не понимаете этой простой истины?
Видимо, не я один не понимаю. Вообще-то в деловом мире это нормально, когда ответственное лицо или приходит со своей командой или имеет полномочия на ее формирование.
В деловом мире (что это за деловой мир, хотелось бы узнать? Эффективные менеджеры?) это, возможно, и нормально.
А вот на производстве вам никто не даст заниматься такой ахинеей. Ага, полцеха рабочих сейчас уволить и нанять каких-то других (каких?).
Такие игрища прокатят с манагерами и продаванами. Накрайняк с айтишниками. Но с рабочими-станочниками или инженерами такое не пройдет.
Команду, б... он приведет. Металлургический цех (начальником цеха, к примеру, тебя назначили), к примеру, триста человек. Кого ты приведешь? Даже замов тебе никто не даст менять по своей прихоти (не говоря про инженеров и рабочих), потому что они знают, как цех работает, весь процесс, все цепочки, все операции. Собственно, они и создают продукт и прибыль. А ты кто?
Знал я такие примеры с завода. Владелец завода поставил на завод руководителя, а тот начал пальцы гнуть и "команду подбирать". Инженеры и руководители просто сообщили владельцу ситуацию. Тот приехал, поговорил с инженерами и директора тем-же днем освободил от обязанностей.
Уймись, болезный. С завода он примеры знает. Из армии еще примеры вспомни и из младшей школы. Ему при ИТ-команды из 3-5 человек, он про цеха какие-то. Ага, никакой разницы.
Вы спросили, почему, я попытался выдвинуть предположение, привожу примеры, обосновываю. Вы меня баните. Как так?
Вы на производстве работали? Нет? А я и на производстве работал (ушел по причине зарплат), и в IT. Ответственно заявляю, никакой разницы, в общем-то. И там, и там - производство. И там и там - продукт. Требования, сроки, деньги.
привожу примеры, обосновываю
Но в основном хамите.
Вы на производстве работали? Нет?
Сначала сервисный инженер по запорно-регулирующей арматуре, потом инженер-наладчик АСУ ТП. Мало? Надо прям кайлом в карьере махать, чтобы жизнь понять?
Ответственно заявляю, никакой разницы, в общем-то
Кто-то ответственно заявляет, что земля плоская.
Если поменять слово "тимлид" на "начальник", а "разработчик" на "инженер" (хотя можно оставить), то все встает на свои места и никакого удивления ситуация не вызывает.
Не везде Тимлид только управляет. Мне к сожалению пришлось и кодить (гасить пожары) и аналитить и управлять. В итоге - выгорание.
Тимлид - это менеджер/разработчик, но фактический - это противоположные роли, зоны ответственности очень размыты: за все отвечает, ничего не успевает, сложно быть авторитетом как разработчику. Лучше, когда в команде есть архитектор, как проектировщик и наставник, и менеджер - для контроля задач и их выполнения.
<sarcasm>
Почему я никогда не вернусь из менеджмента в разработчики. Да все очень просто. Во-первых это деградация, полная. Ты с утра до вечера занимаешься однообразными задачами по написанию кода:
следишь за качеством архитектурыкостыляешь чтоб побыстрому запустить новую фичуследишь за тех долгомзаводишь задачки на выпиливание костылей до которых никогда не дойдут рукирешаешь сложные задачизанимаешься перекладыванием джейсонов слева направоследишь за трендами и новыми технологиямиизучаешь новый фреймворк, который никогда не будешь применять
При этом твоя зарплата не растет и новую работу найти не так то просто. То есть растет, но не так быстро как хотелось бы. Компании проще нанять тыщу джунов с копайлотом, чем одного сеньора который сделает хорошую архитектуру, будет писать качественный, расширяемый, тестируемый и поддерживаемый код. На собеседованиях тебя будут долго мурыжить джуны задавая тупые вопросы "а что будет если скрестить бульдога с носорогом" глядя на тебя с насмешкой в глазах, в которой читается "ааа, не знаешь! а я - знаю! вот я тебя и поймал, никакой ты не сеньор, а врун джуновый!".
Ну и конечно же карьерный тупик. Через 20 лет работы инженером ты оказываешься перед жестоким выбором: либо засунуть свои 20 лет опыта в языке и фреймворке, которые уже не нужны рынку (привет COBOL) либо искать болото, в котором до сих пор используют некрофильские практики (привет COBOL).
</sarcasm>
Если вы проводите на встречах больше 1 часа в день (усредненно по неделе) - вы не умеете выстраивать рабочий процесс. Увы.
Все еще хотите стать тимлидом?