В большинстве компаний, которые занимаются командами и отделами программирования, состоят из программистов, которые разрабатывают и пишут код, и менеджеров, которые ... ну, занимаются вопросами управления. Помимо просто не написания кода, менеджеры обычно даже не смотрят на код, который разрабатывает команда, и даже могут не иметь надлежащей IDE на своих рабочих машинах.
Тем не менее, менеджеры должны судить, хорошо ли работает человек, должен ли он или она быть ответственным за что-то, или должен ли конкретный разработчик быть назначен на задачу, наиболее важную и ответственную. И последнее, но не менее важное: менеджеры обычно назначают ежеквартальные бонусы!
Для эффективного выполнения вышесказанного менеджер должен знать, является ли человек хорошим программистом - конечно же, среди других качеств. Вопрос в том, как они это делают? Они даже не смотрят на код, который пишут люди, они не могут напрямую оценить качество компонентов, разработанных программистами ... но их оценки того, кто является хорошим программистом, а кто "не так хорош", тем не менее верны в большинство случаев!
В чем секрет?
источник
Ответы:
Обычно менеджер будет смотреть на
Это правда, что они обычно не видят (или часто не понимают) код работника, но вышеприведенное для них служит разумным показателем для определения того, насколько хорошо работник вписывается в роль программирования, навязанную ему его работодателем. Если кто-то не выполняет работу, получает низкие оценки от своих коллег, не может хорошо общаться, разочаровывается в других технологиях, к которым он привык, всегда нуждается в надзоре и всегда несчастен, это хороший признак того, что он не ' хорошо справляюсь с этой работой. *
* Может случиться так, что в другом контексте и среде они будут очень счастливы и полны энтузиазма. Может быть, это просто тот программист, против которого они возражали, и они могли бы очень хорошо программировать в другом контексте. «Программист» может означать очень разные работы в разных местах. Но менеджера больше всего заботит их роль «программиста» и то, насколько хорошо подходит сотрудник.
источник
Я не согласен с утверждением, что менеджеры не смотрят на код. Когда я управлял командами, я смотрел на некоторые результаты работы каждого инженера - и большая часть - это код. Но не единственный - электронные письма, дизайнерские документы, технические документы - все это имеет значение.
Но это определенно не единственный фактор. Если один парень сидит в углу и пишет великолепный код, но с ним можно общаться, он не отвечает на вопросы, не делится статусом и не идет на компромисс, когда возникают проблемы с развитием - я не уверен, что он актив для команды. Особенно по сравнению с парнем, который пишет умеренно приличный код, но может делать все вышеперечисленное.
Вот некоторые вещи, на которые я обращаю внимание, когда я в состоянии выдавать награды, но с огромным предостережением, что это абсолютно инстинктивная реакция, потому что ни одно из этого не может быть определено количественно:
И чужой вклад. Часто я был в положении, когда разные инженеры отвечали за различные части проекта. Иногда команда ведет, а иногда и просто владелец определенного выхода продукции (например, «парень сборки»). Люди любят говорить о крайностях - актах героизма или разочаровании проблемных детей. Обычно в процессе решения этих проблем я узнаю много о ОБАХ вечеринках.
Там также есть фактор, касающийся управления людьми . Ни один инженер не такой, как любой другой. Таким образом, они не все сияют в одном свете. Один пишет блестящий код без ошибок, а другой помогает решить сквозные проблемы, которые нарушают код каждого. Один велик лично, другой лучше в письменной форме. Один из них бессвязен в 9:00, а другой отсюда к 3:00. Существует определенная необходимость сделать шаг назад, выяснить, что является наиболее полезным для команды и что может быть фактором личной предвзятости (например, желание убить этого бодрого парня в 4:00 утра, просто потому, что я не могу работать до 11: 00 утра).
источник
Это варьируется в значительной степени в зависимости от технических знаний менеджера.
источник
if you're somehow able to look like you've having a direct influence on the outcome
, Это то, что в наибольшей степени используется хорошим бонусом, но плохим разработчиком кода.Как правило, они этого не делают.
Вот почему программирование - это «Рынок лимонов». http://en.wikipedia.org/wiki/The_Market_for_Lemons
Код испорчен, и это обычно не на 2-3 года, прежде чем вы узнаете. Программисты, как правило, остаются 18 месяцев, поэтому вы никогда не увидите виновников неудачи.
Менеджеры должны поверить на слово, что, например, выпуск занимает четыре месяца и сто итераций. Может быть, вы редактируете множество файлов развертывания вручную и читаете файлы журналов вручную для ошибок, смешанных со статусом? Они не знают, что это можно сделать лучше.
Так что будьте честны, профессиональны и старайтесь совершенствоваться. С опытом менеджер начнет видеть шаблоны хорошего и плохого поведения.
источник
Я начну с грубого обобщения: большинство менеджеров не могут отличить «хорошего» программиста от «плохого» программиста.
Если учесть, что большинство менеджеров (с которыми я встречался или работал) считают «хорошим» в программисте, - это не тот набор навыков, который другой программист счел бы «хорошим».
Менеджер, ориентированный на результат, будет искать такие вещи, как «умный» и «добивающийся успеха». Они не будут заботиться о том, чтобы вы приходили на работу в спортивных штанах, если вы выполняете работу вовремя и в рамках бюджета.
Менеджер, ориентированный на процессы, больше заботится о том, «как все делается». Это означает, что вы должны приходить на работу вовремя, носить правильную одежду и иметь ли вы правильный титульный лист в отчете TPS.
Быть «ответственным» требует иных навыков, чем написание кода. Если человек обладает человеческими навыками, необходимыми для руководства командой, то этому человеку следует воспользоваться для этого. Если вы будете продвигать людей, основываясь на ключевых элементах работы, которую они выполняют в настоящее время, в конечном итоге они достигнут уровня, на котором они теперь некомпетентны. Это называется принцип Петра .
источник
Очевидно, что это всегда помогает иметь грамотного в программировании менеджера, который действительно может читать код и, что еще более важно, углубляться в систему отслеживания ошибок и понимать, что происходит, знать, что не все ошибки созданы равными, и только своевременная доставка плохого кода не считается за многое.
Но это идеальный случай. Для менеджера, чтобы получить меру программиста с нетехнической точки зрения, у меня есть несколько предложений.
Если применимо какое-либо или все из них, у вас наверняка будет хороший программист. Заметьте, что хорошим программистом я не просто оцениваю их способность кодировать, но и другие полезные вещи, такие как способность общаться с другими людьми ;-)
источник
Менеджер может не знать, когда код, который вы пишете, великолепен или его можно улучшить с помощью огромного фактора, но он знает, что он: уложился ли срок в код, который работал? Вы человек, которому он может доверять, чтобы решить проблемы, которые создают другие люди? Заметил ли клиент или пользователь проблему, которая обострилась до его менеджера? Была ли серьезная катастрофа на ваших часах (удалил пользовательскую таблицу, забыл настроить резервные копии, отправил электронное письмо клиентам с собственными данными другого клиента, которых они не должны были видеть, и т. Д. Кто-нибудь похвалил вашу работу ему (особенно в письменной форме) )? Люди говорят хорошие или плохие вещи за вашей спиной?
источник
источник
Менеджеры сами являются кодировщиками и поэтому могут с помощью простого наблюдения выяснить, хорош кодер или нет.
Если ваши менеджеры не являются программистами (и вы занимаетесь разработкой программного обеспечения), вы облажались.
источник
Как менеджер, вот несколько вещей, на которые я смотрел при оценке моих программистов:
Обратная связь с коллегами. Я попросил программистов из моей команды и программистов из других команд прислать мне отзыв о моих людях.
Уважение сверстников . Когда мои программисты сталкиваются с проблемой, которую не могут решить, они говорят: «Пойдем, спросим у такого-то совета».
Получает вещи делать . Я говорю «Я хочу Х», и на следующий день Х готово.
Получает умные вещи . Я говорю «Я хочу Х», и на следующий день не только Х завершен, но и все Х-подобные вещи решены и не требуют дополнительного внимания.
Исправляет меня . Я говорю «Я хочу X», а программист говорит: «X не прав, мы должны сделать Y, и вот почему».
Там не так много хороших менеджеров (см. Смежный вопрос: как программисты узнают, хороший человек или плохой менеджер?). Хорошо управлять людьми очень сложно, и это требует много времени и тяжелой работы. Как только я управлял пятью людьми, у меня почти не было времени на программирование. Когда я управлял 8+ людьми, я больше не мог управлять ими так, как они заслуживали.
источник
Я думаю, что предпосылка вашего вопроса несколько ошибочна, поскольку утверждает, что менеджеры на самом деле не смотрят на код. Я работал во многих ситуациях, когда мои менеджеры были коллегами-инженерами и активно участвовали в проверках кода.
Тем не менее, определенно существует множество ситуаций, в которых нетехнические лица отвечают за разработчиков программного обеспечения, и они не могут полагаться на свои собственные знания и опыт.
В этих случаях ответственные менеджеры обратятся за советом к инженерам. Они попросят нетехнических людей в организации, с которыми взаимодействует инженер, выяснить, обладает ли он хорошими навыками, совместимыми с повышенной ответственностью.
Безответственные просто пойдут со своими "внутренними" реакциями, если они используют какие-то вообще не поддерживаемые "метрики".
Это дерьмовая стрельба, но вы всегда можете бросить курить и надеяться на что-то лучшее в другом месте.
источник
Там, где я работаю, когда приходят оценки сотрудников, менеджеры отправляют неформального анонимного опрашивающего тем, кто регулярно общается с сотрудником; как коллеги-разработчики, так и клиенты. Это дает коллегам-разработчикам возможность вносить вклад в производительность в качестве кодера, который менеджеры могли бы игнорировать.
источник
Менеджер должен смотреть на измеримые. Какие аспекты работы измеримы с точки зрения выполняемой работы, качества работы. Они могут не знать, выполняете ли вы качественную работу, если вы не генерируете много ошибок или не позволяете конечному пользователю делать то, что он должен делать.
Ваша работа требует от менеджера больших затрат, поэтому вы должны быть финансово прибыльными, чтобы продолжить работу.
источник
Я не говорю, что это лучший способ сделать это, но они могут основывать это на удовлетворенности клиентов. Если им нравится приложение, они принимают количество ошибок и считают, что вы своевременно добавляете новые функции, разве ваши разработчики могут быть настолько плохими?
Конечно могли. Они могут использовать грубую силу посредством кодирования, потому что у вас есть 10 человек, делающих работу двоих. Или клиенты довольны, потому что вы так дешево продаете свое приложение.
Еще одна проблема, связанная с этим подходом, заключается в том, что вам нужно подождать, пока приложение будет практически завершено, прежде чем нетехнический менеджер сможет получить какую-либо обратную связь от клиента. Создайте приложение в течение года, только чтобы выпустить его, и никто не любит его.
Жизнь была бы проще, если бы вы могли рассчитывать на то, что скажете людям: «Просто заставьте это работать». Когда вы понимаете и заставляете людей придерживаться правильного процесса, вы устраняете много проблем. Вы можете иметь требовательные сроки, которые являются реалистичными. Любой дурак может выдвинуть нереальные требования и рискнуть потерять талантливых людей.
источник
Я думаю, что большинство из нас в технической команде знают, кто качает, а кто сосет. Если у вас нет огромного оборота, крем поднимается наверх, а мертвый вес падает. Разбойники всегда испытывают какие-то проблемы - они забывают протестировать свой код перед тем, как регистрировать его, поэтому сборка ломается, у них всегда есть оправдание, когда они ничего не делают, и так далее, и тому подобное.
источник
Я думаю, что они не знают, является ли кто-то хорошим программистом , потому что у них нет навыков, чтобы сделать это. Они проверяют, является ли кто-то хорошим разработчиком . Программирование - деятельность развития, но у развития есть много других. Таким образом, они проверяют, вовремя ли вы, правильны ли ваши оценки, есть ли много недостатков в том, что вы сделали в вашей системе отслеживания ошибок, в ваших мягких навыках, приверженности, общении и т. Д.
Некоторые гуру иногда забывают и расстраиваются из-за того, что наша работа не только программирование, у нас есть много других дел, которые также очень важны. Хотя ваш менеджер не будет смотреть на то, как выглядит ваш код (потому что он для него совершенно не важен), он проверит, являетесь ли вы командным игроком, ответственным, уважительным и в целом выполняете качественную работу .
Иногда я думаю, что код переоценен.
источник
Я думаю, что очень мало людей (не говоря уже о менеджерах), которые не имеют общего понимания порядка распределения для разработчиков. Все думают, что они первоклассный разработчик, единственные люди, которые не знают, кто такие плохие разработчики, это сами эти плохие разработчики. В любом случае, если бы вы пошли вокруг и попросили кого-то оценить разработчиков, с которыми они работают, я уверен, что для большинства людей это будет непростой задачей. Таким образом, нет никакого волшебства в определении того, кто работает очень хорошо, а кто - средний или плохой и т. Д. ... Единственная ошибка, с которой разработчики и менеджеры не согласятся, с этими типами продавцов, громкими, которые звучат так, как будто они знают, о чем говорят о, но на самом деле нет. Большинство менеджеров сбиты с толку ими, а разработчики - нет.
После этого именно уклон вашего менеджера определяет ваш рейтинг. Для некоторых программирование - это задача начального уровня, поэтому, хотя вы, возможно, отлично умеете кодировать, оно не даст вам того продвижения, которое вы ищете. В то время как другие рассматривают дизайн или архитектурные аспекты как наиболее важные. И другие считают, что определение требований и сбор (т.е. бизнес-анализ) является наиболее важным. Если вы хотите знать, что важно для вашего менеджера, и у вас нет рейтинга лучших сотрудников, спросите их, что мне нужно сделать, чтобы получить рейтинг лучших сотрудников? В этом ответе вы также узнаете, что для них важно, и тогда вам нужно убедиться, что вы преуспели в этих важных областях.
источник