Additional edits in chapter 02
authorCraig Maloney <craig@decafbad.net>
Sat, 29 Jun 2019 16:19:41 +0000 (12:19 -0400)
committerCraig Maloney <craig@decafbad.net>
Sat, 29 Jun 2019 16:19:41 +0000 (12:19 -0400)
chapter02.md

index 981987608b67f13f7352603cf122757b149bd741..3bab5dd2bcb320b65e118cdf04d19023e7dd0d7a 100644 (file)
@@ -14,9 +14,9 @@ There's a tradition in some programming projects (especially in game development
 
 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 worked on a project that was successful enough for you to spend time 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 to the belief 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 would work or be successful as they were working on it. Our projects may never see the light of day or they 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.
+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 with data obtained later in the project's lifespan. There's also an issue with "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 not an objective 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.
+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 that them to the place.
 
 ## Ranking programmers