The Software Scrutiny Journal

These last couple of months, I’ve been able to hold a steady blog release schedule. Three things have helped me release a steady stream of content. First, I am a part of a mastermind group that holds me accountable to making releases. Next, I keep a backlog of posts so that I don’t feel pressured to write, edit, and release on a single day. Finally, I follow a pipeline to iron out the kinks between stages of publishing. Maintaining these three habits guarantee a steady flow of content.

Masterminding

I highly recommend forming a mastermind group. Though I struggled to find a mastermind group for the last couple of years, it seems to have paid off. Around January, I stumbled upon a couple of co-workers looking for an accountability group, and thought this would be the perfect opportunity. We determined a structure for our meetings and have been meeting every two weeks. I am glad to call this group home.

If you are interested in joining one, try starting with siblings, extended family, coworkers, or friends. In the case that you are looking for a more serious group, you can buy into one for about $800/month. The expensive groups tend to be life coach groups and drive you to success ASAP. I am told that they are worth what they are priced at. However since I am just looking to release content on my blog, I’ve found a co-worker mastermind group to work very well! It is also fitting since the content I write can be applied by my fellow co-workers. After meeting, I get a boost of motivation to fill the post backlog.

Backlogs

Keeping a backlog of posts is cruicial to maintaining momentum. This backlog is split between my vimwiki and my git repository. Initial topics, paragraphs, and miscellaneous thoughts are dumped into the vimwiki. The content moves to the repository once the idea has enough content for publication. Albeit, the content is still in rough condition and requires a couple editing sessions. I try to keep between 2-4 drafts queued in my git repository. I also try to always have ideas in my vimwiki – keeping friction low when I am in a drafting mood.

I define “the pipeline” as the separation todos or activities into atomic categories. Some days I feel like drafting. Other days I just want to appreciate my work and make tweaks through revising. When I am feeling lazy, I would rather just hit the publish button and call it a day. By having each mood associated with an activity, I can be steadfast on regular content delivery.

I don’t spend hours a day on content development either. On a typical day, I can spend between 10-40 minutes on any of the above activities. The best time I find for writing is at the end of my workday right before dinner. Also before bed and on the weekends too.

From Start to Finish

So what does the pipeline aspect look like from start to finish? We start with the spark of an idea. This will occur while I am working on a bit of code, or even while I am out and about. Either way, I immediately get this idea into my vimwiki either through vim or via smartphone. If I am at my computer and feeling motivated, I will write a couple of sentences to get the juices flowing.

The next stage is drafting. The draft begins to manifest itself in the vimwiki. I type whatever thoughts come into my mind – knowing that not everything will make it to publication. My vimwiki has a bunch of half-completed blog posts. I tend to draft for whatever I feel like talking about.

Vim most definitely helps me produce content quicker. I draft in Vim by writing each sentence on its own line. This makes the reordering of sentences and paragraphs super easy with dd and p. It also helps create cleaner git diffs. Additionally I’ve configured the editor to enforce an 80 character line-wrap. This helps encourage short and concise sentences. For example, this paragraph looks like the following in my editor:

Vim most definitely helps me produce content quicker.
I draft in Vim by writing each sentence on its own line.
This makes the reordering of sentences and paragraphs super easy with `dd` and `p`.
It also helps create cleaner git diffs.
Additionally I've configured the editor to enforce an 80 character line-wrap.
This helps encourage short and concise sentences.
For example, this paragraph looks like the following in my editor:

When the amount of content gets to be sizable, I will move the content over to its individual post. When moved, the post gets assigned a permalink in jekyll as well as a description. The filename of the post contains the release date that I will be aiming for. At this point, the post is put in the queue for publishing even though it is not completed yet. And don’t worry, I still use vim while inside this post file. The quick navigation aids in revising.

While revising, I boot up the website locally. I will peruse through the posts that are queued for deployment. I am able to view these from homepage by using the --future jekyll flag. Reading the post in the browser seems to help the revision process since I get to see what a fully-published article will look like. I make changes as needed to make my thoughts more concise.

Finally, when it is time to deploy, it is as simple as running make deploy. Jekyll builds and detects that the post is no longer in the future. The deploy script also runs rsync to upload the build to my Digital Ocean droplet.