Speed matters: Why working quickly is more important than it seems
I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection.<p>But one good counter example does come to mind - designing a database schema.<p>I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes where the future state depends on a prior state, are relevant.<p>Maybe we could say tasks are either "strongly Markvoian", that is, how well we do them now will influence our future work and hence we should really think them through, e.g. designing a schema. Weakly Markovian, in which case there may be some future impact but not much, and so we exercise caution but "done is better than perfect". And finally non-Markovian - e.g. throwing out the garbage, cooking dinner, most emails - getting the thing done is simply a pass/fail and so we just have to do it, quality is relatively unimportant.<p>I think what I'm saying is, most tasks will be weakly or non-markovian, so we should "move fast and break things", but every now and then there'll be something we need to do that is  strongly markovian. For such things we should be prepared to take a step back and give ourselves a little extra time, so things don't blow up further down the track.