Growing Wild

In January 2015 I set a new years resolution to finish my album in 2015.

I started writing the songs for this album when we moved to the little house by the woods back in 2010. I wrote these songs walking in the woods and fields, and in central London where I was working. Many of the songs were recorded in the shed, complete with woodburning stove:

As always life got in the way, we moved from our little house in 2013 and the songs sat unloved for a few years. This year I wanted to set them free. I had hoped to have more time to polish them, but the deadline is 2015. There were also sadly a number of songs that didn’t make it. In the spirit of “done is better than perfect”, my “new” album, Growing Wild is now available on Bandcamp.


I say “I”, but Rebekah wrote one of the songs.

The new

I am writing this blog post using a desktop app.

For the last year and some, I have been working on a secret project at Automattic. Today this project was released Open Source for the whole world to see.

This has been a fascinating experience; this project has changed a lot of things about the way we work at Automattic. Many of the changes have been technical; this was my first project using Node and React for example. However for me the biggest change is not the technology but the process.

Code reviews

Historically we have had no formal code review process at Automattic; while it did happen it was sporadic, unsystematic, and almost always after the fact.

With this project we approached the process differently. Using GitHub we were able to open pull requests against the codebase in way which made it easy to share code between developers, designers, testers and other team members before it was in production. GitHub’s inteface makes it really easy to comment on specific lines of code and suggest a better approach. We made it a habit to always have at least one other person else give your pull request a “+1” before it was merged. Merging your own pull request is like giving yourself a high five.

This was scary at first; now my code was going to be seen by more people; “what if it’s not very good?”! It was also frustrating. Going from a system where you can make changes to the code instantly, to having to have someone else sign off on it does slow down the pace of development.

In return for this there some real benefits. I learnt a huge amount from the developers, designers and testers who reviewed my code. Often my code had problems; knowing this before I commited the code to the repo was a huge improvement, since now problems could be caught and improvements made.

We all learnt a lot through this process; we learnt how to review the code not review the coder; we learnt that critisism of your code is not critisism of you and should not be taken personally.

The result of this is a codebase of much improved quality, maintainability and consistency. Another benefit is the opportunity I have had to improve my coding skills. By talking to more people about my code, and also reviewing other developers code, I have learnt a lot more about what clean, maintainable code looks like.


With this project the way we worked was different by necessity. While GitHub helped us to collaborate more closly on projects and as a whole, than we had before, at its root the change was a cultural one.

Because we are encouraged to review code in areas that we have not worked on, this has lead to a more wholistic approach to solving problems. The work that went into major decisions like defining navigation and information architechture was always a cross-team effort.

This increase in cross team communication has improved has made us much more closely aligned in our vision of the product. I believe this is evident in the consistency you see throughout the new


My experience at Automattic up to this point was generally one of working on a project on my own, up to the point where it was ready to be launched internally. This was partly a cultural thing, parly due to smaller sized teams and partly because collaboration was harder given the tools at our disposal.

I went from working on my own on a feature, to working closely with a group of 2/3 developers, and more broadly with all of the developers working on this new project.

By working on a feature with a team there is a lot more opportunity for us to use our respective skills to improve feature. A good team is more than the sum of its parts; as each member contributes in their specialty.

Having people who specialise in each of these areas to focus on these aspects of the product at the same time, and while the code was being actively worked on shortened the feedback loop in the development cycle, meaning that issues were caught early. Thus false assumptions were picked up before they became entrenched in code, and inconsistencies were ironed out before they became too difficult to change.

By increasing the level of communication around all of the decisions that go into building a project like this, whether its user experience, coding standards or business requirements, the result is that each of these areas receieves the attention it deserves at the point when the feedback is most useful.

Practically speaking this means that whereas before I would have probably committed code with a sub-par user experience, bad architectural designs, poor syntax, or (and!) sloppy designs, now the collaboration between the different members of the team lead to a product that is improved in all of these areas.

I have found this feedback to be really valuable, both in helping me to understand the things I need to work on to improve as a developer, and in reassuring me that I am making a valuable contribution to the project. As someone who loves making things this is very useful.

All of this communication also helps create a team who have a more closely aligned vision of what they are trying to build together and are pulling in the same direction

Open source

The latest change in the way that we work has been to make the project Open Source. This has meant making some changes to the way we work. We have to be careful not to share any private or personal information in our public repo, and have to consider how developers outside Automattic understand our code and issues.

This is a change we are still working out; I am interested to see what changes it brings to the way we work.

More info

Download the Mac desktop app
Learn about Calypso from the developer’s point of view
See the user announcement on
Browse the GitHub repository
Hear about the backstory from Calypso’s lead, Andy Peatling
Matt Mullenweg’s announcement

