管理人员如何知道一个人是好是坏的程序员？

在大多数从事编程团队和部门工作的公司中，设计和编写代码的程序员以及负责……管理工作的经理组成。除了不编写代码之外，管理人员通常甚至不看团队开发的代码，甚至可能没有在工作计算机上安装适当的IDE。

尽管如此，管理者还是要判断一个人是否工作良好，是否应该负责某人，或者是否应该指派特定的开发人员来承担最重要和最重要的任务。最后但并非最不重要的一点：经理们通常分配季度奖金！

为了有效地完成上述工作，经理当然应该知道一个人是否是一个优秀的程序员。问题是，他们怎么做到的？ 他们甚至不看别人写的代码，他们不能直接评估程序员开发的组件的质量……但是他们对谁是一个好的编码者和谁不是那么好的估计在这方面是正确的。在大多数情况下！

有什么秘诀？

通常，经理会看

• 程序员完成工作了吗？
• 他们的同事如何看待他们？他们写的代码？
• 程序员与经理沟通清楚吗？
• 程序员喜欢学习新事物吗？他们会很好地指导别人吗？
• 他们需要很多管理层的关注才能完成工作吗？
• 程序员似乎从工作中得到乐趣吗？

的确，他们通常看不到（或经常理解）员工的代码，但是对于他们来说，以上内容可以作为一种合理的替代方法，用于衡量员工对雇主所施加的编程角色的适应程度。如果某人没有完成任务，从同事那里获得低分，不能很好地交流，对不同的技术感到沮丧，那么他们就习惯了，总是需要监督，并且总是不高兴，这很好地表明了他们不是。与这项工作配合得很好。*

*但是，在不同的背景和环境中，他们可能会感到非常高兴和热情。也许仅仅是他们反对的那种程序员，他们可能会在不同的背景下做得很好。“程序员”在不同的地方可能意味着完全不同的工作。但是经理主要关心他们的“程序员”角色以及员工的适合程度。

我不同意经理人不看代码的说法。当我管理团队时，我查看了每位工程师的一些输出-其中很大一部分是代码。但并非只有其中一个-电子邮件，设计文档，白皮书-都是所有因素。

但这绝对不是唯一的因素。如果一个人坐在角落里并编写出色的代码，但是他是一个与人交谈的野兽，不会回答问题，不会分享地位，也不会在开发问题出现时妥协-我不确定他是不是团队的资产。特别是与编写中等程度的代码但可以完成所有上述工作的人相比。

当我有能力给予奖励时，我会看一些东西，但是有一个巨大的警告，那就是它绝对是一种直觉，这是无法量化的：

• 状态 -是否清晰，准确和及时？在讨论时，这个人是处于状态之上还是在当前问题上有点模糊？当某物着火时，该人是否有做出红旗的正确判断？
• 解决问题 -提问和回答都很重要。这个人是否知道何时寻求帮助，或者他们无限期地在哪里旋转轮子？更好的是，当其他人遇到问题时，此人是否会帮助找到解决方案或成为问题的一部分？即使问题不在您的专业领域内，即使有明智的选择也值得一提。还有一些指向团体或公司之外的地方，或者去类似这样的网站或其他互联网答案的要点。
• 对过程的关注 -通常这是非常明显的-即使在一家不保留肛门的公司中，如果有人在推销该系统，就会看到他们留下的混乱局面。如果其他人由于不遵守指导或体系结构而正在清理他人的功能，那么我们就有问题了。加分点去那些谁想出办法使一致性和质量更容易。
• 完成率，漏洞，复杂度 -完成工作，但正确完成工作。每个人都有一些错误，但是如果这个家伙快速完成工作并且有错误，我们就会遇到问题。我通常发现这不是您每天可以评估的东西-它必须回顾发布，阶段或财政季度。

和其他人的投入。通常，我一直在由各个工程师负责项目各个部分的职位。有时团队负责，有时只是特定输出成果的所有者（例如“构建专家”）。人们喜欢谈论极端事件-英雄主义行为或问题儿童的挫败感。通常，在跟进这些问题的过程中，我会发现很多有关双方的事情。

关于“ 管理人”也有一个因素。没有工程师是完全一样的。因此，它们并不会完全一样。一个编写出色的无错误代码，而另一个编写有助于解决破坏每个人代码的交叉问题。一个人的才能很棒，一个人的写作才能更好。一个在9:00 AM前后不一致，另一个在3:00 PM之前不在这里。一定需要退后一步，弄清楚什么对团队最有利以及什么可能是个人偏见的原因（例如想要杀死那个凌晨4:00 AM的家伙，只是因为我要到11点才能工作）： 00 AM）。

这取决于经理的技术专长而变化很大。

• 在大多数情况下，他们可能会根据您的沟通方式来评判您。如何你与经理，以及如何你见过你的同事沟通交流。
• 如果您很幸运地拥有一位离经理更近的首席开发人员，那么经理可能会寻求首席开发人员的帮助。
• 请记住，经理的主要责任是做好事。他需要看到产生各种结果和目标以满足业务计划。因此，如果您能够以某种方式看起来对结果具有直接影响，那么这对您来说是个好兆头。

