3 ms·

You originally asked: > ... actually define in any sort of concrete terms what a great programmer is. And I did. The concrete terms are in measurable aspects

You originally asked: > ... actually define in any sort of concrete terms what a great programmer is. And I did. The concrete terms are in measurable aspects of a person who is (or is expected to be) performing the role of programmer. These characteristics are congruent with both tangible metrics (such as time) as well as empirically observable metrics (such as solving the problem at hand and doing so to the satisfaction of other people involved). Using software engineering terms to identify a person's ability is invalid. Attempting to do so restricts the ability to define, measure, and verify with minimal subjectivity whether or not a person meets the expectations of whatever subjective classification ("great", "bad", "OK", "senior", "rookie") being considered.

andrewstuart 11y ago
Then you have solved recruiting and everyone agrees with you.
- AdieuToLogic 11y ago
  Sighs. You presented a challenge for providing a definition for the subjective categorization of a "great programmer." It was my assumption that you did not have a satisfactory one, based on how you presented this challenge. Perhaps the problem domain which you presented is not immediately recognizable. In defining a concept relating to people, a plausible one will include terms/metrics/observations relevant to people. This implies a continuous domain (as opposed to a discrete one) much like what exists in analog systems. Attempting to apply binary "yes/no" requirements and/or tests when faced with a partially observable universe doesn't work. Which is why AI agents use heuristics such as "confidence factors." And a person with which an organization has little to no history with presents a partially observable universe often limited to their CV. Now, a computer program has to do approximations such as confidence factors because _it_ is a digital entity (assuming a Von Neumann machine[1]). But we, as human beings, are not Von Neumann machines. We are analog. Which implies continuous domain metrics (IOW: a "spectrum"). Hence the fruitless effort of attempting to apply software engineering best practices onto people. However, addressing the problem defined as being "evaluate whether or not this multi-dimensional analog system can be of value to a collaborating set of multi-dimensional analog systems, for some equally nebulous definition of value" may reveal that collecting measurements within the observable outputs of said analog systems has a higher probability of success than one which attempts to apply measurements/practices for an entirely different problem domain. YMMV. 1- https://en.wikipedia.org/wiki/Von_Neumann_architecture https://en.wikipedia.org/wiki/Von_Neumann_architecture

andrewstuart 11y ago

Then you have solved recruiting and everyone agrees with you.

AdieuToLogic 11y ago
Sighs. You presented a challenge for providing a definition for the subjective categorization of a "great programmer." It was my assumption that you did not have a satisfactory one, based on how you presented this challenge. Perhaps the problem domain which you presented is not immediately recognizable. In defining a concept relating to people, a plausible one will include terms/metrics/observations relevant to people. This implies a continuous domain (as opposed to a discrete one) much like what exists in analog systems. Attempting to apply binary "yes/no" requirements and/or tests when faced with a partially observable universe doesn't work. Which is why AI agents use heuristics such as "confidence factors." And a person with which an organization has little to no history with presents a partially observable universe often limited to their CV. Now, a computer program has to do approximations such as confidence factors because _it_ is a digital entity (assuming a Von Neumann machine[1]). But we, as human beings, are not Von Neumann machines. We are analog. Which implies continuous domain metrics (IOW: a "spectrum"). Hence the fruitless effort of attempting to apply software engineering best practices onto people. However, addressing the problem defined as being "evaluate whether or not this multi-dimensional analog system can be of value to a collaborating set of multi-dimensional analog systems, for some equally nebulous definition of value" may reveal that collecting measurements within the observable outputs of said analog systems has a higher probability of success than one which attempts to apply measurements/practices for an entirely different problem domain. YMMV. 1- https://en.wikipedia.org/wiki/Von_Neumann_architecture https://en.wikipedia.org/wiki/Von_Neumann_architecture