Another riddle

This riddle was written by Rebekah for my birthday:

If you feel lonely give me a squeeze,
I’ll do my best not to respond with a wheeze.
My keys cannot open any door,
But stand on a street and we won’t be poor.
Push my buttons but don’t wind me up,
Bystanders will put money in your cup.
Not just on the street, play me at home,
In field and in forest, wherever you roam.


I can be sown but not with thread
I’m only useful when I’m dead

I have many ears but can’t hear
I have hair but only on my ears

When I’m old you cut off my head
And grind my ears to make your bread

I don’t have legs yet still I stand
And though I wave I have no hands

Fort Boyard


Between two small “islands” in the Pertuis d’Antioche straits on the west coast of France stands Fort Boyard. It serves as a constant reminder of the futility of human endeavour.

The necessity for a fort in this location was obvious to the French military as far back as 1661. The limited range of cannons meant that English ships could pass unchallenged down the channel, and threaten invasion of the French mainland. By putting a fort in this location the French would cut off this route and secure the French defences.

For a long time the fort was considered to be too expensive:

Your Majesty, it would be easier to seize the moon with your teeth than to attempt such an undertaking in such a place”. – Vauban, Louis XIV’s leading military engineer

However by 1800 Napoleon judged that this was a project worth undertaking and work began in 1801. The work was suspended in 1809, and not resumed until 1837, by King Louis-Philippe. By the time it was completed in 1857, both Napoleon and Louis-Philippe were dead.

Unfortunately, by 1857, technological advances in the range of cannons had increased significantly. When it was finally complete, this fortress, which took 28 years to build, was already obsolete. After a brief spell as a military prison it was abandoned to the sea.

The fortress still stands on the sand bank between Île-d’Aix and the Île d’Oléron, crumbling away with the tides. There are several lessons we can take from this story:

Flexible solutions

The need for fortifications in this area was based on:

  •  The short range of cannons
  •  The threat of English invasion from the sea

The proposed solution to this problem was obviously costly in both time and money; a whole town was built to support the workers. However this was not the only solution available to the French. There were other options they could have considered:

  •  Invest in research into longer range cannons
  • Invest in other defence mechanisms which could be effective in this area.

The advantage of these options over the fortress would have been that they would provide value in other locations as well; the fortress was only of value in the one area in which it was built. A search for a more flexible solution may have resulted in improved defences against land based attacks like the French experienced 100 years later, as well as attacks from the sea.

Cut your losses

Even if the French considered that a longer range cannon was not possible when the fortress was begun in 1801, but they time it was completed in 1857 it was a reality. At some point it must have been clear that the advances in cannon ranges were making progress and the fortress would not have brought the value that was originally planned. Why wasn’t the fortress abandoned at this point?

Future proofing

The concept of the fortress was always to make up for a short-coming in cannon ranges. Any project that aims to solve problems caused by a shortfall in another technology is at risk of becoming obsolete when these problems are solved (Twitter API clients anyone?).

Big projects

Fort Boyard took 56 years from start to end; half these were spent building; the other half on hold. Looking at the design of the fortress it is clear that part of the reason for this timescale is that this is a large fortress with sufficient room for a garrison of 250 men. Given that the primary aim of the fortress was to provide a platform to improve artillery cover, the size of the fortress is surprising . Why wasn’t a simple platform built first, for a few cannons and a small shelter as cover for a few men to loaded them (well maybe it was, I’m no historian). A smaller project like this may have been completed in a much shorter timescale and would have improved artillery cover for a period of time when that would have been valuable. Perhaps the project became over-scoped which explains why it wasn’t completed in a timely enough manner to be useful. The same lessons apply when building other things; start small, think about a minimum viable project, ship as soon as possible.


It could be argued that the real problem demonstrated by Fort Boyard is the lack of a goal oriented vision. Were the French so focussed on this one solution to their problem that they overlooked other opportunities they could be investing in? When building anything it is vital to have a clear vision of what your goal is; in this case the goal should not have been to build a fortress, it should have been to defend against invasion. If the focus was on this goal then the fortress would never have been completed. In the same way, when building anything we need to focus on what the end goal is; not just the next iteration of our current {thing}. Without a goal oriented vision we risk building an improved version of something which is soon to become obsolete.


  • Have a goal oriented vision
  • Anticipate technological shifts
  • Avoid big projects
  • Avoid investing in stop-gap solutions
  • Cut your losses – don’t be afraid to dump a project and refocus when necessary

Disclaimer: I am not a historian. this is an over-implication of complex historical events. Please do your own research.