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

Я разработчик Full Stack и работаю в только что созданной команде из 4 человек. Есть еще один парень (назовем его Том), которого наняли вместе со мной. Так что мы двое новички в этой компании.

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

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

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

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

PS: Два других разработчика работают на полную ставку с суперстаршими ролями. У них больше дел, кроме написания кода. Поэтому они позволили нам, новичкам-джуниорам, сделать всю реализацию.

Организация какая-то странная. У вас есть 2 младших разработчика, которые кодируют, и другие супербоги, которые позволяют джуниорам выполнять эту работу. Мне любопытно, какие супер важные роли исполняют два других супермладших человека? В любой другой организации, в которой я работал, никому не требовался 1 суперкрутой парень, чтобы контролировать 1 младшего парня. Основываясь на вашем описании, я бы подумал, что эти 2 суперстарших человека бесполезны.
Поскольку Том, похоже, готов помочь вам, поработайте над тем, чтобы стать приятелями и заставить его объяснить вам свой план игры и приемы. Слепое печатание того, что он вам говорит, делает вас его секретарем, а не разработчиком. Спросите его , почему он предпочитает делать что-то определенным образом. Сядьте с ним за обедом и попросите его объяснить вам архитектуру. Задавайте вопросы и стремитесь понять, что происходит, а не просто слепо следовать его примеру. Стремитесь стать его партнером , а не помощником. Если он использует технику, с которой вы не знакомы, попросите разъяснений и проведите небольшое исследование, чтобы догнать его.
Мы с Томом большие друзья. Том ВСЕГДА готов мне помочь. Я задаю вопросы, он дает развернутый ответ; только часть того, что я понимаю. Кажется, это будет продолжаться вечно. Как будто Том делает огромные успехи, а я просто поддерживаю. У двух других членов команды есть свои вещи. Один из них посвятил себя тому, чтобы покрыть проект как можно большим количеством модульных тестов, а другой — тестер плюс devops.
Некоторые люди просто «получают» хороший дизайн кода, другие борются. Вполне возможно, что вы один из тех людей, которые могут справиться с небольшими повторяющимися задачами, которые, кажется, всегда нужно делать, которые могут утомить жизнь Тома до такой степени, что он будет постоянно делать ошибки. Не у всех есть талант, который считается гламурным, но иногда эти маленькие щепетильные задачи являются более необходимыми.
Даже если вы не можете полностью догнать его уровень, вам это и не нужно. Что вам нужно, так это повысить свои навыки достаточно справедливо, чтобы вы могли взять более интересную историю и быть в состоянии знать, когда вы не сможете, и позволить ему взять. Конечно, вы должны проверить, как он это сделал.
@SalvadorDali - Мне нравятся твои работы, Сальвадор, но я думал, что ты умер? В любом случае, хотя в данном случае это не звучит так, два суперстарших парня могут заниматься делами, которые привносят бизнес в компанию, такими как помощь с предложениями, поддержка торгового персонала, взаимодействие с клиентами или управленческие задачи. Довольно часто бывает, что чем старше становится человек, тем меньше ему приходится кодировать. Кроме того, это не похоже на то, что «1 супер крутой парень был назначен для проверки 1 младшего парня». Просто так получилось, потому что у «супер крутого парня» есть «видение» и навыки.
Представь, если бы Том так и не пришел. Вы все равно застряли бы со старой архитектурой, не зная, хорошо это или плохо, работаете медленно или задачи слишком сложны, не зная, как можно сделать что-то лучше, быстрее и эффективнее. А теперь представьте, что вы разговариваете с собой год назад. Вы видите, насколько лучше вы уже стали? У вас есть действительно уникальная возможность очень быстро получить многолетний опыт - все, что вам нужно сделать, это следовать за Томом и впитывать все его знания. Возможно, вы не станете так же хороши, как Том, но вы точно станете намного лучше, чем вчера. Иногда я Том, и мне хочется, чтобы был еще один Том.
Попросите Тома стать вашим наставником.
Как давно вы начали? Возможно, вы слишком строги к себе. Я согласен, что Том звучит великолепно, и здорово, что у тебя есть коллега, у которого можно поучиться. Проводите столько времени, сколько сможете, работая с ним и разговаривая с ним, тратьте столько свободного времени на чтение/обучение, сколько сможете. Всегда будут люди умнее нас, и, вероятно, это будет один из ваших лучших опытов.

Ответы (8)

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

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

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

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

