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).
-### FIXME
+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 also the tendency in a post-mortem to have a sense 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 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.
-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.
+#### FIXME
## Ranking programmers
projects / themediocreprogrammer.git / commitdiff