Comments 31
А если это личный проект, выросший во что-то большее? А "он сидит и безразлично портит код своими жирными пальцами"!
это похоже на адаптированную версию кодекса бусидо
Каждое утро думай о том, как надо умирать. Каждый вечер освежай свой ум мыслями о смерти. И пусть так будет всегда. Воспитывай свой разум. Когда твоя мысль постоянно будет вращаться около смерти, твой жизненный путь будет прям и прост. Твоя воля выполнит свой долг, твой щит превратится в стальной щит.
Для нормального вхождения в тематику ведущего, а не просто «награждением» таким званием и пусть сам разбирается, достаточно пару дней с человеком пообщаться, это может быть PM или CTO. Опыт надо передавать, в том числе и такой.
На самом деле книги помогу только структурировать имеющийся опыт, без практики они практически бесполезны.
Если это проблема, значит рано уходить в менеджмент. Возможно, еще хочется работать руками, возможно бизнес требует восьмирукость, возможно команда уважает только код, возможно еще нет никаких разумных управленческих процессов. Причин много, а результат один: пиши код блеать.
— Технические эксперты (иногда «архитекторы» ) — следят за обучением новичков, взаимодействием с другими отделами по коду, а так же принимают участие во всех общих технических решениях;
— Аналитики (которые могут быть весьма технически подкованы, и так же уделять время на разработку каких-то фич)
— Менеджеры продукта (которые уже решают более приближенные к бизнесу задачи)
В общем я не могу сказать что кто-то из них «главнее» или «важнее» (хотя может в каких-то авторитарных конторах и есть четкое подчинение этих ролей).
Так на мой взгляд, если человек хочет именно оставаться разработчиком, а на него скидывают обязанности по ПМству или подобному, то это косяк системы управления, нужно разделять роль «ведущего разработчика», иначе можно просто потерять специалиста от недовольства.
Согласен полностью, если есть возможность, то расти можно и нужно. Но чаще вот это вижу: «Principal. Not senior senior» https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html
В крупных компаниях принципалы хоть и есть, но решают они немного, если вдруг «нормальный менеджер» не согласен.
Мне очень помогла привычка не давать оценку сразу.
Увы, но у нас руководитель не дает такой возможности. Хоть какая-то оценка должна быть сразу.
1) Недоменеджмент
2) Неприятие введения новых технологий/новых технических идей от других
3) Постоянное сопереживание всем, недостаточная строгость/излишняя мягкость и вежливость
4) Попытки всем угодить
5) Недооценка своих возможностей
Хоть ещё одну статью пиши по каждому из пунктов.
Кстати пункты 2 и 4 как в вашем, так и в обратном списке тесно связаны и являются противоречиями друг другу в некоторых контекстах. Но бывают ситуации, когда они возникают и одновременно.
Из своего опыта сталкивался с 4 и 5 из вашего списка в своём опыте, из обратного с 1, 4 и 5 (то есть с 4 и 5 обе крайности были в деле). На одном из проектов встречался с командным проявлением пункта два из обратного списка, решения всегда принимались в сторону использования проверенных инструментов, даже для неподходящих для этого задач.
Выделить какой-то самый важный пункт не могу из этих списков, мне кажется одна из важных проблем на данной позиции будет «неумение анализировать результат своих решений и действий». Ошибаться будут все и всегда, важно вовремя обнаруживать и исправлять эти ошибки.
Насчёт оверменеджемнта стоит быть аккуратнее в суждениях. Есть и джуны и просто люди без большого опыта в этой сфере или те, у кого ещё с момента трудоустройства не успело сформироваться понимание идей проекта (а оно может формироваться ооочень медленно). Джунам ответственность надо вводить плавно и контроллируемо, с нехваткой опыта — перепроверить решения на этапе "как ты будешь это делать" и не стесняться править.
Тут могла бы быть притча о двух тимлидах в одной компании, но уверен, у вас и так есть свои точно такие же
Но сам факт того, что у джуна нет опыта не значит, что его не нужно приучать думать.
По поводу плавно и контролируемо — соглашусь.
Кстати, расскажите притчу о двух тимлидах, интересно :D
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.
Разумным мне кажется разрешить всем командам закладывать 20% времени (1 из 5 спринтов, или 2 дня из 2 недель) на задачи технического долга. Если этим заниматься регулярно, то он не только копиться не будет, может даже будут и ощутимые для бизнеса результаты.
я лично глубоко убежден, что не должно быть какого-то отдельного времени для решения техдолга. он должен удаляться в ходе решения текущих задач постепенно.
Интересно было бы развернуть и систематизировать имеющуюся теорию и опыт, хотябы на уровне «продвинутых чайников».
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают.
Увы, позитивные намерения есть далеко не «у всех». Для очень многих людей основной приоритет — напрягаться как можно меньше. Сделай тяп-ляп, создай видимость работы, а там, глядишь, разгребать завалы поставят кого-нибудь другого.
Если вы работаете в стабильной компании, и технический персонал совместно с менеджментом на ранних этапах выявляет таких халтурщиков и не допускает их к работе — вот тогда с некоторым допущением можно сказать, что у всех оставшихся есть позитивные намерения.
Подвох в том, что значительная часть задачи по выявлению таких деятелей лежит как раз на ведущем разработчике. Поэтому, ИМХО, лид должен по-умолчанию предполагать, что работник компетентен и выполняет задачи на совесть. Но при этом отношение должно быть «доверяй, но проверяй». Если человек не оправдывает доверия, надо от него избавляться или, в крайнем случае, переводить на наименее ответственную работу. Иначе, если принять как постулат позитивное отношение каждого человека к работе и полагаться на эмпатию, на вас в итоге свесят всех халтурщиков, и вы будете разгребать за ними культурные слои. Приблизительно как в ошибке #1. Испытано на собственном опыте…
А ведь есть еще люди которые не просто умеют в ИБД, но еще и мастерски перевешивают свои косяки на других (soft skills в курилке с начальником и все такое). Есть люди, живущие в альтернативной реальности, где они являются мега-разработчиками или мега-руководителями, а все факты, указывающие на обратное, — это ложь и провокация. И да, в этой альтернативной реальности они могут иметь офигенно позитивные намерения. Если подойдете к таким персонажам с эмпатией и займетесь поиском позитива, вами не просто воспользуются. Вас будут вертеть на известно каком органе.
А токсичности быть не должно, это да. Надо уметь выявлять коллег такого сорта и очень быстро с ними прощаться. Безо всякой токсичности ;)
По всем остальным пунктам с вами согласен. Спасибо за статью!
Пять ошибок, которые я допустил как ведущий разработчик