Writing helps to clarify your thoughts, and I should do more of it. I used to do it a lot, when I had more time on my own. Work, marriage and parenthood get in the way, but there isn’t really an excuse - it’s always possible to make time for something if you value it enough. You just have to stop spending time doing something else.
The most difficult part is starting. Getting a first draft is an enormous step.
Working in technology, surrounded by devices, it’s easy to think that it makes sense to take notes on a laptop or a tablet - you can keep everything in one place, and you don’t end up with scraps of paper cluttering the place up.
But writing on paper forces iteration, and iteration encourages editing. In the same way, it’s often useful to scribble wireframes on paper, rather than using fancy tools. The fact that they look unfinished gives you the permission to change everything - it invites iteration, and is “probably the best tool we have to design great user experiences”.
The other benefit of using pen and paper is that as long as you can find your devices, there’s no context switching, no distraction, no loading time, ink runs out more slowly than batteries, and there are fewer things likely to get in the way of the expression of your thoughts.
People building software often talk about iterative, incremental delivery, but there’s no reason why that can’t be applied to writing a blog.
There’s a balance that needs to be struck between getting things done and getting things right, between making things better and getting something, anything out of the door, as long as it’s good enough.
Makes sense in startups, but what’s the MVP for a piece of writing? I’m definitely in favour of putting an initial draft out there early, releasing a beta version as soon as you can.
There are a million people out there telling us that we should be aiming for good enough, rather than perfection, so I won’t labour the point, other than to say that they’re right.
I build websites, and when I look back at things I’ve done in the past, I often scratch my head, partly in confusion, partly in embarrassment. All developers have got code that we’re not proud of, and we’ve all cut corners when the needs of the project dictate it. But you have to start somewhere, even if that means changing almost everything later on.
Often the reason for the mess is the fact that you didn’t really know how you were going to do the thing when you started. And that’s OK - as Brian Eno says, it’s “often the case that people work best when they are stretching out over an abyss of ignorance”.
I think back to my computer science course, where we wrote pseudocode on paper to figure out how we were going to approach a problem - the finished code ended up a higher quality because we had thought about things first.
Equally, when I look back at my old notebooks, there are definitely some pieces of writing that are better off not seeing the light of day. But I’m not writing because I know everything - I don’t know it all, and that’s OK.