6 ms·

The Mundanity of Excellence

49 points by prakash 19y ago

DougBTX 19y ago
Cheers for posting this.
gruseom 19y ago
Wow. This is a wonderful article that contains an analysis of excellence based on close observation of competitive swimmers over several years. One could even describe it as an excellent article, using its own definition of excellence. I doubt I would have run across it otherwise, so it's a really good example of why I read HN. Tip: Google Books leaves out a few pages (in my case, 34 and 35). To read these, I went to Google Books in a different browser and searched for text from the top of the next page I did have (36). Their back button then took me to the missing pages. Note that using a different browser is essential (I suppose they use a cookie).
- mechanical_fish 19y ago
  It was a wonderful article until it suddenly stopped in mid-argument. Google Books is like being strapped to a library and tortured. And I do not have time to dork around with three different browsers. Could somebody paraphrase this in a blog post and free it from the tyranny of restrictive copyright? Note to publisher: I see that your 456-page book costs $45. Today I just want to read one article that spans 13 of those pages, without leaving my chair, waiting 2-4 days, losing my train of thought, or spending extra money on other pages that I don't have time to read anyway. If it were technically possible, I would happily pay you 13/456 of the book's price -- $1.28 -- for an electronic copy of the pages in question. I might even pay $2. But it's not technically possible, so I guess I'll just have to hate you today.
  - dangoldin 19y ago
    I think this does a pretty good job covering it: http://www.stubbleblog.com/index.php/2008/05/deliberate-practice/ http://www.stubbleblog.com/index.php/2008/05/deliberate-prac... You have a valid point - it would be great if you can buy books per page - especially compilations. Maybe there's an opportunity for someone.
  - gruseom 19y ago
    Two different browsers. And at most 30 seconds. But I take your point. Before that trick I tried googling for the article itself, and all I found was the publisher offering to sell it for $14. (It would probably take months to arrive, too.) There you have the market inefficiency. I'd happily pay, but nowhere near that much, and only if I get to read it immediately.
    - mechanical_fish 19y ago
      Mind you, I didn't mean to suggest that your handy advice was not very, very welcome. :) I might even get around to trying it later. I just wanted to register my annoyance at the state of online publishing while it was still fresh.
    - andreyf 19y ago
      only if I get to read it immediately I'm sure Scribd has considered this model.
jimbokun 19y ago
So anyone want to take a stab at the qualitatively different practices that separate classes of people who program computers? (Was about to write "people who hack", but think that hacking itself is a qualitatively different way of writing computer programs than what most people do.)
- llimllib 19y ago
  A few ideas: * Learn how to use their tools effectively * Aggressively simplify * Understand math * Understand fundamental computer science principles
  - manny 19y ago
    *Understand math Thank you for also realizing this. It is just mind boggling to me how many IT people are so utterly inept when it comes to basic mathematics. I truely believe that the fact that so many IT employees don't know math is leading to this superficial computer-geek culture.
- andreyf 19y ago
  One could write a series of books on this. Using functional programming techniques, using macros, writing DSL's come to mind first. More generally, trying to do what PG is doing with Arc - writing code that does the most using the least number of "thoughts", abstracting patterns as much as possible, the DRY principle, etc.
  - neodude 19y ago
    There was this guy, I think his first name was Donald..
- nostrademons 19y ago
  I mentioned some in a comment yesterday: http://news.ycombinator.com/item?id=185105 http://news.ycombinator.com/item?id=185105
  - 19y ago
