Starting chapter 02

diff --git a/chapter02.md b/chapter02.md
index 0d8cbef132e0265542dff239d31e75d435281688..528a5f9018679b7cde205194ffb598bf99300eaf 100644 (file)
--- a/chapter02.md
+++ b/chapter02.md
@@ -1,3 +1,17 @@
 # Traveling Companions
 
-Discuss programming heroes, whether the ones who are famous in our field or our co-workers who are way better than us.
+## 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 from a vantage point where the success of the project is a foregone conclusion (or the vantage point where you're