Twenty-twelve was a watershed year for me: I got a Ph.D. at last; underwent my eighth and hopefully final operation in the six years following a RTA and relocated to London. An era has ended, as I finally left academia—I miss my friends and colleagues, teaching and the swimming pool. Now I’m figuring out what I want to get out of, and what I can contribute to, the next phase of my life.
Over the past several years, “I haven’t the time” has been a recurring theme. There are many things I was doing but was unable to continue, due in no small part to said RTA, and there have been many things put on the “for when the dust has settled” shelf. I have been getting better at time management and there have been creative highlights—making an “album in a day” with friends, for instance, was great fun—but my ongoing treatment had massively disruptive knock-on effects. Nevertheless, with a new start, and medical stuff slowly winding down, now’s the time…
“There is no try.”
Yoda’s wise words. I feel I now appreciate their truth; it’s brutal and it leads to cold, hard prioritisation, but it’s vitally important to pick one’s battles carefully, so that one can stay the course and achieve something. Only commit to those things you really can; nobody can see the intermediate thought and effort—as vital as they are—only the results.
As well as resisting the temptation to spin plates, one must avoid the perfectionism trap. “When it’s ready” is the right release cycle for space shuttle avionics and marmite factory control systems, but for bringing one’s past projects up to date and for starting new ones, time is of the essence. Aiming for the “minimum viable product” can help focus on what’s important and get it out of the door. When something is out there, it’s a lot easier to iterate on it and—probably even because—it’s visible! I’ve often been guilty of waiting too long, trying to ensure the architecture will remain pristine, whilst neglecting the functionality.
I’m a big believer in development as a craft and a recent convert of test-driven development (read chapters 13 to 15 of “Dive into Python” for a great introduction); code quality is important. But the most important thing is getting it out there, features missing and all, so that it can be seen, used and improved.
It’s all very well and good having picked one’s battles and freeing up the time and energy to commit to them, but how can one work out which battles to pick in the first place? “Commit early” comes in handy here too: prototype something as simply and directly as possible and see if it sticks. If it does, think hard for a while about whether it’s really worth spending time on in the long run.
I’m committing to applying this in more areas of life, from code to music and cooking. In that spirit, welcome to my ‘blog; I hope you find something of use or interest here.