Filling out the ranking programmers section

diff --git a/chapter02.md b/chapter02.md
index 1e9ded9e8a0ea90639ee7918740bc64783e85fa9..ea5f8385fe29da3ab21592297ad98b1ffee14fca 100644 (file)
--- a/chapter02.md
+++ b/chapter02.md
@@ -23,3 +23,5 @@ 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.
+
+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.