# Traveling Companions

## Famous Coders

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.

## 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.

## 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. 

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.

But there's a subtle trap in the post-mortem: they're a recollection of events from a vantage point of a successful (or unsuccessful) project. They're a recollection of someone who has made a thing, and it was successful enough that you are reading about that project's ups and downs. They're written from a perspective where the success of the project is a foregone conclusion (or from a perspective where the project was important enough to document why it was a failure, or why it didn't live up to the expectations of those involved). It can lead you to believe that what you're working on is not as important as the things that other people are working on. But we don't know the importance of our project in real-time. Even the folks in the post-mortem didn't know if their project will work or be successful as they're working on it. Our projects may never see the light of day or it might be something that changes the world. We can't know the value of what we're working on while we're working on it (though we can have a sense of whether or not we _feel_ our work is important or not).

A post-mortem also has the benefit of hindsight. Decisions that were clear and definite at the time might not make much sense when viewed data obtained later in the project's lifespan. There's also selective memory where something might not be remembered with the same clarity, or may be conflated with other events. Statements like "we knew this one thing wouldn't have worked" may have been "we weren't sure if this would work so we tried several things. They all didn't work.". Consider anyone writing about their past as an unreliable narrator. True, they may be the best and most knowledgeable narrator we have, but they are generally not an outside perspective on whatever they were creating. They have their own biases and reasons for the stories they present in a post-mortem. Treat a post-mortem like you would treat an auto-biography of a famous person: a primary source with an agenda to show the subject in the best way possible.

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.


#### FIXME

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 the number of problems they've solved have only determined that there are a set of programmers who really enjoy solving these sorts of problems and will spend the time to do so. It tells us little about the programmer's abilities. Or we can look at how many lines of code a programmer used in order to solve a problem, or 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. Very little of this tells us anything about the programmer themselves. What it does tell us is that the programmer has had experiences that lead them to that particular solution. It tells us that the programmer has seen these sorts of problems before and has thought deeply about how to make them better. We learn that the programmer has devoted time and energy to practice these sorts of problems. What it doesn't tell 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 just meant that the professor had spent more time in his profession than he had 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 an area that they might want to work on.

## Measuring programmer output

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.

This too can be a source of frustration and feelings of inadequacy. "Why can't I be as productive or useful as this other person" we might say to ourselves? Or worse, these metrics may be used by others to judge productivity and we may find ourselves being criticized for our output (or lack thereof).

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.

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.

## 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'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 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 inteneded 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. 

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.

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.

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.