30 days of blogging summary

Sorry, your browser does not support SVG.

I did it.

Every year I say I'm going to blog more and I never do. This was the kick up the butt that get me going.

Here's a table with some numbers in it:

Total word count 13,118
Unique visitors 6,626

I wrote more words in 30 days than in the entirety of 2019. Daily traffic increased by around 10%, although I don't sell ads so visitor counts are mostly for vanity.

The three most popular articles were:

  1. Writing a Leanpub book with Emacs
  2. My nineties development setup
  3. Eight years of Beeminder

All three of these got picked up by different places: my Leanpub post ended up on irreal.org (which spread it to other places), the post about my dev setup got retweeted by some large Atari accounts, and my post about Beeminder was retweeted by the official Beeminder account.

Getting linked to by other places was a nice surprise, but there were some other effects that I never expected:

  • I got some stickers and a wonderful hand-written note from the team at Beeminder.
  • Two very, very old "games" that I wrote for the Atari ST ended up on AtariMania (Shining Online and Sonic's Adventure).
  • Stranger still, petsasjim1 on YouTube posted some gameplay videos of both games.

Seeing somebody demoing games I wrote when I was a teenager was not something I ever expected. I can't say I enjoyed watching - it's a bit like someone critiquing art I drew in primary school - but it has given me the motivation to make something that's actually worth playing.

Thoughts on the experience

  • At the start I would write articles the day before they were due to be published, but as time went on this slipped. A few got published quite late in the evening on the day they were due.
  • Writing a day in advance was more relaxing, and I could afford to throw out a few ideas before settling on what was published.
  • Having a Beeminder goal to bill me when I miss a post without mercy worked really well. I don't think this goal would have been as effective if I'd configured it to include a week off when I derail.
  • The longer my posting streak went on, the more I was motivated to keep it going.
  • Giving myself a deadline encouraged me to publish some articles that I probably would have left otherwise.
  • I'm not 100% happy with everything that I wrote. Some posts were a little scrappy and would have benefited from an extra day or two of time.
  • Keeping notes in an easily accessible place came in handy when I needed some inspiration.
  • Posting links on Twitter generated some interest, but I don't like just linking to my own content. I think to really get more out of the platform I'd need to put time into building an audience and sharing shorter bits of content throughout the day/week.
  • Articles about my workflow were much more popular than my introspective writing (which I expected).

Overall I enjoyed the experiment. Regular writing was quite enjoyable - if challenging at times - and now that it's over I want to make some changes to my blogging routine. I don't plan on publishing every day, but a few times a week might be the sweet spot for me.


Finding fun in forty-eight hours

Ten years ago I entered my first game jam. I made my first ever Flash game, "Monster Mash", which involved running around a small RPG map and smashing into enemies. It wasn't particularly good, but it was playable. The whole game was created and released in under 48 hours.

Since then I've entered a number of game jams. Some went well (Splodey Boats) and some did not (Ludum Dare #27). I also tried One Game a Month for a few years; although they didn't go quite as well as weekend jams, I was still able to release a couple of fun games.

How many games have I made recently outside of game jams? Zero.

I've written plenty of boilerplate code, and I have prototypes in various stages of completion, but I haven't released anything playable in years.

The great thing about game jams is that they force me to focus on just a few things. If I have to find fun in a short space of time, I have to make decisions quickly. They might not always be the best decisions, but they stop me from getting distracted in all the side-alleys of development. Parkinson's law tends to attack most projects I work on, but when time is limited I have to throw out everything that doesn't contribute to making a playable game.

Would these games be better with extra time to polish? Of course they would! But the important part is they're actually done and playable. In the eyes of the universe, a game I work on for years and never release is exactly the same as something I never created at all.

I've written about a lot of different subjects during my 30 days of blogging trial, but one thread seems to keep coming up: there are lots of things I want to do, but I'm not very good at making the time to actually do them.

Forcing myself to create something in a short space of time seems to be the most effective way to get things done. I don't think it would be sustainable on a regular basis, but regular(ish) jams may be the best way to get some of these projects out of my brain and into reality.

I'm still thinking about how this would work for different kinds of projects, but I think next year's GHD goals will look a little different.


Sharpening the saw

Steven Covey's "The 7 Habits of Highly Successful People" is one of my favourite self-improvement books. It's full of great advice, but the habit of "sharpening the saw" is particularly powerful.

Sharpen the Saw means preserving and enhancing the greatest asset you have – you. It means having a balanced program for self-renewal in the four areas of your life: physical, social/emotional, mental, and spiritual.

Habit 7: Sharpen the Saw

There's a lot of overlap between this and reducing toil. The main difference for me is that sharpening the saw is about learning and improving skills, whereas reducing toil is about automating and eliminating certain types of work.

Looking at my own routines, I've made some improvements over the years:

A few areas I would like to improve:

There are a lot of areas where I'd like to improve. I'm pretty comfortable with the habit of weekly reviews for my GTD list, but I don't have any regular review system for my own processes. I've thought about using a structured approach like kaizen, but it might be overkill for this kind of situation.

I think the first step for me will be to set aside some time to take a full inventory of all my workflows, responsibilities, and routines. It's not very exciting, but I've been so focused on doing things that I haven't really taken the time to step back and examine where I could be doing it better (or if I need to be doing it at all).


Making time

I'm hardly the first person to notice the term "making time" isn't accurate. There are 24 hours in a day, and that can't be changed no matter how much you try.

How to use that time is the tricky part. There are so many different things fighting to get a piece of that time. Right now I've got a pretty big mix of activities on my plate:

  • Tasks that I have to do for other people. Some of these have hard deadlines, others do not. I get paid to do these.
  • Clerical work. Writing/replying to emails, processing my inbox and my next actions list, checking all of my projects are up to date, creating a schedule, and managing financial records all fit in here.
  • Things that need to be done to keep me functioning. Eating, drinking, sleeping, hygiene maintenance.
  • Exercising. I do running and bodyweight exercises on alternating days, with Sunday designated as a rest day.
  • Housework. This in includes cooking, cleaning, doing laundry (and putting it away), and walking the dog.
  • Recreation. Reading, writing, creating software, and a million other projects that I want to do but probably never will.
  • Time wasting. I don't plan this, but it tends to fill in the cracks between other activities.

These don't just take time, but energy as well. And like time, I can only spend so much energy without getting tired.

I've talked about measuring productivity; a big challenge for me is spending less time on low value activities. What counts as "value" is different for everyone, but for I want to change a couple of things:

  • Spend less time on work – This one is tricky as it keeps a roof over my head and food on my plate. But I definitely want to re-balance my days so that work isn't always the primary focus.
  • Spend more time on personal projects – There are lots of things I want to do, but it's really not possible for me to do them all. The last couple of years I've set myself GHD goals to try and focus myself, but I still struggle to complete the things on the list (and my list doesn't always contain things I actually want to do). I will probably tweak this approach for 2021.
  • Waste less time – It's really easy to lose a lot of time to mindlessly browsing the web. It doesn't always happen in one go, but each 5 minute break quickly adds up. I'd like to replace this with low energy activities that I can do instead.

I'm not trying to be productive every single minute of the day - I don't think that's a particularly healthy way to live - but I want to spend more time finishing projects instead of just daydreaming about them.


Limiting goaccess reports to a date range

A few days ago I wrote about filtering referer spam from my server logs before they're processed by goaccess. goaccess doesn't support log filtering out of the box, but tools like grep or sed can be used to filter the log before it's processed by goaccess.

There are two main reports I use for this blog: today's log, and the last 30 days of activity.

Viewing today's log

This is nice and simple. It searches the log for entries that have today's date string, and the results are then piped to goaccess.

grep "$(date '+%d\/%b\/%Y' -d 'today')" path/to/access_log \
    | goaccess -a

This can also be adapted to show log entries for a specific month (or year). I use this when generating monthly reports on how "Writing PHP with Emacs" is performing:

grep 'Nov/2020' path/to/access_log \
    | grep "books/php-with-emacs" \
    | goaccess -a

Note: This could also be done in a single pass using grep's -e syntax, but I find this version more readable.

Viewing this month's log

This one is a little trickier as we need to filter out everything before a specific date. Thankfully sed can do this:

sed -n '/'$(date '+%d\/%b\/%Y' -d '1 month ago')'/,$ p' path/to/access_log \
    | goaccess -a

There are a couple of parts here:

-n
This flag tells sed to hide its output. Normally it will display every line that is processed, which in this case would output the entire log file.
$(date '+%d\/%b\/%Y' -d '1 month ago')
This is evaluated and replaced by a timestamp for 1 month ago.
'/'$(date '+%d\/%b\/%Y' -d '1 month ago')'/,$ p'
This is the expression that sed will evaluate, which searches all entries that match a specific range. The , symbol is the range delimiter, and $ is the end of the range (which in this case is any date after the start date).
p
This final modifier tells sed to output lines that matched.

All together this filters log entries to the last 30 days before goaccess processes them. The date command is pretty flexible so this approach can filter entries to the current week, quarter, or any other range.