From 26070c5b1eb7e42c8f5d090fc92c3a670338b8dc Mon Sep 17 00:00:00 2001 From: Craig Maloney Date: Tue, 7 Aug 2018 09:59:41 -0400 Subject: [PATCH] Started editing ch. 2 --- chapter02.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/chapter02.md b/chapter02.md index e0aef86..378ebcf 100644 --- a/chapter02.md +++ b/chapter02.md @@ -2,15 +2,15 @@ ## 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 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. -- 2.31.1