## Backstage vs. performance
-One of the best pieces of advice I received about comparing ourselves to others is realizing that you're comparing your backstage to their performance. The metaphor draws from the theater, where performers know every thing that isn't right about their own theater-group's performance and unfairly compare it with another person's finished performance. How this relates is that we compare all of the things that we know (the long hours of unproductive coding, the struggles with learning, and so forth) with the finished product of someone else. We don't see their struggle in getting things to work, or their countless hours making crappy prototypes and unfinished projects before making the thing we admire.
+One of the best pieces of advice I received about comparing ourselves to others is realizing that you're comparing your backstage to their performance. The metaphor draws from the theater, where performers know every thing that isn't right about their own theater-group's performance and unfairly compare it with another person's finished performance. How this relates is that we compare all of the things that we know (the long hours of unproductive coding, the struggles with learning, and so forth) with the finished product of someone else. We don't see their struggle in getting things to work, or their countless hours making crappy prototypes and unfinished projects before making the thing we admire. Allow yourself to have a messy back-stage and do plenty of rehearsals and understand that it takes effort and practice to put on a good performance.
## The lure of the post-mortem
-There's a tradition in some programming projects (especially in game development projects where there is a clear end when the product ships) of doing a post-mortem on the project. What the post-mortem does is allow the developers of a project to state what went right and what didn't go right. The better ones tend to be frank accounts of the successes and failures of a project.
+There's a tradition in some programming projects (especially in game development projects where there is a clear end to the project when the product ships) of doing a post-mortem on the project. What the post-mortem does is allow the developers of a project to state what went right and what didn't go right. The better ones tend to be frank accounts of the successes and failures of a project.
The post-mortem can be a fascinating look into the development of a project. I've found myself reading a lot of these looking for insights into the development process.
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.
-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.
+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 the problem to think hard 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
Pulling our ego out of the question allows us to be more open to the answers we receive. When people don't understand our question it becomes easy to take it personally and re-frame it as "they're not understanding me" or "they're not listening to me". Pulling ourselves out of the question allows us to take the answer at it's merits and gives us the ability to change the question as needed.
-Of course there are folks who won't respond with your best interests at heart and are only interested in imposing their own world-view upon you. Instead of answering your question they question why you're doing that at all and should be using their methodology instead. 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 wish I had good answers for how to handle these folks. There are plenty of them that feel that whatever they're doing is the only right path and those that stray from their chosen path are anathema to their world. My best suggestion is to thank them for their time and find someone else to ask. Perhaps they may be useful in the future when you have questions about whatever is part of their agenda, but for now be as kind as possible and wish them well on their journey. Technology spaces have a lot of folks who have been working with computers for a long time and form very strong opinions about their tools and technologies. My hope is that you can find the ones that are also kind and willing to share what they know and not badger you their strongly held beliefs. Over time you too will form your own beliefs on what works and what doesn't work and pass that knowledge on to others. Recognizing folks who are there to help educate and those who are there to proselytize is part of our growth process.
+Of course there are folks who won't respond with your best interests at heart and are only interested in imposing their own world-view upon you. Instead of answering your question they question why you're doing that at all and should be using their methodology instead. 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 wish I had good answers for how to handle these folks. There are plenty of them that feel that whatever they're doing is the only right path and those that stray from their chosen path are anathema to their world. My best suggestion is to thank them for their time and find someone else to ask. Perhaps they may be useful in the future when you have questions about whatever is part of their agenda, but for now be as kind as possible and wish them well on their journey. Technology spaces have a lot of folks who have been working with computers for a long time and form very strong opinions about their tools and technologies. My hope is that you can find the ones that are also kind and willing to share what they know and not badger you with their strongly held beliefs. Over time you too will form your own beliefs on what works and what doesn't work and pass that knowledge on to others. Recognizing folks who are there to help educate and those who are there to proselytize is part of our growth process.
If we look at other programmers as our traveling companions on this journey; as peers in our coding practice, then we can realize that we're all in this together. Even someone with many more years of experience than you is your peer. You have knowledge and experience they won't have, and they have experience and knowledge you don't have. If we strip away the barriers of perceived rank and meritocracy we can better engage with and learn from each other.
projects / themediocreprogrammer.git / commitdiff