swombat 19y ago
35 pages to get across the "deliberate practice" idea? I hate to be ever so demanding, but why are we voting this up when a much shorter article gets the entire point across? (see http://news.ycombinator.com/item?id=185533 http://news.ycombinator.com/item?id=185533 ) Daniel
- gruseom 19y ago
  a much shorter article gets the entire point across I so disagree. First of all, the article has more than one point; I'm surprised that's not obvious. For another thing, its supporting evidence and reasoning are considerable, relevant, and fascinating. More than that, I personally found it to be rich in subtleties, of the kind that would draw me back to reread and reflect. Does a vitamin C pill get across the entire point of an orange? I know 35 pages of blah blah blah when I see it. This piece deserves closer attention. Look again.
  - neodude 19y ago
    YMMV, but it was absolutely fasinating for me, especially because I spent a significant portion of my teenage life swimming in a team, going to meets, etc. The antidotes in the article - even the subjective ones - resonate so well with my memory of who and how they got faster, and who didn't (in most cases, me), that I'm blown away with the revelations. I can go back and read that article a couple more times and get more and more out of it. But, YMMV.
  - tonystubblebine 19y ago
    My coach gave me a printed version of this article in 1997. I'm still thinking about it and give it the occasional re-read. This discussion thread really highlights how awful it is that so much research is locked up behind pay walls. I'm pretty sure the article was originally published in a sports psychology journal but here we are, a bunch of hackers, who are trying our best to enjoy it through Google book search (described above as like "being strapped to a library and tortured").
lliiffee 19y ago
I couldn't get this from google books, but I was able to read it through JSTOR. I think my institution is providing this access, but perhaps someone else has it too... http://www.jstor.org/stable/202063 http://www.jstor.org/stable/202063
- gcheong 19y ago
  I was able to get to it through the San Francisco Public library website using my library card. Best use of my library card in about 3 years!
mnemonicsloth 19y ago
Fundamentally important -- this belongs in the instruction manual to the human brian. I do wish this author's prose style was less excellent at concealing this fact.
nostrademons 19y ago
I remember having a conversation with a couple coworkers and my former boss about the nature of "talent". My hypothesis is that what we think of as innate talent or giftedness really arises from slight differences in pain/reward pathways in the brain, such that "gifted" people derive enjoyment from activities that the average person finds very boring. This leads to them practicing those activities more often, which leads to them becoming more skilled, which leads to more enjoyment, and a positive feedback cycle ensues. The amazing feats we see are the cumulative results of years of this feedback cycle - at each stage, the gifted person is just a little bit better than the average folk and enjoys the activity just a little more, but over time that lead compounds. That was my experience with math, and has for the most part been my experience with computers. Even when I was "on strike" in 6th grade and refused to do any schoolwork, I found it very difficult to avoid the math tests or homework. I tried once and found it so boring that on all further math work, if I wanted to protest how stupid the assignment was, I'd just do all the work and write down the wrong answers in the answer column or do it and refuse to turn it in. When I quit my job to work on my startup, my former boss threw up all sorts of objections like "You have no idea if this'll work, and if it doesn't, you might find yourself writing lots of code for nothing, and that really sucks." And I just kinda looked at him a little funny. What I wanted to say was, "Dude, that's what I do anyway. That's what I do for you, that's what I do when I get home, and that's what I'd continue to do even if I cashed out for millions. There's nothing wrong with writing lots of code for nothing, and on the off chance it succeeds, it means I won't have to work for superficial idiots like you." (I didn't; I just said "Okay. I'm still leaving" and left.)
- dfranke 19y ago
  Aside from the last clause, I'd have gone ahead and said it.
  - nostrademons 19y ago
    It sounded overdramatic in my head at the time, and I was sick of arguing about whether or not it was a good idea. I'd argued enough with myself about whether it was a good idea; I didn't think that either me nor my boss was going to convince the other, so I didn't see anything productive that could come out of the discussion. Interestingly, our sales guy (who'd been sent to me earlier to get me to stay) saw this immediately. After I explained why I was doing this, he said immediately, "So, even if the Goldman Sachs deal came through tomorrow, and we were rolling in customers, you'd still leave?" I said "Yeah. This is something I have to do, regardless of what the outcome is or what I'm giving up in the process." And he just said, "Interesting. I see where you're coming from. You should go do it; when you're this set on something, you're doing a disservice both to us and to yourself to not pursue it."
asdf333 19y ago
bravo for sharing a thought provoking link and not a 5 second sound-bite.
throwawayaccnt 19y ago
here, I made this for you... Happy Mother's day... back to lurking. http://www.scribd.com/doc/2926754/The-Mundanity-of-Excellence http://www.scribd.com/doc/2926754/The-Mundanity-of-Excellenc...
- ovi256 19y ago
  Guys, upmod him, we need to get this link to the top. PS: Thanks a lot man.
