Mark Needham

Thoughts on Software Development

Deliberate Practice: Watching yourself fail

with 5 comments

Think bayes cover medium

I’ve recently been reading the literature written by K. Anders Eriksson and co on Deliberate Practice and one of the suggestions for increasing our competence at a skill is to put ourselves in a situation where we can fail.

I’ve been reading Think Bayes – an introductory text on Bayesian statistics, something I know nothing about – and each chapter concludes with a set of exercises to practice, a potentially perfect exercise in failure!

I’ve been going through the exercises and capturing my screen while I do so, an idea I picked up from one of the papers:

our most important breakthrough was developing a relatively inexpensive and efficient way for students to record their exercises on video and to review and analyze their own performances against well-defined criteria

Ideally I’d get a coach to review the video but that seems too much of an ask of someone. Antonios has taken a look at some of my answers, however, and made suggestions for how he’d solve them which has been really helpful.

After each exercise I watch the video and look for areas where I get stuck or don’t make progress so that I can go and practice more in that area. I also try to find inefficiencies in how I solve a problem as well as the types of approaches I’m taking.

These are some of the observations from watching myself back over the last week or so:

  • I was most successful when I had some idea of what I was going to try first. Most of the time the first code I wrote didn’t end up being correct but it moved me closer to the answer or ruled out an approach.

    It’s much easier to see the error in approach if there is an approach! On one occasion where I hadn’t planned out an approach I ended up staring at the question for 10 minutes and didn’t make any progress at all.

  • I could either solve the problems within 20 minutes or I wasn’t going to solve them and needed to chunk down to a simpler problem and then try the original exercise again.

    e.g. one exercise was to calculate the 5th percentile of a posterior distribution which I flailed around with for 15 minutes before giving up. Watching back on the video it was obvious that I hadn’t completely understood what a probability mass function was. I read the Wikipedia entry and retried the exercise and this time got the answer.

  • Knowing that you’re going to watch the video back stops you from getting distracted by email, twitter, Facebook etc.
  • It’s a painful experience watching yourself struggle – you can see exactly which functions you don’t know or things you need to look up on Google.
  • I deliberately don’t copy/paste any code while doing these exercises. I want to see how well I can do the exercises from scratch so that would defeat the point.

One of the suggestions that Eriksson makes for practice sessions is to focus on ‘technique’ during practice sessions rather than only on outcome but I haven’t yet been able to translate what exactly that would involved in a programming context.

If you have any ideas or thoughts on this approach do let me know in the comments.

Be Sociable, Share!

Written by Mark Needham

April 25th, 2015 at 10:26 pm

  • Alexandre Martinez

    IMHO, technique in programming can refer to the ability to structure the code produced iteratively, refactoring the code as you go to achieve a more decoupled and readable code.

  • Dezo

    Another possibility is to think about causes of failed tests/bugs, and time spent on manual tasks.

    Btw deliberate practice is, from my view, the key point of the book Talent is overrated.

  • @disqus_RqsuAueU94:disqus interesting observation…then I wonder how to assess your skill at doing that in an individual exercise?

  • @dezom:disqus agreed – although since I wrote this post I haven’t been structuring my practice particularly deliberately so this is a good reminder to get back on it 🙂

  • Alexandre Martinez

    Deliberate practice in programming can aim at improving several skills at once : awareness of code deterioration, seeing possible improvements in existing code, applying said improvements. Awareness evolves as critical thinking about code develops, critically reading one’s old code can be quite revealing regarding one’s progress. The number of improvements one can see in code depends and the ease (or speed) with which improvements are applied can be used. How to choose the correct improvement is important too.