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