Cleaning up the wording under ranking

diff --git a/chapter02.md b/chapter02.md
index 656192ff5144d2166a80a82889a346eca62ea8df..7bfbe9e242c1b6232b4222421b808978a35e90c4 100644 (file)
--- a/chapter02.md
+++ b/chapter02.md
@@ -24,7 +24,10 @@ There's nothing wrong with reading a post-mortem about a project - we can learn
 
 ## Ranking programmers
 
-There are many metrics for which folks rank various programmers. You've likely seen these metrics manifest themselves in competition sites, commits to projects, productivity, turn-around of code, and good ol' gut feelings. We do it to ourselves and others. We compare our work against 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. Or I can compare myself against folks who were mentored by programmers whose names are legendary in the field. Unfortunately I will likely find gaps between my knowledge and their knowledge. Comparisons like this tend to be unhelpful and lead us into punishing ourselves for not being the other person. We look at our projects and our history and find that we're not the other person, nor could we ever be the other person.
+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.
+
+
+#### 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.