# Traveling Companions

## Famous Coders

Throughout computing there have been folks who have demonstrated amazing coding abilities. They're in the pantheon of computer programmers: Ada Lovelace, Dennis Ritchie, Rear Admiral Grace Murray Hopper, 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, or the folks who maintain the operating system we use, or someone who rose to prominence in our chosen community. It can feel a little intimidating when we compare ourselves with these folks. 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 those folks. We may even be friends with coders who seem to figure out things much quicker than we can and marvel at how they seem to have this body of knowledge that feels impossible to attain.

## 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 someone else's finished performance. How this relates is that we tend to 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 tend to see their struggles with getting things to work, or their countless hours making crappy things before they managed to make something that was much better.

## The lure of the post-mortem

There's a tradition in some programming projects (especially game development projects where there is a clear end to the project when it 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 from a vantage point 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 vantage point where the success of the project is a foregone conclusion (or the vantage point where the project is was important enough to document why it was a failure, or didn't live up to the expectations of those involved). It can give you a false-sense 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. It may never see the light of day or it might be something that changes the world. We can't know that while we're working on it (though we can have a sense of whether or not we _feel_ our work is important or not).

There's also the tendency in post-mortems to have a bit of hindsight about them. Things that were clear and definite in the moment might not make as much sense with the benefit of future-understanding. There's also selective memory where something might not be remembered with as much clarity when looking at it from the vantage point of a completed (or failed) project. Statements like "we knew this wouldn't have worked" from the vantage point of hindsight may have been "we wanted to try to see if this would not work. We were convinced it wouldn't work but we tried anyhow". Consider anyone writing about their past as an unreliable narrator. True, they may be the most experienced and knowledgeable narrator we have, but they are generally not an outside perspective on whatever they were creating.

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 may befall us 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 vantage point of someone deep in the conflict. You're looking at their recollections of tactics, not the overall strategy brought them to the place.

## Ranking programmers

There are many metrics for which folks rank various programmers. You've likely seen these metrics manifest themselves in competition sites, commits to projects, productivity, turn-around of code, and good ol' gut feelings. We do it to ourselves and others. We compare our work against 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. Or I can compare myself against folks who were mentored by programmers whose names are legendary in the field. Unfortunately I will likely find gaps between my knowledge and their knowledge. Comparisons like this tend to be unhelpful and lead us into punishing ourselves for not being the other person. We look at our projects and our history and find that we're not the other person, nor could we ever be the other person.

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. Finding other programmers who don't mind answering questions is valuable to our learning process.