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. Confident statements like "We knew this one thing wouldn't have worked" might actually 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 do not have 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 that brought that 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 that brought that them to the place.
## Ranking programmers
There's also a tendency to measure programmer productivity by how many contributions the programmer can make to a project.Under certain version control systems these are called "commits". They list out a set of changes that the programmer wishes to make to the code. In an era of social coding sites like Github and Gitlab we can easily review what other programmers are committing. Since we can measure the number of commits, we can use this measurement to feel that we're not generating the same number and frequency of commits as other programmers. And unlike measurements of old (lines of code in particular, which measures how many lines of code a programmer adds to a program) we can review the quality of their commits to a project. It can be daunting to see a lot of quality work done by our peers. It can also be source of frustration and feelings of inadequacy. "Why can't I be as productive or contribute as this other person?" we ask ourselves.
-Even more frustrating is when others use these metrics to judge productivity and code contributions. We we may find ourselves being criticized for our output (or lack thereof).
+Even more frustrating is when others use these metrics to judge productivity and code contributions. We may find ourselves being criticized for our output (or lack thereof).
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 the amount of time thinking about the problem just by looking at a commit. 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 if this commit is the result of one afternoon of work or many days of work (unless they commit more often). We might even find out that this person is acting as the focal point of an organization and is folding the work of multiple folks into their commits.
projects / themediocreprogrammer.git / blobdiff