4 ms·

As I remember from an HR course at business school, studies have shown that experience is one of the worst indicators for job performance (when hiring someone;

As I remember from an HR course at business school, studies have shown that experience is one of the worst indicators for job performance (when hiring someone; all else being equal).

daveguy 8y ago
I'd have to see that study. It seems to me that experience gives you a lot of information about what is not as important that comes in handy even when you are "winging it" with something related. Also, "experience is one of the worst indicators for job performance...all else being equal" could mean a lot of things: 1) truly everything else being equal i.e. the person with less experience will do better. (surely that is not the case) 2) Of everything, considered equally, experience is the least indicative of performance compared to education, creative thinking, etc. Can you link those studies and clarify what is meant by "worst indicators"? Also, what job was that in the evaluated job performance? I know it's definitely not true for trade skills like woodworking.
- trendia 8y ago
  > In programming specifically, many studies have shown order of magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of the programmers. The original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years' experience and found that the ratio of intitial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer's amount of experience and code quality or productivity. (Code Complete, page 548) https://blog.codinghorror.com/skill-disparities-in-programming/ https://blog.codinghorror.com/skill-disparities-in-programmi...
  - wallacoloo 8y ago
    From what I can tell of the quote, it looks to be just the ability of an engineer to successfully code a new program? Does it touch on any of the other roles of a computer programmer, such as the ability to break a large task into smaller, incremental deliverables, arrange those deliverables in a way that allows parallelism, communicating with the rest of the team to actually make use of this parallelism, and before doing any of this actually verifying that the thing you’re planning to implement is really what the customer needs? And of course, such work is usually done within an existing system that you have to navigate and modify in a way that remains maintainable (for example, writing the right types of tests, and creating the appropriate types of abstractions). I would be stunned if one’s ability along those axes plateaus within just a couple years of experience. I guess, I’m just skeptical of this because I recently switched jobs from a place where nobody seemed to know what was happening to one where everything seems to be very well-polished. At both places, people generally are similar in their ability to write code that does a specific thing, but there’s a night/day difference in how they do these other things. And I’m hesitant to say that it’s because they just fundamentally aren’t good at those things, because that can’t explain how I was also miserable at those other areas but seem to be learning how to do them now that I’m in the right environment. In other words, I feel like my ability to meaningfully contribute to an organization as a computer programmer is increasing with experience, and I can see quite clearly that the people with more seniority at my present job are generally capable of more effectively navigating the problem space than are my coworkers fresh out of college.
deleted 8y ago
[deleted]
im3w1l 8y ago
"all else being equal" isn't possible. Normally it's a convenient illusion but here it leads us astray. You need to carefully think about what you are controlling for and how and what that will mean. As an example do you control for total number of x-size projects completed, or do you control for x-size projects completed per time in the career? It should be clear that you cannot keep them both equal, you have to choose one or the other (or neither I suppose).

As I remember from an HR course at business school, studies have shown that experience is one of the worst indicators for job performance (when hiring someone; all else being equal).

daveguy 8y ago

I'd have to see that study. It seems to me that experience gives you a lot of information about what is not as important that comes in handy even when you are "winging it" with something related. Also, "experience is one of the worst indicators for job performance...all else being equal" could mean a lot of things: 1) truly everything else being equal i.e. the person with less experience will do better. (surely that is not the case) 2) Of everything, considered equally, experience is the least indicative of performance compared to education, creative thinking, etc. Can you link those studies and clarify what is meant by "worst indicators"? Also, what job was that in the evaluated job performance? I know it's definitely not true for trade skills like woodworking.

trendia 8y ago
> In programming specifically, many studies have shown order of magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of the programmers. The original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years' experience and found that the ratio of intitial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer's amount of experience and code quality or productivity. (Code Complete, page 548) https://blog.codinghorror.com/skill-disparities-in-programming/ https://blog.codinghorror.com/skill-disparities-in-programmi...
- wallacoloo 8y ago
  From what I can tell of the quote, it looks to be just the ability of an engineer to successfully code a new program? Does it touch on any of the other roles of a computer programmer, such as the ability to break a large task into smaller, incremental deliverables, arrange those deliverables in a way that allows parallelism, communicating with the rest of the team to actually make use of this parallelism, and before doing any of this actually verifying that the thing you’re planning to implement is really what the customer needs? And of course, such work is usually done within an existing system that you have to navigate and modify in a way that remains maintainable (for example, writing the right types of tests, and creating the appropriate types of abstractions). I would be stunned if one’s ability along those axes plateaus within just a couple years of experience. I guess, I’m just skeptical of this because I recently switched jobs from a place where nobody seemed to know what was happening to one where everything seems to be very well-polished. At both places, people generally are similar in their ability to write code that does a specific thing, but there’s a night/day difference in how they do these other things. And I’m hesitant to say that it’s because they just fundamentally aren’t good at those things, because that can’t explain how I was also miserable at those other areas but seem to be learning how to do them now that I’m in the right environment. In other words, I feel like my ability to meaningfully contribute to an organization as a computer programmer is increasing with experience, and I can see quite clearly that the people with more seniority at my present job are generally capable of more effectively navigating the problem space than are my coworkers fresh out of college.

deleted 8y ago

[deleted]

im3w1l 8y ago

"all else being equal" isn't possible. Normally it's a convenient illusion but here it leads us astray. You need to carefully think about what you are controlling for and how and what that will mean. As an example do you control for total number of x-size projects completed, or do you control for x-size projects completed per time in the career? It should be clear that you cannot keep them both equal, you have to choose one or the other (or neither I suppose).