Live data from Hacker News

Not All Practice Makes Perfect

nautil.us

41–50 of 62 posts

Re: Not All Practice Makes Perfect

#41
post #2

I thought it was way too verbose going over too many examples to make a simple point. "Okay, I get it, what used to be exceptional is now just "meh".. Get to the point".. It didn't address the actual matter, the one in the title, that not all practice makes perfect, until very far in the article. I then thought about an article that would have given much more information with fewer words, a seminal paper entitled "Th…

I really liked the read but I kinda agree, he seemed to make the same or similar point paragraph after paragraph.

Re: Not All Practice Makes Perfect

#42
Just going after the title, "folk aphorisms" are such pseudoscience, it's not even funny.

Not that they don't apply, they do. But "many" of the times, not "most", let alone "all of the times".

And you have aphorisms that are exact opposites of each other, like "birds of a feather flock together" and "opposites attract".

The end result? people use them more to support their opinions or gut feelings rather than uttering them after a careful analysis of the situation.

In terms of rigor, they stand at the same level as anecdotal evidence, meaning something that adds practically zero information to an ongoing situation.

Re: Not All Practice Makes Perfect

#44
post #35
post #17

Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.

I wondered the same thing. I was a classically trained musician and learned to implement some of these techniques in practice sessions. They're really effective. But how could we use "deliberate practice" to improve coding? If we assume coding to stand for solving problems with code, then it seems we'd need to deliberately practice problem solving. It's possible to measure problem solving skills, and push those skill…

It depends on what you're trying to learn with coding. I've recently had good success with this technique when applying it specifically to OpenGL. I've used a few specific parts of OpenGL extensively, and not used the rest of it very much at all. So I took some time to go through the Red Book examples very carefully and made sure I truly understood what they were doing. Then I wrote my own simple project using the techniques to make sure I understood them outside of the book. Then I started applying parts of them in my work at my job. Then I extended what we were doing in my work at my job by going a little further. And then I did it again going a little further still. It's been pretty effective.

Re: Not All Practice Makes Perfect

#45
post #8

Earlier quoted context omitted.

I think it is a common mistake by people starting to learn for example an instrument. You play the new piece, often a bit too fast, and make a mistake. Then just repeat in the same way, making exactly the same mistake over and over again. The hope is that if you play it enough times and put in enough effort you will cease making the mistake. That is of course wrong. Instead you learn the mistake really really well. W…

Not a proficient musician by any stretch of metrics/imagination. But adding onto learning new pieces, what worked for me personally is hearing the parts in the original recording, and singing the melody with my voice if it's melody or vocalizing and tapping the rhythm with my whole body (foot and spine engaged) if it's a rhythm pattern. That way, when I am playing my instrument when that problematic measure comes, I'…

Congrats, you have independently discovered solfège, a necessary tool in every musician's arsenal. :-)

Re: Not All Practice Makes Perfect

#46
post #17

Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.

Force yourself to use patterns you dont like or dont suite the task at hand. Such as: today write everything using lambda callbacks, everything mvc, no classes allowed, no malloc allowed, etc.

Re: Not All Practice Makes Perfect

#47
post #17

Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.

A good lead developer should help you grow, partially by selecting problems and partly by providing more/less structure. E.g. I might tell a junior developer to implement the design on the whiteboard and provide multiple rounds of code review, because just getting a complex implementation right is plenty challenging; for a more-senior colleague, I'm much more likely to throw him/her at a complex problem and I'll provide a few "you could have improved by ", possibly afterwards.

Re: Not All Practice Makes Perfect

#48
A learning phenoma that I find fascinating is learning things that seem impossible. I experienced most in music, learning rhythmic independence. Most instruments require this skill, but where I really noticed it is trying to play and sing songs where the rhythms are disimilar.

Upon first attempts, there is simply no ability to perform the task at all. No purchase on which to begin efforts. But somehow the trying to do it eventually does work, and will manifest as a breakthrough.

This is in contrast to practice if of skills where a path of incremental improvements is followed. (As described in the article when learning to memorize strings of numbers).

What's strange is that the beginning attempts feel like you're not learning anything, because you actually aren't doing anything that seems similar to the action you are trying to learn.

Re: Not All Practice Makes Perfect

#49
post #46
post #17

Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.

Force yourself to use patterns you dont like or dont suite the task at hand. Such as: today write everything using lambda callbacks, everything mvc, no classes allowed, no malloc allowed, etc.

That doesn't seem to me to be a directed, deliberate approach as the article implies is necessary. There's no way to know what patterns would be on the boundary of my skillset, so I might spend time using something that's unfamiliar but actually very basic which wouldn't challenge me, or something that's unfamiliar and incredibly difficult which would frustrate me because I couldn't make any progress. Isn't the reason that the system outlined in the article worked because the next level was always within reach but also something that provided a challenge? How do we get that in an arbitrary subject?

Essentially I wonder if the problem is that in some things we learn (eg coding) there isn't really a defined "ladder" that allows someone to practise harder and harder things in a deliberate way.

Re: Not All Practice Makes Perfect

#50
post #17

Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.

You can certainly practice improving your mechanics, by which I mean your IDE/development environment whether it's keyboard shortcuts or workflow imrpovements.

You can also do katas whether it's practicing TDD or setting up a new instance of a project in whatever framework you're using. I also find katas useful for keeping familiar with syntax of languages that I don't use a lot, which is useful if you do a lot of language switching.

Post reply on HN