几周前，我被指派评估我们所有的程序员。我对此感到非常不舒服，因为我是那个教每个人商店的编程语言的人（他们都大学毕业时不知道这种语言，幸运的是，我非常精通它。）。在评估中，我对他们的表现（满分）非常有偏见。
我很高兴我们的编程商店不需要平均性能水平，但我听说过需要平均性能水平的商店的恐怖故事。
我的问题如下：
【问题讨论】：
标签： evaluation
真正完成任务是评估开发人员所需的全部内容。之后，您查看开发人员生成的质量。他们是否编写单元测试并相信测试并对他们生成的代码负责？他们是否主动修复错误而不被分配？他们对编码充满热情吗？他们是否总是不断地学习，试图找到更好的方法来完成任务或改进流程？这些问题几乎就是我如何判断我直属的开发人员的方式。如果他们不直接隶属于您，并且您不是他们的直接下属，那么您真的不应该评估他们。如果你被指派评估那些不在你手下的程序员，那么你需要主动回答上述关于他们的问题，这可能很难。
您无法移除评估测试。我知道它有时会变得乏味，但我真的很喜欢这样做，这对于您正在评估的开发人员来说是无价的。你需要成为一个关心你的开发人员如何做的经理。你是他们的直接反映，因为他们是你。我总是留给开发人员的一个问题是让他们评估我。评估需要是一条两车道的道路。
我还必须评估一个千篇一律的问题列表，我会这样做，但我总是添加上面的内容，并在我与开发人员一对一的时候尝试让评估变得有趣和学习练习，它是关于您正在审查的开发者的所有信息。
【讨论】：
我首先会考虑的不一定是代码行数，而是该人添加的代码的价值当然反映了他们被分配要做的事情。有人告诉维护代码与构建新应用程序是非常不同的。还要考虑人们如何使用新技术使代码相关和更新？该人创建的代码的可维护性如何？他们做事的方式是否符合团队其他成员的逻辑和理解？他们的编码是改进了应用程序还是破坏了它？最后同样重要的是，他们的编码会随着时间的推移而改进吗？
【讨论】：
如何获得每个人的意见？与一个人一起工作的每个人都会对那个人有独特的洞察力。一个人可能会认为某人是个懒鬼，而另一个人则认为他们在开始编码之前花费了大量时间进行计划，等等。
【讨论】：
如何获得每个人的意见？与一个人一起工作的每个人都会对那个人有独特的洞察力。
如果 (1) 评估是在敞开大门的情况下进行的，并且 (2) 您曾与该人合作过一个项目，甚至是同一个模块，这将是可行的。作为评估他们的人，我无法评判那些没有直接合作过的程序员。
一个人可能认为某人是个懒鬼，而另一个人则认为他们在开始编码之前花了很多时间进行计划
不幸的是，这是有争议的。看起来像个懒鬼的人可能陷入了沉思，也可能没有。一个花很长时间计划的人，一定是一个糟糕的程序员吗？
我相信一个好的评估问题可以回答这个问题。
【讨论】：