zach 19y ago
If you all don't mind long articles, I hope I can be forgiven for a long comment. This is an excerpt buried in Zed Shaw's interview with Geoffrey Grossenbach transcribed here: http://podcast.rubyonrails.org/programs/1/episodes/zed_shaw http://podcast.rubyonrails.org/programs/1/episodes/zed_shaw --- Geoffrey: One thing I’ve always been fascinated whenever I’ve talked to you about it is just your personal process of development. You’re definitely someone who tries to pick the best tools and customize them to make them work as well as you can. You also have something where you keep track of your bug rate and how many bugs you’re writing, and tests that fail and then you adjust your process. How does that work? Zed: That’s not recommended for everyone. You have to basically be really, really disciplined. I’m actually not really, really disciplined; I’m doing it on one project, on my U2 project, and I’m tryout basically kind of like a quality control process – physical quality control. All I do is I track a bunch of metrics that don’t necessarily say how many bugs there are exactly, but they’re indicators of the bugs. I track them over time, and then I use statistics to tell me if I’m starting to suck or if I’m improving. I’m doing mostly C coding on that project, so a lot of this is I’m running my program under Valgrind with heavy testing. Then I track what my test coverage is, and then basically it’s just a series of numbers stream across my screen as I code. It’s kind of like auto-test – when I compile the thing it codes it – and then about every maybe 300 sampled I take a break, go in and crunch the numbers, and I see if I did better than last month. A lot of times what I’ll do is I’ll try a new technique; I’ll try a technique for a while and then I’ll go crunch the numbers and see if I actually had a statistical improvement or not. That’s the biggest thing; I don’t waste my time on stuff that doesn’t actually improve the bug rate – the defect rate. For example, at first I wasn’t doing code coverage. I wanted to see if code coverage improved your testing – coverage of your test code, or your test code having coverage. I wanted to see if that improved quality. So I didn’t do any code coverage. I measured all of my defect rates and figured out what my average defect rate was. I did maybe about 700 or 800 samples. Then I started doing code coverage and beefing up my code coverage. I spent maybe about a month improving my code coverage. In C code it’s real hard to get really good coverage because so many lines do so much stuff. But I got it up to about 60 percent. Then I went and crunched the numbers again to see if increasing the code coverage in test improved my defect rate. What happened was it didn’t improve my defect rate; my defect rate was still about the same. What it did improve was when I made changes – like if I had to do re-factoring – it reduced the amount of time to get my defects back down. So you make a change, you do your re-factoring, your defects go up, your defects go up, and then you have to spend time fixing all that. With heavier, more test-coverage it made it go down quicker, but it didn’t really improve my defect rate much. There’s some complexity in that. When you have more coverage, you are seeing more of your defects, so that’s part of it, but I found that test-coverage doesn’t really justify an improvement in quality initially. It mostly just improves your time to fix later. But out of the ways, that’s some weird stats crunching. The process actually comes from the Capability Maturity Models – Skies, Watson Freeze, Personal Software Process. So all you’ve got to do is rather go get his book, go through what he recommends. The key is as your code. Keep metrics and then crunch numbers to see if that’s improving things for you, and that’s really all that is.

49 points by prakash 19y ago

Cheers for posting this.

Wow. This is a wonderful article that contains an analysis of excellence based on close observation of competitive swimmers over several years. One could even describe it as an excellent article, using its own definition of excellence. I doubt I would have run across it otherwise, so it's a really good example of why I read HN. Tip: Google Books leaves out a few pages (in my case, 34 and 35). To read these, I went to Google Books in a different browser and searched for text from the top of the next page I did have (36). Their back button then took me to the missing pages. Note that using a different browser is essential (I suppose they use a cookie).

mechanical_fish 19y ago
It was a wonderful article until it suddenly stopped in mid-argument. Google Books is like being strapped to a library and tortured. And I do not have time to dork around with three different browsers. Could somebody paraphrase this in a blog post and free it from the tyranny of restrictive copyright? Note to publisher: I see that your 456-page book costs $45. Today I just want to read one article that spans 13 of those pages, without leaving my chair, waiting 2-4 days, losing my train of thought, or spending extra money on other pages that I don't have time to read anyway. If it were technically possible, I would happily pay you 13/456 of the book's price -- $1.28 -- for an electronic copy of the pages in question. I might even pay $2. But it's not technically possible, so I guess I'll just have to hate you today.
- dangoldin 19y ago
  I think this does a pretty good job covering it: http://www.stubbleblog.com/index.php/2008/05/deliberate-practice/ http://www.stubbleblog.com/index.php/2008/05/deliberate-prac... You have a valid point - it would be great if you can buy books per page - especially compilations. Maybe there's an opportunity for someone.
- gruseom 19y ago
  Two different browsers. And at most 30 seconds. But I take your point. Before that trick I tried googling for the article itself, and all I found was the publisher offering to sell it for $14. (It would probably take months to arrive, too.) There you have the market inefficiency. I'd happily pay, but nowhere near that much, and only if I get to read it immediately.
  - mechanical_fish 19y ago
    Mind you, I didn't mean to suggest that your handy advice was not very, very welcome. :) I might even get around to trying it later. I just wanted to register my annoyance at the state of online publishing while it was still fresh.
  - andreyf 19y ago
    only if I get to read it immediately I'm sure Scribd has considered this model.

