Comment by kpennell | Hacker News Reader

Comment by kpennell | Hacker News Reader

Parent Full thread

I read this article a while ago and recently re-listened to his interview on Tim Ferriss' podcast: https://www.youtube.com/watch?v=gnk4sgOFjBQ He talks about how maniacal he was at practicing music at a young age. His friends gave him a hard time because all he wanted to do was practice scales over and over. The dude was exceptionally motivated from a very early age.

The gist of this blog post is that the average pace is for chumps and that he was able to finish Berkelee school of music in much less time than the average person takes thanks to studying ahead of time with a mentor and reading the books and testing out. He wasn't a 'chump' and the lesson is that you shouldn't be either.

I remember reading this advice 10 years ago and really taking it to heart. I didn't want to be a chump afterall and became convinced I could do everything faster than the chumps. But the problem with this is that it can make you beat yourself up and/or always feel rushed if it does take you a normal amount of time to do something. Like I've had to admit that I'm a really slow programmer. It took me forever to learn it. And I beat myself up a lot in the process.

But now I've taken to listening to more Alain de botton and Oliver Burkeman for my self-help/self-development. These British authors advocate for a much gentler version of self help. In one Alain de botton interview, he mentioned how we've come to worship exceptionalism and see being average as being bad. Oliver Burkeman's 4000 weeks book plainly states that you can't do it all. This has been super refreshing for someone like me who took Sivers' stuff seriously in my early 20s and then beat myself up for merely being average at many things.

You provided a lot of great context here that wasn't in the article. I found it suspect to begin with unless he had a lot of knowledge or was exceptional. How did he know how to answer those questions in the first lesson with the mentor unless he already had a strong understanding of chords going into it? In other words, he had enough knowledge that the mentor could accelerate accumulating more on top of it. But he had to have already spent a huge amount of time (equivalent to several college semesters) acquiring knowledge to be at that point.

I found the rest of your comment interesting too, but I don't think the overall point of the original article is invalidated, it just needs a caveat. There is no speed limit, except your own ability!

Consider that while the author got good at music, the chumps got moderately good at everything else as well that can be quite fulfilling. And the author missed out on life experiences that you can only have during age 18-19-20.

With time as a limited dwindling resource, we all make tradeoffs and optimize for what we care about. From that lens, the "chumps" don't seem like chumps at all, and neither does the author.

> I've had to admit that I'm a really slow programmer.

I am, too! Mostly the people I've worked with were much faster than me. Some are genuinely great, some just produce rubbish, and some are inbetween.

In my experience, slow programmers produce less rubbish on average than the fast ones. Perhaps I'm biased :)

Seeing how I agree with your thoughts in general, I’m now en route to pick up a copy of 4000 weeks. Thanks!

hope you enjoy. It's one of the books I've highlighted the most

I enjoyed it. I liked the acknowledgement of the finiteness of life and the reality of hard decisions. That productivity books really are missing the point - tinkering at the edges to squeeze out 5% extra productivity does not confront the reality that you’ll still be unable to complete almost everything you really want to in life.

I think what was lacking is a bit more concrete guidance. I know it’s almost the point of the book not to provide any, but perhaps more qualitative examples would help.

Definitely helped me overall and changed my mindset somewhat.

awesome. thx for returning to comment.

It's not coding you should be quick at but finding a robust design, that doesn't need a lot of fixes or rework. It takes practice and experience and may not be as glamorous. Also takes an experienced boss to appreciate, but there are jobs for us.

> It's not coding you should be quick at but finding a robust design, that doesn't need a lot of fixes or rework.

Yes, but you don't even need to be quick (modulo company/team-politics, which tends to favor speed). I am a slow but good architect, but slow doesn't hurt because it's going to be dwarfed by implementation time anyway. Not to mention, paper+pencil+contemplating is the most fun part!

How do you measure programming speed? Everyone remembers an instance where they lost a sizeable amount of work, only to figure out that you could easily recreate the work in a few hours because you know what has to be done. Programming is not the only part of the job.

Reply on news.ycombinator.com