How to do things faster!

I once saw a quote that to be able to do things faster, you need to practise doing things faster. It was attributed to Bill Gates, but I can’t verify this. At first this surprised me, as I was used to thinking that it was deep expertise that made you be faster at what you do. But in writing this article, I started to agree with this statement to a degree.

To give you an example of this, I will tell you the story of me and chess. I joined because I was interested in playing chess with other people but the people I knew in person at the time didn’t want to play chess so much. So I played the live chess, and I gained more experience with the rules, the tactics and the strategies.

Anna’s stats – (c)

I was exploring the site, and I saw this link for three-minute chess. I thought I’d give it a go. My loss was brutal, stressful, and I questioned my identity for a bit. But because it was a safe space, and I was exploring chess as a hobby, I thought I’d try to get better at this three-minute chess thing. So I played and played and played. I played 641 games over four years. As you can see from my statistics in 2010-2011 in the image, I got a lot worse before I got better. And I never regained my beginner score of 1200.

In 2013, we started playing chess in my department, socially. This was where I applied my skills in speed chess. My decisions in making moves were almost immediate, and this put pressure on my opponent. Yet while at the beginning and middle of the game I was ahead, my end game was terrible, and I end up losing the game.

Chess has 10^120 possible games. There are only a limited number of starts and the number of possibilities of the middle part of the game increases. My end game was terrible, for two possible reasons. The first is that I am not well-read on the common strategies for end game. The other possible reason, is that I had set myself an unattainable expectation that my moves must be fast all the time. The end game needs careful analysis to win, and speed is not appropriate there. The important thing is the minimum number of moves, rather than the speed at which you make them.

This is applicable for my work as well. From my experience in software production support, I got good practise at finding bugs, and developing a solution with the minimum changes, within a limited timeframe. While this skill had limited use during my PhD, it became more useful when I co-supervise students who write code, and they ask me what’s wrong with their code during a meeting.

It was also useful in quickly building proofs of concept in software. Through my PhD and my current work, I have a lot of explorations in analysis concepts, some which make it, but the majority don’t. The ability to quickly build these prototypes came from practise, as well as an expertise in what I do. I am able to determine what is important versus what is a lower priority for the prototype.

So, to cut a long story short, if you want to be faster at something, you need practise. But to be fast at something and be good at it, you also need to be able to critically assess and determine the minimum number of moves to get to where you want. This is where deep expertise, experimentation, and slowing down to think, comes into play.