#Gtd

OK, not sure who thought of this idea, but I absolutely love it. Personally, I use and abuse the excellent TaskPaper for my own GTD flogging (can haz iPad verzion pleaz?), but Epic Win is sheer brilliance : Your task lists as a role playing game. Brilliant.

Done right, this could unbelievably popular. WTB now. Apparently, the twitter feed for the app says it is awaiting approval in the Apple app store at the moment. Do wonder how it’ll work and sync with my desktop needs though…

I actually tried to negotiate a sabbatical after five years before coming to the new gig (particularly since I’d just given one up leaving Amnesty at the end of three years). No dice. Great little talk on the benefits of taking time out from work.

Of course, what happens is I just take mini-sabbaticals in between jobs though would really like to plan for one in a few years time from this gig (though often think I am kidding myself that I’ll ever take time off properly - when will those books get written?).

Great little video from Jason Fried (ostensibly flogging Rework, 37Signals’ new book) on why modern offices are constructed to optimize interruptions and why you and I spend all our time on weekends and after work getting real work done.

Offices are optimized for interruptions and interruptions are the enemy of work, creativity, and productivity.

And yeah, the fact, I am working at home while penning this, instead of out surfing today, is probably a good indication of it as a truism.

Fantastic Do lecture from “Vagabonding”’s Rolf Potts, traveller extraordinaire, on taking some lessons from approaching travel to how you should live your real life. Definitely worth your time to watch the whole thing.

Best quote: “Life does not reward you with free time, you need to create it.”

The always astute Joel Spolsky talking about the book Coders at Work. Zeroes in on a interview with Joel Zawinski and the avoidance of technical fancy-pantsedness. Love this quote from Zawinski when asked about his pet peeve for over-engineering:

‘Yeah,’ he says, ‘At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.’

Shipping is a feature. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing.

Gene Kranz was Flight Director during the Apollo missions and the guy immortalized as the get it done person who helped get the Apollo 13 astronauts home when everyone else thought they were done for and famously attributed to the quotation “Failure is not an option.” This is what he said after the death of three astronauts in a training exercise in 1967 which became known as the Kranz Dictum:

Great post on Startup CTO mistakes I’d rather not repeat…

1. Not getting involved in “the business”
2. Keeping the technology vision in your head
3. Adopting bleeding-edge technology
4. Giving up control of the development process
5. Staying too hands-on and not getting hands-on enough

I actually found it interesting how these were still applicable to my current non-startup role.

The bleeding edge technology one is one I’ve managed to avoid (though my team would argue any open source and anything but java is bleeding edge), but I think more poignant is the one about giving up control of development since it makes it impossible to execute on a technology vision. And yeah, could probably be accused of keeping too much of the tech vision in my head (or not communicating it well enough). Sometimes what seems obvious and transparent when you’ve thought it up is pretty murky to other people (so add communicating it better as well).

It’s a bit sad I predate the moon landing, but this is kinda cool. In a few scant days, we’ll be celebrating the 40th anniversary of the moon landing which is a symbolic milestone that all humanity can be proud of despite what we’ve done in space since then.

I should point out I often use Kennedy’s example of this as a clear BHAG (Big, Hairy Audacious Goal), when talking about strategy planning because it has a clear, measurable, unambiguous achievement within a time limit.

Really useful article on how to start implementing continuous deployment in your organization. It encapsulates a lot of the stuff I just posted on the Five Whys and Lean Startups.

I can imagine a few other things you need here, like a complete sandbox for for each dev, as well as the continuous integration server to keep testing every commit, and the cultural change is enormous but not onerous.

I think the other important thing is that this is scary. Even me at my most crazy would be a bit concerned about this. People will be worried, especially if this is something you haven’t done from the very start. You also need a culture that doesn’t punish honest mistakes. Otherwise, people will fear to deploy something in short cycles from idea to production in nothing time.

Great article from the currently totally-on-fire Eric Ries.

One of the major things we’ve learned about user stories, even if we’ve never articulated it, is about “popping the why stack.” In essence, you ask “Why ?” a number of times and, if at the end of those five whys, the answer isn’t increasing revenue, protecting revenue, or reducing costs, that feature you’re writing probably isn’t worth the time.

I never realized the idea came from Toyota where it’s practically a gospel part of their keizen process in improving quality and reducing defects.