A few weeks ago, I was assigned to evaluate all our programmers. I'm very uncomfortable with this since I was the one who taught everyone the shop's programming language (they all got out of college not knowing the language and as luck would have it, I'm very proficient with it.). On the evaluation, I was very biased on their performance (perfect scores).
几个星期前,我被分配来评估我们所有的程序员。我对此感到非常不舒服,因为我是那个教过每个人的商店编程语言的人(他们都是大学毕业后不知道语言而且运气好,我非常精通它。)。在评估中,我对他们的表现(完美分数)非常偏颇。
I'm glad that our programming shop doesn't require an average performance level but I heard horror stories of shops which do require an average level.
我很高兴我们的编程商店不需要平均性能水平,但我听到商店的恐怖故事需要平均水平。
My question are as follows:
我的问题如下:
- As a programmer, what evaluation questions would you like to see?
- As a manager, what evaluation questions would you like to see?
- As the evaluator, how can you prevent bias in your evaluation?
- I would love to remove the evaluation test. Is there any advantages to having an evaluation test? Any disadvantage?
作为程序员,您希望看到哪些评估问题?
作为经理,您希望看到哪些评估问题?
作为评估者,您如何防止评估中的偏见?
我很乐意删除评估测试。评估测试有什么好处吗?任何劣势?
4 个解决方案
#1
11
Gets things done is really all you need to evaluate a developer. After that you look at the quality that the developer generates. Do they write unit tests and believe in testing and being responsible for the code they generate? Do they take initiative to fix bugs without being assigned them? Are they passionate about coding? Are they always constantly learning, trying to find better ways to accomplish a task or make a process better? These questions are pretty much how I judge developers directly under me. If they are not directly under you and you are not a direct report for them, then you really shouldn't be evaluating them. If you are assigned in evaluating those programmers that aren't under you, then you need to be proactive to answer the above questions about them, which can be hard.
获取完成的东西实际上是评估开发人员所需要的。之后,您将了解开发人员生成的质量。他们是否编写单元测试并相信测试并负责他们生成的代码?他们是否主动修复错误而不分配错误?他们对编码充满热情吗?他们是否总是不断学习,试图找到更好的方法来完成任务或使流程更好?这些问题几乎就是我如何直接判断开发人员。如果他们不是直接在你之下并且你不是他们的直接报告,那么你真的不应该评估它们。如果您被指派评估那些不在您之下的程序员,那么您需要主动回答上述有关他们的问题,这可能很难。
You can't remove the evaluation test. I know it can become tedious sometimes, but I actually enjoy doing it and it's invaluable for the developer you are evaluating. You need to be a manager that cares about how your developers do. You are a direct reflection on them and as they are of you. One question I always leave up to the developer is for them to evaluate me. The evaluation needs to be a two lane road.
您无法删除评估测试。我知道它有时会变得单调乏味,但我真的很喜欢这样做,这对你正在评估的开发人员来说非常宝贵。您需要成为一名关心您的开发人员如何做的经理。你直接反思他们,就像他们一样。我总是留给开发人员的一个问题是让他们评估我。评估需要是一条双线道路。
I have to also evaluate off a cookie cutter list of questions, which I do, but I always add the above and try to make the evaluation fun and a learning exercise during the time I have the developer one on one, it is all about the developer you are reviewing.
我还要评估一个cookie切割器的问题列表,我这样做,但我总是添加上面的内容并尝试让评估变得有趣并且在我让开发人员一对一的时候进行学习练习,这是关于您正在审核的开发人员。
#2
2
I would first consider not necessarily the number of lines of code, but the value of the code that the person adds as reflective of course to what they are assigned to do. Someone told to maintain code verses building a new app is very different. Also consider how the person uses new techniques to make the code relevant and updated? How maintainable is the code the person creates? Do they do things in a manner that is logical and understandable to the rest of the team? Does their coding improve the app or just wreck it? Last and not least does their coding improve over time?
我首先要考虑的不一定是代码行的数量,而是代表该代码的值,以反映当前它们分配给它们的内容。有人告诉维护代码版本构建一个新的应用程序是非常不同的。还要考虑这个人如何使用新技术来使代码相关和更新?这个人创造的代码有多可维护?他们是否以对团队其他成员合乎逻辑且易于理解的方式做事?他们的编码是改进应用程序还是只是破坏它?最后,并非最不重要的是他们的编码随着时间的推
#3
0
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person. One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding, etc.
如何让每个人都参与进来?与一个人合作的每个人都会对这个人有独特的见解。一个人可能认为某人是懒鬼,而另一个人则认为他们在开始编码之前花了很多时间进行规划等。
#4
0
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person.
如何让每个人都参与进来?与一个人合作的每个人都会对这个人有独特的见解。
That would work if (1) evaluation is conducted with open doors and (2) you've worked with that person on one project or even on the same module. As the person evaluating them, I couldn't judge the programmers who I didn't directly work with.
如果(1)评估是在敞开的大门上进行的,并且(2)您在一个项目上甚至在同一个模块上与该人合作,那将是有效的。作为评估他们的人,我无法判断我没有直接合作的程序员。
One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding
一个人可能认为某人是懒鬼,而另一个人则认为他们在开始编码之前花了很多时间进行规划
Unfortunately, this is debatable. Someone who looks like a slacker might be in deep thoughts, or maybe not. And is someone who spend a long time planning, necessarily a bad programmer?
不幸的是,这是值得商榷的。看起来像个懒鬼的人可能会深思熟虑,或者可能不是。有人花了很长时间计划,必然是一个糟糕的程序员吗?
I believe a good evaluation question would be able to answer this.
我相信一个好的评估问题就能解决这个问题。
#1
11
Gets things done is really all you need to evaluate a developer. After that you look at the quality that the developer generates. Do they write unit tests and believe in testing and being responsible for the code they generate? Do they take initiative to fix bugs without being assigned them? Are they passionate about coding? Are they always constantly learning, trying to find better ways to accomplish a task or make a process better? These questions are pretty much how I judge developers directly under me. If they are not directly under you and you are not a direct report for them, then you really shouldn't be evaluating them. If you are assigned in evaluating those programmers that aren't under you, then you need to be proactive to answer the above questions about them, which can be hard.
获取完成的东西实际上是评估开发人员所需要的。之后,您将了解开发人员生成的质量。他们是否编写单元测试并相信测试并负责他们生成的代码?他们是否主动修复错误而不分配错误?他们对编码充满热情吗?他们是否总是不断学习,试图找到更好的方法来完成任务或使流程更好?这些问题几乎就是我如何直接判断开发人员。如果他们不是直接在你之下并且你不是他们的直接报告,那么你真的不应该评估它们。如果您被指派评估那些不在您之下的程序员,那么您需要主动回答上述有关他们的问题,这可能很难。
You can't remove the evaluation test. I know it can become tedious sometimes, but I actually enjoy doing it and it's invaluable for the developer you are evaluating. You need to be a manager that cares about how your developers do. You are a direct reflection on them and as they are of you. One question I always leave up to the developer is for them to evaluate me. The evaluation needs to be a two lane road.
您无法删除评估测试。我知道它有时会变得单调乏味,但我真的很喜欢这样做,这对你正在评估的开发人员来说非常宝贵。您需要成为一名关心您的开发人员如何做的经理。你直接反思他们,就像他们一样。我总是留给开发人员的一个问题是让他们评估我。评估需要是一条双线道路。
I have to also evaluate off a cookie cutter list of questions, which I do, but I always add the above and try to make the evaluation fun and a learning exercise during the time I have the developer one on one, it is all about the developer you are reviewing.
我还要评估一个cookie切割器的问题列表,我这样做,但我总是添加上面的内容并尝试让评估变得有趣并且在我让开发人员一对一的时候进行学习练习,这是关于您正在审核的开发人员。
#2
2
I would first consider not necessarily the number of lines of code, but the value of the code that the person adds as reflective of course to what they are assigned to do. Someone told to maintain code verses building a new app is very different. Also consider how the person uses new techniques to make the code relevant and updated? How maintainable is the code the person creates? Do they do things in a manner that is logical and understandable to the rest of the team? Does their coding improve the app or just wreck it? Last and not least does their coding improve over time?
我首先要考虑的不一定是代码行的数量,而是代表该代码的值,以反映当前它们分配给它们的内容。有人告诉维护代码版本构建一个新的应用程序是非常不同的。还要考虑这个人如何使用新技术来使代码相关和更新?这个人创造的代码有多可维护?他们是否以对团队其他成员合乎逻辑且易于理解的方式做事?他们的编码是改进应用程序还是只是破坏它?最后,并非最不重要的是他们的编码随着时间的推
#3
0
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person. One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding, etc.
如何让每个人都参与进来?与一个人合作的每个人都会对这个人有独特的见解。一个人可能认为某人是懒鬼,而另一个人则认为他们在开始编码之前花了很多时间进行规划等。
#4
0
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person.
如何让每个人都参与进来?与一个人合作的每个人都会对这个人有独特的见解。
That would work if (1) evaluation is conducted with open doors and (2) you've worked with that person on one project or even on the same module. As the person evaluating them, I couldn't judge the programmers who I didn't directly work with.
如果(1)评估是在敞开的大门上进行的,并且(2)您在一个项目上甚至在同一个模块上与该人合作,那将是有效的。作为评估他们的人,我无法判断我没有直接合作的程序员。
One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding
一个人可能认为某人是懒鬼,而另一个人则认为他们在开始编码之前花了很多时间进行规划
Unfortunately, this is debatable. Someone who looks like a slacker might be in deep thoughts, or maybe not. And is someone who spend a long time planning, necessarily a bad programmer?
不幸的是,这是值得商榷的。看起来像个懒鬼的人可能会深思熟虑,或者可能不是。有人花了很长时间计划,必然是一个糟糕的程序员吗?
I believe a good evaluation question would be able to answer this.
我相信一个好的评估问题就能解决这个问题。