通常，他们没有。

这就是为什么编程是“柠檬市场”的原因。http://en.wikipedia.org/wiki/The_Market_for_Lemons

代码搞砸了，而且通常在不到2-3年的时间里才知道。程序员通常会停留18个月，因此您永远不会看到失败的原因。

经理必须信服您，例如，发布需要四个月的时间和一百次迭代。也许您正在手工编辑大量部署文件，并手工读取日志文件以了解与状态混合的错误？他们不知道可以做得更好。

因此，要诚实，专业，并努力提高自己。有了经验，经理将开始看到好和坏行为的模式。

管理人员如何知道一个人是好是坏的程序员？

我将从粗略的概括开始：大多数管理人员无法将“好”程序员与“坏”程序员区分开。

这样一来，大多数经理（我已经见过或为之工作）在程序员中认为“良好”的技能与另一位程序员认为“良好”的技能并不相同。

他们是如何做到的呢？

以结果为导向的经理将寻找诸如“智能”之类的东西，并“将其完成”。只要您按时按预算完成工作，他们就不会在意是否要穿着运动裤工作。

面向过程的经理更关心“事情如何完成”。这意味着要准时上班，穿正确的衣服，TPS报告中的封面是否正确。

一个人工作良好，如果他或她应该负责某事

“负责”与编写代码相比需要不同的技能。如果一个人具有领导团队所需的人际交往能力，则应利用这个人来做这件事。如果您根据他们当前正在执行的工作的关键工作要素来提拔他们，那么最终他们将达到一个他们现在没有能力的水平。这就是所谓的彼得原理。

显然，拥有一名编程素养的经理总是有帮助的，他可以实际阅读代码，甚至更重要的是深入研究Bug跟踪系统并了解正在发生的事情，知道并非所有bug都是一样的，并且按时交付不良代码并不重要很多。

但这是一个理想的情况。为了使经理从非技术角度来衡量程序员，我有几点建议。

• 他们是否迅速/定期/一致地强调在完成满足当前指定要求的工作时存在问题的地方...是否因此而烦恼（毕竟这是软件开发，如果不够复杂，不会出现这些问题，这不是一个真正的开发项目）。
• 如果他们不确定某件事，他们会立即说出来-只有对自己的能力有信心的程序员才能真正做到这一点（他们知道如果您不喜欢它，他们可以轻松地找到另一份工作）。相反，知道自己已深陷困境的人往往会躲起来寻找掩护。
• 团队中的其他程序员怎么说/暗示其他程序员？如果您是一位体面的经理，那么您将与编程团队保持紧密联系-特别是在集成测试/错误修复期间。因此，如果您没有收到此类反馈，则应该由其他人来完成您的工作。
• 我最喜欢的是：我所说的“ tomcat”程序员。如果过了一会儿，您不断注意到各种程序员总是在同一位程序员的办公桌前闲逛（假设他们在做工作并讨论一些麻烦的问题，而不是酷有趣的Web内容的常驻发现者）...那么这就是其他程序员的原因被吸引到那个人的桌子。如果他们还不是团队负责人，那么他们可能应该被尽快任命。

如果这些条件中的任何一个或所有都适用，那么您很可能会拥有一个好的程序员。请注意，优秀的程序员不仅会评估他们的编码能力，还会评估其他有用的东西，例如能够与其他人进行交流;-)

经理可能不知道您编写的代码什么时候才是出色的，或者是否可以通过巨大的因素对其进行改进，但是他所知道的是：您是否在有效期限内完成了代码？您是他可以信任的人，可以解决其他人造成的问题吗？客户或用户是否注意到上报给经理的问题？您的手表是否发生了重大灾难（删除了用户表，忘记了设置备份，向客户发送了一封电子邮件，其中包含他们本来应该没有看到的其他客户的所有权数据，等等是否有人赞美您的工作（特别是书面形式） ）？人们在背后说好还是坏话？

1. 在大多数情况下，经理不评估您的代码，而同行则对他们进行评估（无论是正式的还是非正式的，当他们尝试使用您的代码时）。您的老板将在某种程度上使用同事的意见（再次，无论是正式的还是非正式的）。
2. 总体的可靠性以及完成和完成任务的速度通常是非常重要的因素，与编码能力无关。
3. 通讯。如果您正在做很多事情并且做得很好，那么您的经理需要知道这一点！（当然，不要吹牛）。学会“管理您的经理”，而不仅仅是被动。帮助老板了解您的工作方式。

管理人员本身就是编码员，因此，通过简单的观察，他们就可以确定编码员是否好。

如果您的经理不是编码员（并且您从事的是软件业务），那么您会很困惑。

作为一名经理，这是我评估程序员时要注意的一些事项：

• 同行反馈。我要求团队中的程序员以及其他团队中的程序员向我发送有关人员的反馈。

