Between October 31,2015 and Sep 5, 2016
we wrote 80 blogs on changes in
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
pick the ones which are worth writing about
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 undertand 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
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.
Tell a story even if you have 10 seconds
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 itselfs 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
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.
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
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
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
So you see even a great John Lasseter had to be reminded to tell a
Actual content over bullet points
is so focused on knowing the full story that he banned usage
of power point in internal meetings and discussions. As per him it is
easy to hide behind bullet points in a power point 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.
Learning to tell story is a journey
I’m glad that during the last 310 days 16 people contributed to the
The process of writing the posts at times was frustrating for a bunch of
They had done the work of digging into the code and had posted their
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
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.