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.

Collaboration

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 WordPress.com

Feedback

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 WordPress.com
Browse the GitHub repository
Hear about the backstory from Calypso’s lead, Andy Peatling
Matt Mullenweg’s announcement