• 同行敬重。当我的程序员遇到无法解决的问题时，他们说“让我们随便问一些建议”。

• 把事情做好。我说“我想要X”，第二天X结束了。

• 使事情变得聪明。我说“我想要X”，第二天，不仅X完成了，而且所有类似X的事情都解决了，不需要进一步关注。

• 修理我。我说“我想要X”，而程序员说“ X不正确，我们应该做Y，这就是原因”。

那里没有很多好的管理者（请参阅相关问题：编程人员如何知道一个人是好是坏的经理？）。善于管理人非常困难，需要大量时间和辛勤工作。当我管理5个人时，我几乎没有时间进行编程。当我管理8位以上的人员时，我再也无法管理他们应得的。

我认为您的问题的前提有些瑕疵，因为它断言经理实际上没有看代码。我曾在许多情况下工作过，当时我的经理是一名工程师，并积极参与了代码审查。

但是，肯定有多种情况，其中非技术人员负责软件工程师，他们不能依靠自己的知识和经验。

在这种情况下，负责的经理将请工程师的同伴寻求建议。他们将询问与工程师交互的组织中的非技术人员，以查看他是否具有与增加的责任相适应的良好人际交往能力。

不负责任的人会随他们的“胆量”反应一起去使用某种通常无法支持的“量度”。

这是胡扯，但您总是可以退出，并希望在其他地方有更好的东西。

在我工作的地方，当对员工进行评估时，经理会向与员工定期互动的人员发送非正式的匿名提问者；开发人员和客户都一样。这给其他开发人员提供了机会，可以作为管理人员可能忽略的编码人员来提供有关性能的信息。

经理必须考虑可衡量的。就完成的工作，工作质量而言，可以衡量工作的哪些方面。他们可能不知道您是否做得很好，除非您产生很多错误，或者不允许最终用户执行应做的事情。

您的工作使经理花了很多钱，因此，您必须在财务上获利才能继续工作。

我并不是说这是最好的方法，但是他们可以基于客户满意度。如果他们喜欢该应用程序，接受大量的错误并感觉到您及时添加了新功能，那么您的开发人员真的会那么糟糕吗？

当然可以。他们能够通过编码进行暴力破解，因为您有10个人从事两个工作。还是客户满意，因为您以如此便宜的价格出售应用。

这种方法的另一个问题是，您必须等到应用程序几乎完成后，非技术经理才能获得任何客户反馈。一年构建一个应用程序只是为了发布它，没有人喜欢它。

如果您可以依靠告诉人们“让它工作”，生活会变得更加简单。当您了解并促使人们坚持正确的流程时，您将消除许多问题。您可能会要求苛刻的实际期限。任何傻瓜都会提出不切实际的要求，并冒失去才能的风险。

我认为我们技术团队中的大多数人都知道谁会动摇，谁会动弹。除非您有大量的营业额，否则奶油会升到顶部，并且自重会下降。笨拙的开发人员总是会遇到麻烦-他们忘了在签入代码之前先测试他们的代码，以免生成中断，他们总是在找不着事情的时候找借口。

我认为他们不知道，如果有人是一个很好的程序设计师，beucase他们没有能力做到这样。他们检查某人是否是一个好的开发人员。编程是开发活动，但是开发还有许多其他活动。因此，他们会检查您是否准时，估计是否正确，在错误跟踪系统中所做的事情是否存在很多缺陷，您的软技能，承诺，沟通等。

一些专家有时忘记并感到不高兴的是，我们的工作不仅是编程，还有许多其他事情要做也很重要。虽然您的经理不会看您的代码看起来如何（因为它对他来说完全不重要），但他会检查您是否是团队合作者，负责任，有礼貌并总体上做得高质量。

有时我认为代码被高估了。

我认为很少有人（更不用说经理）对开发者的优先次序没有很好的总体了解。每个人都认为自己是顶尖的开发人员，唯一不知道谁是不良开发人员的人就是那些不良开发人员。无论如何，如果您要四处走走，并请某人对与他们一起工作的开发人员进行排名，我相信对于大多数人来说，这将是一件容易的事。因此，确定谁的表现非常好，谁的表现中等或差等并没有魔力。开发人员和管理人员不同意的唯一陷阱是那些销售人员的类型，大声的人听起来像他们知道自己在说什么关于，但实际上不是。大多数经理都被他们迷住了，但开发商却没有。

之后，是您的经理的偏见决定了您的排名。在某些情况下，编码是一项入门级的任务，因此，尽管您可能会擅长编码，但它并不能使您获得所需的晋升。而其他人则认为设计或体系结构方面最为重要。其他人则认为需求定义和收集（即业务分析）是最重要的。如果您想知道什么对您的经理很重要，而您却没有获得最高绩效者的排名，请问他们该怎么做才能获得最高绩效者的排名？您还将在答案中了解什么对他们也很重要，然后由您确定自己在那些重要领域中表现出色。