3 ms·
> I challenge ANYBODY to actually define in any sort of concrete terms what a great programmer is. Definition: A great programmer is one who can define/identi
by AdieuToLogic 11y ago
> I challenge ANYBODY to actually define in any sort of concrete terms what a great programmer is.
Definition:
A great programmer is one who can define/identify the problem which needs to be solved as put forth by people who have a vested interest (stakeholders), contributes to or delivers a software solution to said problem definition, within time constraints allowed for by their stakeholders, and does so to the acceptance of the same stakeholders.
Q.E.D.
- andrewstuart 11y agoThat's your opinion. Others will think differently - recruiting is purely a matter of opinion. I tried to define it here: 50 characteristics of a great software developer http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml http://www.supercoders.com.au/blog/50characteristicsofagreat... In software engineering terms, specify the requirements that make a great programmer and if there is science to it then you should also be able to define concrete test cases that tell you if someone meets each requirement. It can't be done, doesn't work in real life.
- vacri 11y agoA definition needs to be qualitative, but it doesn't need to be quantitative. How do you measure "melancholy" or "a thumpin' beat"? > if there is science to it then you should also be able to define concrete test cases This is a misapplication of "science". Science is robust observation, not the algorithm behind something. And there certainly doesn't have to be concrete test cases for something to be "science" - a classic example is case studies and low n studies in medicine. Another is everything we've learned from brain injuries. Science isn't limited to just finding against the null hypothesis.
- AdieuToLogic 11y agoYou 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 agoThen you have solved recruiting and everyone agrees with you.
- AdieuToLogic 11y agoSighs. 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
- sklogic 11y agoSounds like a definition of a manager or an architect, not a programmer.