Варианты для ведущего программиста, который предпочитает программирование ведущему? [закрыто]

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

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

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

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

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

В моей компании меня повысили до руководителя группы (они называют его «руководителем проекта»), и из-за нехватки людей, которые знакомы с продуктом и имеют достаточный опыт, я вызвался руководить двумя разными командами. Несколько месяцев назад, «чтобы помочь с графиком», руководство удвоило размер этих 2 команд.

Что-то, что я пытался сделать ...

1. Дайте понять всем (включая руководство), что моя и чужая должность не являются постоянным назначением. Все желающие могут подняться на сцену, взглянуть на проект в более широком смысле и принять участие в принятии архитектурных / дизайнерских решений. У меня будет последнее слово (пока), если есть разногласия без разрешения, но пока этого не произошло.
2. Сосредоточьтесь на том, чтобы помогать другим людям развиваться и расти. У меня были (почти философские) дискуссии с разными разработчиками в разное время о кодировании и дизайне и разных подходах к выполнению задач. Некоторые из этих обсуждений связаны с реальной работой, другие являются чисто мысленными упражнениями. У меня был парень с более чем 20-летним опытом, я вернулся к его книжной полке и взял книгу по C ++, потому что он интересовался некоторыми низкоуровневыми вещами, которые я делал с шаблонным метапрограммированием. Эти обсуждения несколько заразительны, и после того, как вы поднимаете эти темы достаточно много раз, люди начинают думать об этом самостоятельно.
3. Делегируйте как можно больше людей. Хотя я смотрю на многие вещи, я не участвую в каждом обзоре кода. Вместо этого я делаю рецензии кода для наших промежуточных парней и позволяю этим парням делать рецензию кода для некоторых из более зеленых людей. Я считаю обзоры кода скорее инструментом передачи знаний, а не «давайте удостоверимся, что мы прочитали каждую строку и нашли все возможные ошибки».
4. После того, как интерфейсы определены и базовый дизайн создан, я позволю даже новичкам иметь как можно больше свободы при кодировании внутренних классов. Да, большая часть этого кода далека от совершенства, но она проверена и работает. Если он пересекает определенную субъективную границу в терминах «запаха кода», и они не подвергли его рефакторингу, я бы предложил, чтобы определенные классы были разбиты или переставлены. Иногда это больно, но когда я проверяю несколько дней спустя и получаю ответ: «Мне неприятно это признавать, но сейчас этот код выглядит намного лучше», что на самом деле вызывает у меня теплое, нечеткое чувство.
5. Бросьте вызов людям. Вместо того, чтобы назначать им функцию для добавления в продукт, попросите их добавить эти функции, но сделайте это, не увеличивая число функций / членов данных в существующих классах. Если вам нужно добавить что-то новое, вы должны взять что-то существующее и найти время, чтобы понять, что это такое. Все знают о рефакторинге, но вначале без лишних усилий кажется, что людям нужна помощь, чтобы перейти к реальному действию. Как минимум, я считаю необходимым посещать этот пункт практически во время каждой проверки кода.
6. Все о балансе. Вы не можете быть единственным старшим человеком в команде, который смотрит на всех остальных. Вы не можете провести всю неделю в собраниях и обзорах. Вы не можете ожидать, что поймаете каждую ошибку, которую совершает ваша команда. В конце дня вам нужно выделить время для себя, чтобы быть лидером, но вы также должны выделить время, чтобы быть разработчиком. Я бы сошел с ума, если бы не мог кодировать. Даже несмотря на все остальное, я все еще уверен, что у меня есть время, чтобы написать код, и не просто код, а некоторые действительно очень интересные вещи. Я только что взял в руки книги по мета-программированию шаблонов и начал копаться в Boost. Парни, которые придумали это, должны быть безумными (в хорошем смысле). Если ваше руководство начинает задавать вам вопросы о том, почему не все проверяется или почему noob просматривает другой код noobs, вам просто нужно объяснить весь баланс, и что команде просто не хватает опытных людей, и в конце дня «это то, что есть». Если в вашей команде есть старшие сотрудники, тогда пришло время расширить возможности и дать им свободу делать свои собственные проекты / обзоры / помогать другим, а не рассматривать их как просто генераторы кода. С расширением возможностей приходит свобода, и люди любят свободу. Если у вас есть разработчики, которые не заботятся о свободе / расширении возможностей, это нормально. Каждой команде по-прежнему нужны чистые кодеры, просто убедитесь, что вы стремитесь к равновесию. Пришло время расширить возможности и дать им свободу делать свои собственные проекты / обзоры / помогать другим, а не рассматривать их как просто генераторы кода. С расширением возможностей приходит свобода, и люди любят свободу. Если у вас есть разработчики, которые не заботятся о свободе / расширении возможностей, это нормально. Каждой команде по-прежнему нужны чистые кодеры, просто убедитесь, что вы стремитесь к равновесию. Пришло время расширить возможности и дать им свободу делать свои собственные проекты / обзоры / помогать другим, а не рассматривать их как просто генераторы кода. С расширением возможностей приходит свобода, и люди любят свободу. Если у вас есть разработчики, которые не заботятся о свободе / расширении возможностей, это нормально. Каждой команде по-прежнему нужны чистые кодеры, просто убедитесь, что вы стремитесь к равновесию.
7. Ваше время ценно. Поэтому попросите команду отправить вам по электронной почте все не критичные ко времени вопросы, на которые они могут подождать несколько часов, прежде чем получить ответ. Когда вопрос задан, вся команда должна быть скопирована на него. В конце концов, когда у вас перерыв в работе, вы можете взглянуть на проблему и помочь человеку, но много раз кто-то, возможно, уже избил вас до ответа, и вам не нужно ничего делать. Очевидно, что в качестве лидера я все еще делаю себя доступным и разъясняю этот факт, потому что я верю, что одна из моих целей состоит в том, чтобы никто из команды не застревал в течение длительных периодов времени, не добиваясь прогресса.
8. Убедитесь, что ваша команда использует как можно больше инструментов, чтобы сделать общение более эффективным. Например, у нас есть вики-сайт, и каждый раз, когда одна и та же проблема возникает несколько раз, я спрашиваю последнего, кому я помогал создать вики-страницу.

