# Traveling Companions
-## Famous Coders
+## Famous programmers
Throughout computing there have been folks who have demonstrated amazing coding abilities. They exist the pantheon of great computer programmers: Ada Lovelace (the first computer programmer), Dennis Ritchie (creator of the C programming language), Rear Admiral Grace Murray Hopper (creator of COBOL and credited with finding the first documented computer "bug"), and so on. We also have developers in our own communities that have a certain celebrity status, whether they're the folks who wrote the language we currently use, the folks who maintain the operating system we use, or someone who rose to prominence in our chosen community. It can be intimidating when we compare ourselves with these luminaries. After all, whatever we're currently working on might not measure up to whatever they have done. Worse, we may be working on something similar and feel like whatever we're working on will never measure up to what these folks have accomplished. We may even be friends with programmers who seem to figure out things much quicker and cleaner than we can and marvel at how they seem to have this body of knowledge at their fingertips that we can't possibly understand.
## Measuring programmer output
-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.
+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 programmers 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.
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).
## Traveling Companions
-There are times when it is useful to compare ourselves with other coders. Sometimes we can learn about new technologies or new methodologies by looking at the work of others. But it's easy to fall into the trap of thinking that because we're not at the level of other coders that we're somehow inferior to them. Rather than looking at other coders as competition we should look at them as companions. We're all in this profession working to make our respective projects better. With Open Source / Free Software we have a unique opportunity to see how other folks do their work in public. We can learn from the code of others much in the same way that scientists can look at the papers of other scientists to see what worked (and can improve the validity of the paper with replication and repetition). No coder is completely isolated from the work of others. Rare is the programmer that coded their own environment from scratch without the work of others to help their own coding efforts. We all learn from each other. But rather than be intimidated by the work of others we can instead take it apart and learn from it. And if we're lucky we can take the opportunity to ask them how the code works and why they chose to write the code in that way.
+There are times when it is useful to compare ourselves with other programmers. Sometimes we can learn about new technologies or new methodologies by looking at the work of others. But it's easy to fall into the trap of thinking that because we're not at the level of other programmers that we're somehow inferior to them. Rather than looking at other programmers as competition we should look at them as companions. We're all in this profession working to make our respective projects better. With Open Source / Free Software we have a unique opportunity to see how other folks do their work in public. We can learn from the code of others much in the same way that scientists can look at the papers of other scientists to see what worked (and can improve the validity of the paper with replication and repetition). No coder is completely isolated from the work of others. Rare is the programmer that coded their own environment from scratch without the work of others to help their own coding efforts. We all learn from each other. But rather than be intimidated by the work of others we can instead take it apart and learn from it. And if we're lucky we can take the opportunity to ask them how the code works and why they chose to write the code in that way.
### FIXME
-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's value in asking questions of our fellow programmers. We tend to overlook asking questions fearing that 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 an idea or a particular piece of code. There are programmers out there who don't mind answering questions, and my hope is that you find them. Granted there are some programmers who are very busy and might not have the time or inclination to answer our questions. 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. They may even be grateful for the question because it gives them insights into a perspective they might not otherwise have. When we ask questions we initiate a sharing of ideas in both directions.
-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.
+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 manifests 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 frustrating when folks won't answer our questions directly. 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. Perhaps what we're asking isn't the best way to do something and pausing to listen may help us better understand why they suggested what they did.
-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.
+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.
-If we look at other coders 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 if someone has many more years of experience than you they are your peer. You have knowledge and experience they don't have, and they have experience and knowledge you don't have. If we strip away the barriers of ranking and meritocracy we can better engage with each other and learn from each other.
+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.
-The journey to becoming a better programmer is long and hard. We need the best companions we can find to help us along the way. And not just the technically-skilled companions but the companions that we can talk to when the day is done and commiserate about our struggles together.
+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.
+
+The journey to becoming a better programmer is long and hard. We need the best companions we can find to help us along the way. We need more than just the technically-skilled companions; we also need companions we can talk to when the day is done. We need companions we can sit with around the proverbial campfire where we can laugh and commiserate about our struggles together.
projects / themediocreprogrammer.git / commitdiff