Меня обвиняли в том, что я бог программирования. Я не просто следую простым правилам, которые, как я обнаружил, приводят к хорошим проектам, которые быстро создаются и меньше глючат. Этим техникам может научиться каждый.
@richard, ты не придаешь себе должного значения. Конечно, любой может научиться техникам, но уметь их умело использовать — это совсем другое дело. Любой может научиться размахивать бейсбольной битой или клюшкой для гольфа, но это не значит, что каждый будет хотя бы отдаленно уметь бить по мячу.
см. ted.com/speakers/carol_dweck — я не отрицаю, что у меня есть талант. Я просто говорю, что большинству из них можно научиться. «Если вы думаете, что можете научиться чему-то новому, или если вы думаете, что не можете, то вы правы».

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

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

Да, у меня есть эти основы. Но вы можете сделать очень немногое, если только не воспользуетесь какой-то принципиально новой идеей. Вот почему я задал этот вопрос здесь.
@DivyanthJayaraj Возможно, вы можете сделать так много. Возможно, вы в конечном итоге дойдете до уровня Тома, или нет, потому что Том пожертвовал своей личной жизнью, чтобы преуспеть в работе, и/или он намного более увлечен, чем вы. Как заявляли другие, отсутствие положительного отношения к ситуации — худшее, что вы можете сделать для себя и компании.

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

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

Какой характер у Тома?

Личность Тома сильно влияет на то, насколько он может и будет готов вам помочь. Если он не против помочь / научить вас, воспользуйтесь этим в полной мере. Если он упрям ​​и/или ему не хватает личных навыков, узнайте как можно больше из Интернета, отточите свои навыки и начните искать новую работу в другом месте. В обоих случаях внесите свой вклад. Если у вашей программы нет тестировщиков, сосредоточьтесь на тестировании его кода. Для этого есть много причин: это поможет вам изучить его вещи, это поможет вам быть занятым и продуктивным, это подтверждает, что его код является кодом уровня гения, а не кодом операции с фрикадельками (последний, который некоторое время выглядит хорошо, а затем разваливается). ).

Совет для лидеров

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

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

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

Кроме того, нелегко научиться отступать и позволять другим людям выполнять задачи, которые вы могли бы выполнять в два раза быстрее, и оставлять позади более надежный код. Тому нужно научиться позволять другим людям пытаться и, возможно, делать ошибки. Возможно, ему придется что-то исправлять, но в долгосрочной перспективе он не сможет делать все в одиночку.
Мне нравится ваш комментарий о хирургии фрикаделек против гения. Есть много способов показать, что вы знаете, о чем говорите, но на самом деле вы полны этого. Вы также говорите о сопровождении кода. Я помню, как кто-то сказал, что хорошим программистом является способность писать удобочитаемый код для других, потому что если вы не можете, то вы не очень полезны. Напоминает мне одного участника соревнования по программированию, которого все называли таким умным и «гениальным программистом», но когда судьи пошли читать его код… они не могли его понять. У вас может быть логика, но не то, как ее правильно представить.
Я называю хакером того, кто просто пишет код, который хоть как-то работает, какой бы сложной ни была задача, но понять его можно только при наличии подробных объяснений или требующих, чтобы действительно умный человек понял хакера. Определенно не гений, по крайней мере, с точки зрения разработчика программного обеспечения. Настоящий гений берет что-то действительно трудное для понимания и делает это простым. Это также то, как я определяю хорошего инженера в целом.

Я не знал, что ты так себя чувствуешь...

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

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

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

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

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

Вы уверены, что Том такой гений, каким вы его считаете? Это читается как введение в историю Daily WTF, где появляется Том, заново реализует систему и говорит хорошую фразу, но всякий раз, когда кто-то действительно смотрит на его код, он на самом деле небрежен и безоснователен.

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

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

Он тратит время на парное программирование и инструктирует вас, так что постарайтесь учиться у него.

У меня есть младшая коллега, гораздо менее опытная, чем я (я программирую еще до ее рождения). Мы занимаемся не парным программированием, а регулярными проверками кода, и через 1-2 месяца я вижу, что она становится лучше до такой степени, что, по моим оценкам, через 1-3 месяца я могу удалить себя из этой части проекта и позволить ей сделать это самостоятельно.

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

Несколько практических советов:

  • в спринте вы должны оценить, как вы видите задачу — оценка пользовательских историй работает только в том случае, если каждый выскажет свое мнение

  • принятие задачи не означает, что вы должны делать ее без посторонней помощи - обратитесь за помощью в ежедневном стендапе

  • если истории невыполненных работ становятся настолько сложными, что только один человек в команде даже чувствует себя способным понять их влияние и масштаб (при условии, что вы занимаетесь скрамом), тогда требуется уточнение/разделение истории. Наличие описания истории, которое не понимает команда в целом, неприемлемо.

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

Что мне делать, если я чувствую себя в тени чрезвычайно талантливого члена команды?
СпросиСетьПолитика конфиденциальности1y, 0v