Что, если я лучший разработчик, чем мой руководитель группы?

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

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

Подумайте об этом так: Авраам Линкольн руководил Гражданской войной, но он не был ни генералом, ни великим бойцом. Стив Джобс руководил Apple, но он не был великим инженером.

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

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

А какую радость вы бы получили от навязывания этого взгляда? Вы хоть знаете, чем хороши SOLID и DRY? Знаете ли вы, что в «Чистом кодировании» Роберт Мартин тоскует по дням вырезания и вставки кода? Простого знания и использования принципа недостаточно, чтобы убедить других, почему он хорош. Может быть, это сократит время разработки, или, может быть, руководитель вашей группы придерживается (разумного) мнения, что код, вырезанный и вставленный несколько раз, намного проще и с ним легче справиться, чем с расползающимся зверем фабричных шаблонов, который сочетает в себе принципиально разные бизнес-логики. .

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

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

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

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

Итак, отвечая на ваши вопросы:

Должен ли руководитель группы быть знаком с лучшими практиками?

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

Что, если я лучший разработчик, чем руководитель группы?

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

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

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

Должен ли я попытаться «занять его место» в качестве лидера команды?

Я бы вообще этого не делал.

Что я должен делать?

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

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

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

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

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

на каждую строку кода, которую я рефакторю, будет 10 новых

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

В этом случае я предлагаю вам задать вопрос не столько «что, если я лучший разработчик, чем мой руководитель группы?», сколько «как я могу внедрить лучшие практики перед лицом сопротивления со стороны опытных/старших разработчиков?»

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

Размышляя вслух, я также задаюсь вопросом, может ли ваш руководитель группы чувствовать давление, чтобы продолжать писать код в дополнение к руководству командой. Возможно, он чувствует, что ему нужно быть таким же продуктивным, как он был, когда он был «просто» программистом, а также выполнять свою руководящую роль. Возможно, причиной плохого качества его проверок может быть кажущаяся нехватка времени; возможно, ему нужно больше доверять своей команде, чтобы выполнять работу, пока он сидит на заднем сиденье. Я не знаю, но, возможно, стоит рассмотреть ситуацию с его точки зрения — может быть, даже обсудить ее с ним в неформальной обстановке, просто чтобы прощупать его («Доброе утро, босс — так что, сегодня у вас много дел?» - открытие!). Это поможет узнать, плохой ли он программист, который не он даже не знает об этом, но имеет право отменять действия любого, кто укажет на это (очень трудная ситуация), или когда-то был хорошим программистом, но из-за своих руководящих обязанностей у него больше нет времени делать это должным образом, и ему просто нужно научиться позволять вам и все остальное время справляться с этим. С лучшим пониманием этого ваш путь может стать яснее.

Было бы рекомендовано попробовать «занять его место» в качестве лидера команды?

Нет.

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

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