There's nothing wrong with reading a post-mortem about a project - we can learn a great deal about how a project is run (or shouldn't be run) and what pitfalls to be aware of if we go down a similar path. But understand that you're reading one account (whether by one person or one team of people). They have the perspective of someone deep in the conflict. You're looking at their recollections of tactics, not the overall strategy brought them to the place.
-#### FIXME
-
## Ranking programmers
There are many metrics which folks use to rank programmers. You've likely seen these metrics manifest themselves in different ways: competition sites, numbers of commits to projects, productivity measurements, time to turn-around code, and good ol' fashioned gut feelings. We do it to ourselves and others. We compare our work against the work of 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; the comparison is valid. Or I can compare myself against folks who were mentored by programmers whose names are legendary in the field. I will find gaps between my knowledge and their knowledge, because I didn't have access to those mentors (or worse: I didn't take advantage of the mentors that I did have access to. Whoops!). Comparisons like these are unhelpful and lead us into punishing ourselves for not being someone else. We look at our projects and our history and conclude that we're not that other person, nor could we ever be that other person.
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 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 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.
projects / themediocreprogrammer.git / commitdiff