Blogging - start from the middle

… and check why 5600+ Rails engineers read also this

Blogging - start from the middle

Time constraints seems to be the main reason for not blogging more often.

Today, I’d like to teach you a technique which reverses the situation - the blog post is created in your available time.

Start from the middle

I call this technique - “start from the middle”. The point is to start your post with the main message. Find the MVP of your blog post.

What’s the minimal content to write and still get the message through?

What’s the minimal thing you need to write to help your readers in the chosen topic?

Sometimes, it may be just 3-4 sentences. Sometimes it’s a picture with a short explanation. It can also be a piece of code. It can be just a list of points.


The point is to make it consistent and shippable. If I run out of time, I want to ship (publish) the post and still deliver value. It doesn’t need to be perfect. It probably won’t be.

This approach is not about being perfect. If you’re a perfectionists, you may have hard time applying it in practice.

Does it sound similar to what you’ve done before? The agile approach to coding is very similar. Release early, release often. Start with something minimal which works and then iteratively improve it.


The start from the middle technique works well in combination with timeboxing. Timeboxing is reversing the situation with lacking time for blogging. You start with the constraint - you only have N minutes to ship this blog post. You no longer have the problem of lacking time. You now have a different challenge - choosing the scope of the blog post.

That’s often what product owners, PMs and clients need to do when it comes to giving work to developers. They need to scope the feature so that it’s not too expensive cost-wise and time-wise. As a developer you’re usually presented with the scope and your job is to make it under the available time.

In case of blogging this means that you’re playing both roles. You are the product owner. You are the developer. Deal with it :)

What’s a good time constraint?

Depends on your availability. I experiment with 30 minutes, but I may have it easier, after writing > 100 blog posts. 60 minutes may be a good start.

As for perfectionism - this may be hard to some of you. Your blog post won’t be perfect. It’s similar to the features you sometimes ship. Product owners need to make such decisions - what to omit.

It’s your role now - decide what is the thing that you’re going to explain in the blog post as first. By this decision, you’re also deciding what’s not included - thanks to the time constraints.

Keeping it shippable is the key here. Even if you timebox the writing to 120 minutes, try to keep it shippable from the beginning. If you’re using a tool like nanoc (as I’m doing it now), then the post is in the repository. Commit often.


Keep your TODO list for the blog post. Prioritise the TODO items. Start from the top. If you have more time, just keep going with the tasks. What can be a blogging task? For this blog post, I wasn’t sure if I cover all the points, so I split them into points:

  • start from the middle
  • shippable
  • timeboxing
  • TODO
  • editing, typos, headers, bolds
  • screenshots of a blog post in progress
  • blog post header picture

As you see, I’ve managed to do almost all of them. I didn’t finish the last ones - dealing with screenshots and pictures takes more minutes and I put it at the end - no time available for that.

BTW, It’s an interesting situation. Now, when I present you the list of points, you see that this post is unfinished. What if I didn’t present the list to you? The thing is, as authors we know more than our readers. It’s only our mind that makes us think it’s unfinished - because we started with some bigger vision. Our readers usually don’t know the vision.

You might also like