-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 by 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 review what other programmers are committing. Since we can measure the number of commits, we can use this measurement 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 review the quality of their commits to a project. It can be daunting to see 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).
+
+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 the amount of time thinking about the problem just by looking at a commit. 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 if this commit is the result of one afternoon of work or many days of work (unless they commit more often). We might even find out that this person is acting as the focal point of an organization and is folding the work of multiple folks into their commits.
+
+Measuring ourselves on the quantity of others output is easy and seductive but it isn't useful for figuring out how to improve ourselves in relation to the other programmer (other than "generate more commits"). That way of thinking can lead us to believing that we're not spending enough time doing "actual programming" and lead to overwork, stress, and burn-out.
+
+## Traveling Companions
+
+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 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 Free and Open Source 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. (It's a rare programmer that has coded their entire programming environment from scratch without the work of others.) 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. 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's value in asking questions of our fellow programmers. We tend to overlook asking questions for fear 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 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. 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.