There are many metrics which folks use to rank programmers. You've likely seen these metrics manifest themselves in different ways: competition sites, numbers of commits to projects, productivity measurements, time to turn-around code, and good ol' fashioned gut feelings. We do it to ourselves and others. We compare our work against the work of our peers and folks that we admire. But that can lead us to make comparisons that aren't objective or based on all of the data. I can compare myself against folks who do low-level programming and find that I don't measure up in that realm. Never mind that I haven't done a whole lot of low-level programming; the comparison is valid. Or I can compare myself against folks who were mentored by programmers whose names are legendary in the field. I will find gaps between my knowledge and their knowledge, because I didn't have access to those mentors (or worse: I didn't take advantage of the mentors that I did have access to. Whoops!). Comparisons like these are unhelpful and lead us into punishing ourselves for not being someone else. We look at our projects and our history and conclude that we're not that other person, nor could we ever be that other person.
+The major problem with ranking programmers (or really anything for that matter) is that ranking systems are based on one set of criteria. There is no real standard for ranking programmers. Sites that rank programmers based on numbers of problems solved or difficulty of problems solved have only determined that there are a set of programmers who really enjoy solving these sorts of problems. They've also determined these sets of programmers will spend the time and effort to solve these problems and will be competitive in solving these problems. It tells us little about the programmer's abilities outside of that domain.
-#### FIXME
-
-The major problem with ranking programmers (or really anything for that matter) is that ranking systems are based on one set of criteria. There is no real standard for ranking programmers. Sites that rank programmers based on the number of problems they've solved have only determined that there are a set of programmers who really enjoy solving these sorts of problems and will spend the time to do so. It tells us little about the programmer's abilities. Or we can look at how many lines of code a programmer used in order to solve a problem, or how "clean" the solution is (clean being another nebulous term). We can look at the Big O notation of the code that a programmer generates or how well the code adapts to various circumstances. Very little of this tells us anything about the programmer themselves. What it does tell us is that the programmer has had experiences that lead them to that particular solution. It tells us that the programmer has seen these sorts of problems before and has thought deeply about how to make them better. We learn that the programmer has devoted time and energy to practice these sorts of problems. What it doesn't tell us is an overall measurement of the programmer's skills or abilities. It's similar to the apocryphal tale of a brilliant professor. This professor was an absolute genius in his field and was one of the go-to people for answers about his subject. But despite his brilliance he was unable to understand how to change a tire on a car. Does that mean the professor was not as brilliant as folks claimed him to be? Hardly. It just meant that the professor had spent more time in his profession than he had changing tires. The same is true for programmers. If a programmer spends most of their time solving a particular set of problems they will eventually become skilled at those sorts of problems. But if they struggle with a different sort of problem it doesn't discount their overall skills; it just points out an area that they might want to work on.
+We can find other metrics to rank programmers. One classic metric is reviewing how many lines of code a programmer used in order to solve a problem (this is sometimes referred to as "code golf", where the fewer number of lines of code the better the solution). Or we can see how "clean" the solution is (clean being another nebulous term). We can look at the Big O notation of the code that a programmer generates or how well the code adapts to various circumstances. We can count the number of cycles a particular piece of code takes in order to run and benchmark it against similar code. Very little of this tells us anything about the programmer themselves. What it does tell us is that the programmer has experience that lead them to that particular solution. It tells us that the programmer has seen these sorts of problems before and cared deeply enough about how to make a better solution. We learn that the programmer devoted time and energy to practice these sorts of problems. What it doesn't show us is an overall measurement of the programmer's skills or abilities. It's similar to the apocryphal tale of a brilliant professor. This professor was an absolute genius in his field and was one of the go-to people for answers about his subject. But despite his brilliance he was unable to understand how to change a tire on a car. Does that mean the professor was not as brilliant as folks claimed him to be? Hardly. It means the professor spent more time thinking about his profession than he spent thinking about changing tires. The same is true for programmers. If a programmer spends most of their time solving a particular set of problems they will eventually become skilled at those sorts of problems. But if they struggle with a different sort of problem it doesn't discount their overall skills; it just points out areas they might want to work on.
## Measuring programmer output
-There's also a tendency to measure programmer productivity via how many commits the programmer can make to a project. In an era of social coding sites like Github / Gitlab we can easily look at what other coders are committing and feel that we're somehow not measuring up. And unlike certain measurements of old (lines of code, which measures how many lines of code a programmer adds to a program) we can see the quality of their commits to a project. It can be daunting seeing a lot of quality work done by our peers.
+There's also a tendency to measure programmer productivity via how many contributions the programmer can make to a project.Under certain version control systems these are called "commits". They list out a set of changes that the programmer wishes to make to the code. In an era of social coding sites like Github and Gitlab we can easily look at what other coders are committing. Since we can measure the number of commits we can use this to feel that we're not generating the same number and frequency of commits as other programmers. And unlike measurements of old (lines of code in particular, which measures how many lines of code a programmer adds to a program) we can see the quality of their commits to a project. It can be daunting seeing a lot of quality work done by our peers. It can also be source of frustration and feelings of inadequacy. "Why can't I be as productive or contribute as this other person?" we ask ourselves.
-This too can be a source of frustration and feelings of inadequacy. "Why can't I be as productive or useful as this other person" we might say to ourselves? Or worse, these metrics may be used by others to judge productivity and we may find ourselves being criticized for our output (or lack thereof).
+Even more frustrating is when others use these metrics to judge productivity and code contributions. We we may find ourselves being criticized for our output (or lack thereof).
+
+#### FIXME
Unfortunately commits and lines of code are the most visible measurement of coding productivity, but they don't show much about the actual practice of programming. We can't measure to any degree of accuracy the amount of time thinking about the problem. We don't see the mounds of reference material the programmer used in order to figure out a solution. And we certainly don't know just from looking at commits if this is the result of one person's afternoon of work or many days of work (unless they commit more often). We might find that this person is committing the work of multiple folks in their organization with the committer as the focal point for the other contributions.
There's value in being able to ask questions of our fellow coders. We tend to overlook asking questions for feeling like we're going to ask something obvious or ask a question that will make us feel inadequate for asking. Asking questions is very useful when we don't understand what is going on with a particular piece of code. There are coders out there tho don't mind answering questions, and my hope is that you find them. Granted there are some who are very busy; who might not have the time to answer our questions in a manner that is useful to us. But if we are truly stuck and have exhausted all other avenues perhaps we can ask questions of them that don't require much of their time and effort and we can both be happy for the interaction.
-There is an art to asking questions and it can be frustrating when folks don't answer our questions, or come back with other questions / suggestions that are less than helpful. This can manifest itself in exchanges where person A asks: "I'd like to know how to do X" and persons B and C respond "I would do Y instead". It's easy to be angry at those folks and think "they're not answering my question!". It's also easy to get embroiled in exchanges with folks about the merits of doing Y where clearly I had inteneded to do X all along, thank you very much. But if we re-frame the experience as "this person is trying to help me; perhaps there is something in this recommendation that might be helpful." then we can have a better conversation.
+There is an art to asking questions and it can be frustrating when folks don't answer our questions, or come back with other questions / suggestions that are less than helpful. This can manifest itself in exchanges where person A asks: "I'd like to know how to do X" and persons B and C respond "I would do Y instead". It's easy to be angry at those folks and think "they're not answering my question!". It's also easy to get embroiled in exchanges with folks about the merits of doing Y where clearly I had intended to do X all along, thank you very much. But if we re-frame the experience as "this person is trying to help me; perhaps there is something in this recommendation that might be helpful." then we can have a better conversation.
Of course there are folks who don't respond with your best interests at heart and are only interested in pushing their own world-view upon you. And it can take a lot of energy to engage with these folks to tell them "no, I really, really intended to learn more about X". I don't have good answers for how to handle these folks outside of thanking them for their time and finding someone else to ask. But this is also part of our growth process.
projects / themediocreprogrammer.git / commitdiff