Можете ли вы быть менеджером и программистом одновременно? [закрыто]

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

Это очень распространенная схема, по крайней мере, в компаниях, в которых я работал.

Можете ли вы быть хорошим программистом или хорошим менеджером, если вы делаете оба одновременно?

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

ОБНОВЛЕНИЕ : мой вопрос касается управления компанией (в моем случае), а не управления командой. Но я заинтересован в обоих, конечно.

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

Быть менеджером означает много перерывов, смены тактики, таких как встречи и т. Д.

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

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

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

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

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

В-третьих, клиенты были довольны, поскольку их неотложные проблемы были решены довольно быстро.

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

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

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

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

Я был менеджером программных проектов в течение многих лет, с различными компаниями, проектами и командами.

Управление проектами и программирование - это настолько разные виды работ / ролей, что я бы сказал, что вы не можете выполнять обе задачи одновременно на «превосходном» уровне. Это компромисс - мастер без дела, мастер на все руки, что-то в этом роде.

Для меня самая большая боль - переключение контекста между режимом менеджера и программиста. Кажется, они затрагивают разные части мозга (или что-то в этом роде). Один день программирования, один день управления я могу делать хорошо, но переключаться между этими ролями постоянно сложно.

Я видел оба сценария. Менеджеры разработчиков, занимающиеся кодированием, занимают {некоторый процент своего времени}, а менеджеры разработки вообще не занимаются программированием.

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

(Конечно, есть компании, в которых вы можете продвигаться через Dev, ведущий Dev - в отличие от Dev Manager, конечно - на такие должности, как Architect и т. Д.)

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

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

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

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

Для тех, кто рассматривает этот путь, несколько советов:

• Освободитесь от роли в архитектуре и определите лидеров в вашей группе.

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

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

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

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

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

Хороший менеджер может быть, да. Пока вы остаетесь настойчивым и последовательным, обычно проблем не возникает.

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

Как вы сказали, это чрезвычайно распространено в начинающих компаниях.

Я думаю нет.

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

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

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

Из моего ограниченного опыта я не нашел никого, кто бы управлял другими программистами и кодами, как полноценный программист.

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

Спольский написал в своей статье об уровне абстракции разработчика следующее:

«В компании-разработчике первоочередной задачей менеджмента должно быть создание этой абстракции для программистов».

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

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

Он все еще один из лучших разработчиков, которых я знаю.

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

Лучший менеджер, который у меня когда-либо был (я был в бизнесе около 25 лет), был активным разработчиком, моим менеджером и пол-владельцем компании (около 40 сотрудников). Он был особенным, но он явно преуспел в этом вопросе.

Конечно, нет!

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

Хотя менеджер в технической компании ДОЛЖЕН .. нет ... ДОЛЖЕН знать, как кодировать. Вы просто не сможете оценить или понять проблемы клиента. Кодирование и управление - это два типа людей. С одной стороны - гики и неловкие люди (смирись с этим, гики, ты понимаешь, о чем я говорю), а другая - с людьми. Вы должны выбрать сторону. Вы не получите ничего с кодированием, если вы сделаете оба. Если вы любите программировать и можете делать это 24/7, если ваша жена не мешает вам, оставайтесь в стороне от управления. Даже сократить зарплату, если вам нужно. Я собираюсь сделать это, но я не думаю, что начальству это понравится, потому что я облегчаю им жизнь, выполняя управленческую роль. Мне придется вернуться к фрилансу, если они не согласятся, потому что счастье и заниматься любимым делом гораздо важнее денег и иллюзий, которые они покупают.

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

Прочитайте раздел «Отсутствие ориентированного на программирование пути карьеры» на этом сайте. Довольно хороший материал и очень актуальный: http://c2.com/cgi/wiki?ProgrammingIsNotFun

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

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

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

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

Так что я думаю, что нет четкого ответа, но я стараюсь не смешивать слишком много. Мои 2 цента

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

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

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

Учитывая нормальное рабочее время, я не думаю, что такая двойная роль - хорошая идея. Управляющий программист (или менеджер по программированию) всегда испытывает желание делать большую часть программных вещей сам, вместо того, чтобы заставлять своих программистов делать это. Всегда есть оправдание: «объяснять, а не сделать это занимает больше времени», но в долгосрочной перспективе 50% программистской работы, которой он занимается, не хватает в части управления, поэтому другие программисты менее эффективны.