Journaling

n. The activity of keeping a diary, also known as journal.

As much as I love the idea of keeping a journal, I suck at it. Like most things – and most people – I start out with the best of intentions, but fail to maintain the habit; also, like a bad workman, I often blame the tools but the truth is that it is habit and nothing more.

I’ve tried many tools and formats over the years; too many to list here. Inspired by my eldest daughters recent experiments with Bullet Journal – complete with shiny new Moleskine notebook and washi tape decorations, see the featured image on this post – I started thinking about how to kickstart my journaling habit.

As much as I love analog methods (I am also a sucker for nice notebook and pen) the reality is that I spend most of my time in front of my MacBook Pro or with my iPhone (no Watch, yet 😉) nearby so a digital solution works best for me. Since I am already deep into the Apple lifestyle, the natural choice is Day One from Bloom and it is a very nice app. If you don’t believe me, go read this review from The Sweet Setup.

However I work for a company whose primary product is a blogging platform, and what is a blog if not a form of journaling? Of course a journal should be personal, so I just setup a [private]|(https://en.support.wordpress.com/settings/privacy-settings/) blog, picked a theme, and I am set! Thanks to the excellent WordPress app I have most of the features from Day One on my phone. In fact I think the only thing I lose out on is the automatic weather details.

Let us see how long I can maintain this habit for… 😀

Smartbrick

I love my smartphones, and I’ve been using them for a long time now. I think my first real smartphone was an O2 branded HTC Universal, followed by a Nokia N95. I’ve also had various models of iPhone (3G, 4, 4S, 5 and currently using a 6) and both a Nexus 4 and 5.

The common factor between all these devices was my choice of service provider: O2. I let myself get suckered into upgrade after upgrade to get the latest and greatest model, and always lived in hope of them improving network coverage in my neck of woods.

You see, I live in the middle of nowhere. We’re right on the limit for both getting ADSL and having pizza delivered, and our nearest neighbour is a quarter of a mile away. It’s a wonderful location, but not without its frustrations for a self-confessed lover of technology like myself. The problem is getting worse as my older children start to suck up more and more of our available bandwidth with Netflix, YouTube, and Xbox Live.

Coupled with the poor broadband connectivity is less than stellar coverage from O2. I can get 3G in Carlisle, but around where I actually spend 99% of my time I get GPRS or nothing. To add insult to injury, the GPRS connection rarely works for anything other than push notifications. This means that whenever I leave the house, unless I’m headed for “civilisation” I’m carrying the eponymous “smartbrick” in my pocket.

The christmas before last my brother-in-law was shocked and delighted to discover he could get a 32Mbps 4G signal from EE in my living room, compared to the paltry ~2Mbps my BT ADSL was providing to a house full of gadgets during a family christmas.

Being tied into a contract prevented me from switching to EE at the first opportunity, but as my contract is due to expire I’ve been checking out my options. EE with their 4G-in-my-living-room is a clear contender, but with my work at Automattic (by the way, we’re hiring!) I also have to travel several times a year – usually to the United States. Neither O2 nor EE have particularly great roaming prices there, and having had my fingers burnt with a few bills on my return from travels, I’m keen to get the best bang for my buck. Especially when roaming I rarely turn my data on – except in emergencies – so despite being in “civilisation” my phone remains a smartbrick unless I’m near a WiFi connection.

This lead to me Three. They have very reasonable pay-as-you-go bundles (I really want to be done with long term contracts), but most importantly they have a “feel at home” romaing deal which means I can use my full allowance in the US and other countries. A quick warning: the “all you can eat” data allowance in the UK is capped at 25GB when roaming. The cheek of it! Oh, and they have 3G-in-my-living-room, which is a massive improvement on O2.

So for my current trip to New Orleans for a team meetup (I’m typing this on the train to the airport in our excellent WordPress app, and using my Three 3G to post it) I’m trying out their “feel at home” deal and I’m looking forward to being able to use my smartphone as Apple intended!

A smartbrick no more!

I will never stop learning

Today – after seven-and-a-half years at Canonical – I have started work for Automattic.

What brought me here wasn’t the products – which are awesome – but the company itself.

The more I learned about my new colleagues and how they worked, the more I knew I wanted to – no, had to – work here.

The Automattic creed sums it up far better than I can:

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Our founder, Matt Mullenweg, introduced the creed in 2011.

Much is written on the hiring process, how we work, and the benefits of a distributed workforce. There’s even a book! I’ll be adding my voice to those over the coming months and years, but from everything I’ve seen so far, and everyone I’ve spoken to, those articles have only scratched the surface.

So if this sounds like the sort of place you’d like to work, come join us.

Documentation Driven Development

I’m by no means the first to propose this approach: I first heard the phrase “Readme Driven Development” from Tom Preston-Werner in 2010, and there he referenced Documentation Driven Development:

It’s important to distinguish Readme Driven Development from Documentation Driven Development. RDD could be considered a subset or limited version of DDD.

A quick google(v.) gives me various results for “documentation driven development”:

…and that’s just from the first page of results!

So lets be clear: I’m not claiming to have invented anything here; I’m just distilling the various sources into my own thoughts.

I recently got around to reading The Year Without Pants by Scott Berkun, which details his actually-more-than-a-year working for Automattic. When he was describing a general workflow for updating WordPress.com, this caught my attention:

Write a launch announcement and a support page. Most features are announced to the world after they go live on WordPress.com . But long before launch, a draft launch announcement is written. This sounds strange. How can you write an announcement for something that doesn’t exist? The point is that if you can’t imagine a compellingly simple explanation for customers, then you don’t really understand why the feature is worth building. Writing the announcement first is a forcing function. You’re forced to question if your idea is more exciting for you as the maker than it will be for your customer. If it is, rethink the idea or pick a different one.

This reminded me of Tom Preston-Werner’s approach, and set me thinking about the problem again.

A README file or launch announcement (or release note) are user facing, but users aren’t our only audience. If writing those things first help us distil our thoughts about what we are going to deliver to our users, then doing the same thing for our commit messages or – taking it to the extreme – comments will help us stay focused too. This can be particularly relevant when fixing bugs/issues/defects, as you will generally go into them with a clear idea of what you are going to do to address them.

Of course, just like TDD isn’t always practical – e.g., exploratory spikes – so too can DDD not always be used. Nor should your documentation be set in stone: good documentation lives and breathes alongside the code.