September 19, 2016
Between October 31,2015 and Sep 5, 2016 we wrote 80 blogs on changes in Rails 5.
Producing a blog every 4 days consistently over 310 days takes persistence and time - lots of it.
We needed to go through all the commits and then pick the ones which are worth writing about and then write about it. Going into this I knew it would be a hard task. Ruby on Rails is now a well crafted machine. In order to fully understand what's going on in the code base we need to spend sufficient time on it.
However I was surprised by the thing that turned to be the hardest - telling story of the code change.
Every commit has a story. There is a reason for it. The commit itself might be minor but that code change in itself does not tell the full story.
For example take this commit. This commit is so simple that you might think it is not worth writing about. However in order to fully understand what it does we need to tell the full story which was captured in this blog.
Or take the case of Rails 5 officially supports MariaDB . The blog captures the full story and not just the code that changed.
Now you might say that I have cherry picked blog posts that favor my case. So let's pick a blog which is simple.
You might wonder what could go wrong with a blog like this. As it turns out, plenty. That's because writing a blog also requires defining the boundary of the blog. Deciding what to include and what to leave out is hard. One gets a feel for it only after writing it. And after having typed the words on screen, pruning is hard.
A good written article is simple writing. The problem with article which are simple to readers is that - well it is simple. So it feels to readers that writing it must be simple. Nothing can be further from the truth. It takes a lot of hard work to produce anything simple. It's true in writing. And it's true in producing software.
Coming back to the "Skipping Mailer" blog, it took quite a bit of back and forth to bring the blog to its essence. So yes the final output is quite short but that does not mean that it took short amount of time to produce it.
John Lasseter was working as an animator at Disney in 1984. He was just fired from Disney for promoting computer animations at Disney. Lasseter joins Lucasfilm. Lucasfilm renamed itself to Pixar Graphics Group and sold itself to Steve Jobs for $5 million.
Lasseter was tasked with producing a short film that would show the power of what computer animations could do so that Pixar Graphics Group can get some projects like producing TV commercials with cartoon characters and earn some money. Lasseter needed to produce a short film for the upcoming computer graphics animation conference.
His initial idea was to have a short movie having a plotless character. He presented this idea to a conference in Brussels. There Belgian animator Raoul Servais commented in slightly harsh tone that
No matter how short it is, it should have a beginning, a middle, and an end. Don't forget the story.
Lasseter complained that it's a pretty short movie and there might not be time to present a story.
Raoul Servais replied
You can tell a story in ten seconds.
Lasseter started developing a character. He came up with the idea of Luxo Jr.
Here is final production of Luxo Jr.
Luxo Jr. was a major hit at the conference. Crowd was on its feet in applause even before the two minutes film was over. Remember this is 1986 and Computer Animation was not much advanced at that time and this was the first movie ever made with the use of just computer graphics.
Lasseter later said that when audience was watching the movie they forgot that they were watching a computer animated film because the story took over them. He learned the lesson that technology should enable better story telling and technology in itself divorced from story telling would not advance the cause of Pixar.
Later John Lasseter went on to produce hits like Toy Story, A bug's life, Toy Story 2, Cars, Cars 2, Monsters Inc, Finding Nemo and many more.
So you see even a great John Lasseter had to be reminded to tell a story.
Jeff Bezos is so focused on knowing the full story that he banned usage of PowerPoint in internal meetings and discussions. As per him it is easy to hide behind bullet points in a PowerPoint presentation.
He insisted on writing the full story in word document and distribute it to meeting attendees. The meetings starts with everyone head down reading the document.
He is also known for saying that if we are building a feature then we first need to know how it would be presented to the consumers when it is unveiled. We need to know the story we are going to tell them. Without the story we won't have full picture of what we are going to build.
I'm glad that during the last 310 days 16 people contributed to the blog posts. The process of writing the posts at times was frustrating for a bunch of them. They had done the work of digging into the code and had posted their findings. Continuously getting feedback to edit the blog to build a nice coherent story where each paragraph is an extension of the previous paragraph is a downer. Some were dismayed at why we are spending so much energy on a technical blog.
However in the end we all are happy that we underwent this exercise. We could see the initial draft of the blog and the final version and we all could see the difference.
By no means we have mastered the art of storytelling. It's a long journey. However we believe we are on the right path. Hopefully in coming months and years we at BigBinary would be able to bring to you more stories from changes in Rails and other places.
If this blog was helpful, check out our full blog archive.