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… 😀

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.

Distraction Free Writing

I’m a big fan of Markdown. I’m also a fan of WordPress. When the Jetpack extensions introduced Markdown editing I was mostly happy. Mostly, because as nice as the Add New Post screen is, it is still too noisy for long posts.

Adding a new post to WordPress

Adding a new post to WordPress

Previously I’ve resolved this by writing long posts in Draft, then publishing (or just cut’n’pasting) them here.

The other day, while revising my post on using Travis CI with Django projects, I finally clicked on the Toggle fullscreen mode icon at the top of the post editor, and I got one step closer to happiness. Compare and contrast the following screenshots:

Draft

Draft

WordPress full screen mode with Markdown

WordPress full screen mode with Markdown

Draft has got some amazing features – the quick preview is great – but my use of it has just decreased for updating this site. Sorry Nate!