Я не обсуждал это ни с кем в управлении

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

Когда ваш проект заканчивается, ищите более ориентированное на программиста положение в вашей компании или за ее пределами.

Обсудите с руководством, что вам нужно меньше управления и больше технических навыков.

Звучит так, как будто вы в личке, а не у ведущего разработчика. Я бы посоветовал ведущему разработчику больше программировать.

Перспектива работодателей :

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

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

Дайте им путь, чтобы поддержать вас, создав план преемственности. По сути, вы находите кого-то в текущей команде, кто заинтересован в том, чтобы делать то, что вызывает у вас головную боль, в течение следующих 6–9 месяцев вы тренируете его, выполняя свои задачи по одному.

Сначала выберите что-нибудь легкое, например, еженедельные обновления статуса:

• Сидите рядом с вами, когда вы делаете обновление статуса.
• Сядьте рядом с ними, пока они делают следующее обновление статуса.
• Позвольте им сделать это самостоятельно и рассмотрите это прежде, чем это выйдет в финал.

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

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

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

Я думаю, что если бы вы представили вашему работодателю план на 6-9 месяцев, в котором говорилось

• Хорошее объяснение того, почему вы считаете, что лучше всего вернуться к тому, чтобы сосредоточиться на кодировании над другими обязанностями.
• Кого нужно подменять ... или они должны кого-то найти ... это будет ключевым фактором, я думаю.
• Rach месяц на 6 месяцев, какие обязанности вы бы передали новому человеку
• Какую ответственность вы бы взяли на себя (например, дизайн, возможно, сидите на обзорах кода и т. Д.).
• Идея о снижении заработной платы, которую вы бы хотели взять (где-то между оригиналом и сейчас), хотя позвольте им поднять это.

Если вы соберете это вместе как план для меня, как работодателя, я был бы более чем рад работать с вами, чтобы это произошло.

Удачи.

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

2 вопроса, которые не очевидны из вашего поста:

• Вы работаете в фирме, которая напрямую зарабатывает деньги на написанном вами программном обеспечении (например, Google, Microsoft или Fog Creek), или вы занимаетесь вспомогательной функцией (например, в банке или в продовольственной компании)?

• Является ли генеральный директор технологом или кем-то, кто вырос благодаря деловым ролям?

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

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