jimbokun 19y ago

So anyone want to take a stab at the qualitatively different practices that separate classes of people who program computers? (Was about to write "people who hack", but think that hacking itself is a qualitatively different way of writing computer programs than what most people do.)

llimllib 19y ago
A few ideas: * Learn how to use their tools effectively * Aggressively simplify * Understand math * Understand fundamental computer science principles
- manny 19y ago
  *Understand math Thank you for also realizing this. It is just mind boggling to me how many IT people are so utterly inept when it comes to basic mathematics. I truely believe that the fact that so many IT employees don't know math is leading to this superficial computer-geek culture.
andreyf 19y ago
One could write a series of books on this. Using functional programming techniques, using macros, writing DSL's come to mind first. More generally, trying to do what PG is doing with Arc - writing code that does the most using the least number of "thoughts", abstracting patterns as much as possible, the DRY principle, etc.
- neodude 19y ago
  There was this guy, I think his first name was Donald..
nostrademons 19y ago
I mentioned some in a comment yesterday: http://news.ycombinator.com/item?id=185105 http://news.ycombinator.com/item?id=185105
- 19y ago

swombat 19y ago

35 pages to get across the "deliberate practice" idea? I hate to be ever so demanding, but why are we voting this up when a much shorter article gets the entire point across? (see http://news.ycombinator.com/item?id=185533 http://news.ycombinator.com/item?id=185533 ) Daniel

gruseom 19y ago
a much shorter article gets the entire point across I so disagree. First of all, the article has more than one point; I'm surprised that's not obvious. For another thing, its supporting evidence and reasoning are considerable, relevant, and fascinating. More than that, I personally found it to be rich in subtleties, of the kind that would draw me back to reread and reflect. Does a vitamin C pill get across the entire point of an orange? I know 35 pages of blah blah blah when I see it. This piece deserves closer attention. Look again.
- neodude 19y ago
  YMMV, but it was absolutely fasinating for me, especially because I spent a significant portion of my teenage life swimming in a team, going to meets, etc. The antidotes in the article - even the subjective ones - resonate so well with my memory of who and how they got faster, and who didn't (in most cases, me), that I'm blown away with the revelations. I can go back and read that article a couple more times and get more and more out of it. But, YMMV.
- tonystubblebine 19y ago
  My coach gave me a printed version of this article in 1997. I'm still thinking about it and give it the occasional re-read. This discussion thread really highlights how awful it is that so much research is locked up behind pay walls. I'm pretty sure the article was originally published in a sports psychology journal but here we are, a bunch of hackers, who are trying our best to enjoy it through Google book search (described above as like "being strapped to a library and tortured").

lliiffee 19y ago

I couldn't get this from google books, but I was able to read it through JSTOR. I think my institution is providing this access, but perhaps someone else has it too... http://www.jstor.org/stable/202063 http://www.jstor.org/stable/202063

gcheong 19y ago
I was able to get to it through the San Francisco Public library website using my library card. Best use of my library card in about 3 years!

mnemonicsloth 19y ago

Fundamentally important -- this belongs in the instruction manual to the human brian. I do wish this author's prose style was less excellent at concealing this fact.

nostrademons 19y ago

I remember having a conversation with a couple coworkers and my former boss about the nature of "talent". My hypothesis is that what we think of as innate talent or giftedness really arises from slight differences in pain/reward pathways in the brain, such that "gifted" people derive enjoyment from activities that the average person finds very boring. This leads to them practicing those activities more often, which leads to them becoming more skilled, which leads to more enjoyment, and a positive feedback cycle ensues. The amazing feats we see are the cumulative results of years of this feedback cycle - at each stage, the gifted person is just a little bit better than the average folk and enjoys the activity just a little more, but over time that lead compounds. That was my experience with math, and has for the most part been my experience with computers. Even when I was "on strike" in 6th grade and refused to do any schoolwork, I found it very difficult to avoid the math tests or homework. I tried once and found it so boring that on all further math work, if I wanted to protest how stupid the assignment was, I'd just do all the work and write down the wrong answers in the answer column or do it and refuse to turn it in. When I quit my job to work on my startup, my former boss threw up all sorts of objections like "You have no idea if this'll work, and if it doesn't, you might find yourself writing lots of code for nothing, and that really sucks." And I just kinda looked at him a little funny. What I wanted to say was, "Dude, that's what I do anyway. That's what I do for you, that's what I do when I get home, and that's what I'd continue to do even if I cashed out for millions. There's nothing wrong with writing lots of code for nothing, and on the off chance it succeeds, it means I won't have to work for superficial idiots like you." (I didn't; I just said "Okay. I'm still leaving" and left.)

dfranke 19y ago
Aside from the last clause, I'd have gone ahead and said it.
- nostrademons 19y ago
  It sounded overdramatic in my head at the time, and I was sick of arguing about whether or not it was a good idea. I'd argued enough with myself about whether it was a good idea; I didn't think that either me nor my boss was going to convince the other, so I didn't see anything productive that could come out of the discussion. Interestingly, our sales guy (who'd been sent to me earlier to get me to stay) saw this immediately. After I explained why I was doing this, he said immediately, "So, even if the Goldman Sachs deal came through tomorrow, and we were rolling in customers, you'd still leave?" I said "Yeah. This is something I have to do, regardless of what the outcome is or what I'm giving up in the process." And he just said, "Interesting. I see where you're coming from. You should go do it; when you're this set on something, you're doing a disservice both to us and to yourself to not pursue it."

