Every now an again, I have to remind my self of the old adage about the perfect being the enemy of the good. I can spend a lot of time on something without ever getting to the finish line when I forget this. I'm not unusual. It's a common trait. But getting beyond this is so important, and I have had this brought into sharp focus a few of times lately in ways I found rather inspiring.
The first was at The Web Is, which was a conference in Cardiff earlier this year. The annoyingly talented Seb Lee Delisle made a throwaway comment about his 'not being that smart'. About how his skill was just that he focussed on getting things finished. That's the hard part, getting ideas out of your head and into the world. I liked that message.
This resonated with me and made me look, with a hint of shame, at the number of side projects or experiments that I had started but not completed for one reason or another. Usually that was because I couldn't make it 'perfect', or even perhaps feel 'good enough'.
Reflecting on this and in particular thinking about my latest experiment to almost see the light, spurred me on to revisit it.
Effort isn't everything
Being determined to complete a project is fine, but that alone will not protect you from sinking countless hours into something without really knowing where the finish line is. At times like that, I turn to a version of the old expression the enemy is the enemy of the good, which I first heard from my sister:
Done is better than perfect.– My big sister
This has perhaps been one of the most liberating and revisited bits of advice anyone has given me. It frees you from that sometimes crippling anxiety that prevents you even starting something. It is embodied by the open source community with the mantra of 'release early, release often'. It underpins the idea of an MVP in Agile development.
I find that when I remember it, that message just allows me to get things done.
Shrinking from judgement
The second example was at another conference. This time in Manchester at Front End North, a lovely new conference attended by many students and recent graduates.
One of the sessions there, given by Rozemary King talked about the value of play and of being creative. I loved this talk. Rozemary made some wonderful points about how we gradually get our tendancy to play and to discover, trained out of us as we grow up. She talked about the value of exercising our creative muscle without worrying about the judgement of others on how we good that creativity is.
...
The hipster tax
The third example came at the end of that same conference in Manchester. There had been several talks about the best way to approach web development, and several moments where people described the latest hot tool which you absolutely must be using or else you're doing it wrong.
I sometimes refer to "the hipster tax". It's the price you pay if you want to always be using the latest technologoy or technique. If you're not careful, you can be in a perpetual state of learning something new at the expense of using that new thing to accomplish your goals.
Shortly after describing the Hipster Tax, I went on to talk about using Gulp for automated deployment and in particular, I railed on the use of FTP for deployment, citing an example of developers 'shooting themselves in the face' by using FTP.
During the questions at the end of the day, a young woman asked a fantatstic question which made me revise my argument somewhat. She asked:
"Everyone is talking about Grunt or Gulp, and I'm worried now that I shouldn't be using FTP for my personal site. Am I doing it wrong? Do I really have to go and learn those?"– A question at Front End North
This question came in the middle of much conversation and questions about the best and the latest tools and techniques. I found the question to be more than a little bit brave, and incredibly valuable.
The answer I gave, was that she should not worry about falling in to line with what everyone was shouting about. If FTP was working fine for her on her personal project, then there was no need to have her productivity curtailed by learning something to replace it. There are bound to be plenty of other more urgent things for her to focus on. In short, my message was:
There's no need to spend time solving a problem you don't have.
Sure, for many projects, FTP deployments aren't going to cut it, and understanding the alternative will be valuable later. I personally have moved away from them for ALL projects, regardless of scale. But in asking this question, she reminded me of Rozemary's earlier message about the danger of stifling the creativity of others by being unfairly critical. It also reminded me of the dangers of optimising too early on software projects.
But most of all, it reminded me that done is better than perfect.
Satisfaction in reaching a finish line
All of these examples spurred me on to 'finish' something I had been toying with for a few weeks. I tidied it up, got it functional (but not perfect) and released it to the world. The reward was a positive response from enough people to drive me to refine it further, and even the occasional pull request where people helped me improve it.
It still might not be perfect, but I got it done.