Practice and Being Dumb

Posted by Ian Whitney on January 8, 2015

I’ve been thinking a lot about practice this week.

Starting a site and newsletter can be seen as a kind of anti-imposter syndrome. It’s a bold claim to the world, “Look at me! I clearly know what I’m talking about. I own this domain and everything!”

Except I never intended the site or newsletter to be seen that way. For me they are an admission of ignorance – a place for me to stupidly bash through coding exercises until I, hopefully, figure out what I’m doing. I mentioned this on the site’s about page, but since no one looks at about pages I’ll repeat it here: I have no idea what I’m doing!

The site and newsletter are a form of public practice. My hope is that by publicly doing these exercises, I will get better at code design. And other programmers who also want to improve will be able to learn from my practice. Or, even better, decide to begin their own practices.

After putting up this week’s post, I posted a link on Reddit. The two folks that replied both said that they didn’t like the refactored version. And they both suggested ways that future posts could be improved, either by using more realistic code samples or by showing the difficulty of implementing new features before refactoring.

So, one post in and already two people are telling me that I’m doing it wrong. Is that ok? Yes! Failing while practicing isn’t the problem, the problem is not noticing that you’ve failed. Noticing the failure gives you the chance to fix it next time. Not noticing just means that you’ll further reinforce the behavior next time.

All of this might be a way of me asking you to tell me when I do something dumb. If I write some code that seems wrong to you, it’s probably not because I am smart or clever. If I did something that seems dumb, it’s probably because I am dumb. And I will be less dumb if you point this out.

You can always reply to this newsletter. Or tell me that I’m dumb on twitter @iwhitney

Anyway, on with this week’s links.

Ben Orenstein has done many talks and blog posts about Vim. Even as an expert user, he is constantly practicing and improving his interactions with Vim. In this episode of Ruby Rogues he discusses his regular “tool sharpening” sessions and how he will force himself to improve his text editor habits. His techniques are applicable anywhere, not just in Vim.

The Lost Art of Finding Our Way is a book about navigation without the assistance of technology. I’m still reading it, and I’m not entirely sure that I’d recommend it, but it hits a lot of my weird interests: geography, wayfinding, ancient seafaring and so on. Throughout the book Huth says, “You’ll never figure this out by reading a book. Go out and try these techniques yourself.” And he’s right. I can read how to orient myself using the belt of Orion, but actually practicing it is something else. Should the weather here ever allow me to stand outside for more than 30 seconds, I hope to try out some of the techniques I’ve learned.

All video games require practice, but few require the kind of patient, deliberate practice that Spelunky does. Spelunky helped kick off the recent trend of “Rogue-like-like” games which are relentlessly hard and different each time you play them. The only way to succeed is to fail, again and again, as you learn the rules of the game. Death in Spelunky is never cheap or random, it is always the result of a dumb thing you did. So you learn and you practice and, eventually, you win. It is a sweet feeling. I think I died 1000 times before my first win. And I still haven’t beaten the game’s secret, even-harder ending.