asdf333 19y ago

bravo for sharing a thought provoking link and not a 5 second sound-bite.

throwawayaccnt 19y ago

here, I made this for you... Happy Mother's day... back to lurking. http://www.scribd.com/doc/2926754/The-Mundanity-of-Excellence http://www.scribd.com/doc/2926754/The-Mundanity-of-Excellenc...

ovi256 19y ago
Guys, upmod him, we need to get this link to the top. PS: Thanks a lot man.

zach 19y ago

If you all don't mind long articles, I hope I can be forgiven for a long comment. This is an excerpt buried in Zed Shaw's interview with Geoffrey Grossenbach transcribed here: http://podcast.rubyonrails.org/programs/1/episodes/zed_shaw http://podcast.rubyonrails.org/programs/1/episodes/zed_shaw --- Geoffrey: One thing I’ve always been fascinated whenever I’ve talked to you about it is just your personal process of development. You’re definitely someone who tries to pick the best tools and customize them to make them work as well as you can. You also have something where you keep track of your bug rate and how many bugs you’re writing, and tests that fail and then you adjust your process. How does that work? Zed: That’s not recommended for everyone. You have to basically be really, really disciplined. I’m actually not really, really disciplined; I’m doing it on one project, on my U2 project, and I’m tryout basically kind of like a quality control process – physical quality control. All I do is I track a bunch of metrics that don’t necessarily say how many bugs there are exactly, but they’re indicators of the bugs. I track them over time, and then I use statistics to tell me if I’m starting to suck or if I’m improving. I’m doing mostly C coding on that project, so a lot of this is I’m running my program under Valgrind with heavy testing. Then I track what my test coverage is, and then basically it’s just a series of numbers stream across my screen as I code. It’s kind of like auto-test – when I compile the thing it codes it – and then about every maybe 300 sampled I take a break, go in and crunch the numbers, and I see if I did better than last month. A lot of times what I’ll do is I’ll try a new technique; I’ll try a technique for a while and then I’ll go crunch the numbers and see if I actually had a statistical improvement or not. That’s the biggest thing; I don’t waste my time on stuff that doesn’t actually improve the bug rate – the defect rate. For example, at first I wasn’t doing code coverage. I wanted to see if code coverage improved your testing – coverage of your test code, or your test code having coverage. I wanted to see if that improved quality. So I didn’t do any code coverage. I measured all of my defect rates and figured out what my average defect rate was. I did maybe about 700 or 800 samples. Then I started doing code coverage and beefing up my code coverage. I spent maybe about a month improving my code coverage. In C code it’s real hard to get really good coverage because so many lines do so much stuff. But I got it up to about 60 percent. Then I went and crunched the numbers again to see if increasing the code coverage in test improved my defect rate. What happened was it didn’t improve my defect rate; my defect rate was still about the same. What it did improve was when I made changes – like if I had to do re-factoring – it reduced the amount of time to get my defects back down. So you make a change, you do your re-factoring, your defects go up, your defects go up, and then you have to spend time fixing all that. With heavier, more test-coverage it made it go down quicker, but it didn’t really improve my defect rate much. There’s some complexity in that. When you have more coverage, you are seeing more of your defects, so that’s part of it, but I found that test-coverage doesn’t really justify an improvement in quality initially. It mostly just improves your time to fix later. But out of the ways, that’s some weird stats crunching. The process actually comes from the Capability Maturity Models – Skies, Watson Freeze, Personal Software Process. So all you’ve got to do is rather go get his book, go through what he recommends. The key is as your code. Keep metrics and then crunch numbers to see if that’s improving things for you, and that’s really all that is.