## 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.
+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 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.
+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 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.
+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 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).
+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).
-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.
+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 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.
+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
projects / themediocreprogrammer.git / blobdiff