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).
-#### FIXME
-
-Unfortunately 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 to any degree of accuracy the amount of time thinking about the problem. 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 just from looking at commits if this is the result of one person's afternoon of work or many days of work (unless they commit more often). We might find that this person is committing the work of multiple folks in their organization with the committer as the focal point for the other contributions.
+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 that this person is acting as the focal point of their 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 line of thinking can lea us to thinking that we're not spending enough time doing "actual programming" and lead to overwork, stress, and burn-out.
+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 can be 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 very 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 be able to look at 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 (by replication and repetition). No coder is completely isolated from the work of others. Rare is the programmer that achieved everything they achieved without looking at 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 have the opportunity to ask others about how the code works and why they chose to do it that way.
+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.
+
+### 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.
projects / themediocreprogrammer.git / commitdiff