Building a Blog

A few months ago, after purchasing a Nikon D7000 DSLR camera, I decided I should really get serious about maintaining a blog on which to not only showcase my photography, but also to showcase myself, as a photographer, a developer and as a person. I want a “portfolio of me”; something a potential client or employer could look at that would represent who I am and what I can do.

I have started and abandoned blogs in the past, and have generally lost interest shortly after getting the blog up and running, making it look and feel like something I like, and making a few posts. But this time had to be different.## Why did I fail before? My first step was to figure out why I abandoned blogs in the past. I’ve tried a personal blog, a professional blog, Tumblr, Posterous, WordPress… the lot.

There are plenty of features I like in those services, which is why I’ve tried them all. After thinking about it, though, I realized that none of those services worked the way I wanted to work. They didn’t fit into my workflow, they required that I adopt their workflow.

For example, I like being able to edit my posts in a very light, desktop editor, like MarsEdit, or even TextMate and I want to write my posts in a structured, semantic language without regard for display (such as Markdown).

Photos present another large problem for me. Perhaps I am overly critical, but I haven’t found much to like about most photo services like Flickr, Facebook, Picasa, or so on. I want more control, both over the display of my photos and over the management of them once uploaded.

Of all the services I have tried, WordPress comes the closest to being everything I want. It already does most of what I want, built in, and what it doesn’t do, it’s open source enough to easily extend. Except I don’t want to work in PHP.

So what am I going to do?

Being a web developer, and since this blog is supposed to showcase my ability as a developer, it seemed the only reasonable course of action was to build my own blog engine.

Yes, yes, yes… blog engines are a dime-a-dozen. And I could pull components off the shelf and work them in. But something about that approach didn’t feel right. I had no desire to waste countless nights debugging code I didn’t write, trying to hack it into doing something it didn’t do. By starting from scratch, I would control the entire application stack, down to every last feature.

Speaking of features, that was and still is a major hurdle. There are so many features in popular blog applications… how could I possibly implement them all?

Focus is a hard thing to keep

I settled in to begin building my blog, and after working on just the basic functionality here and there on evenings and weekends for months, I realized I had lost focus. I had missed the point. I hadn’t posted anything. What’s the point of building a blog if you don’t fill it with content?

On more than one occasion while working on this project, I seriously considered abandoning the DIY approach and returning to an off-the-shelf stack, just so I could focus on writing posts, not code. In fact, I recently bumped my custom rails application to a sub-domain and installed WordPress at the primary domain, thinking I would blog about building the Rails application while building it.

But after rediscovering why I don’t like WordPress, I quickly realized this was a mistake and will soon be reverting the Rails blog engine to the primary domain. The WordPress blog will probably fall off and die somewhere…

Let’s just… just… just write!

Swapping in a WordPress blog may have been a mistake, but it did teach me one good lesson: content is king. And even if my blog doesn’t have all the features I want, the only way I’ll know what feature is the most important to add next is to use the blog while I build it. It’ll be a great opportunity to document the development of a big application!

For right now (unless I’ve forgotten to edit this post), the whole site is still in WordPress… and it’s not terrible, and/but it’s not bursting with rainbows and unicorns either.

I’m grind through it with WordPress for two reasons: first, it gives me an outlet for writing stuff immediately, and second, it will help me better identify what features my own blogging engine must have, should have, and probably won’t ever have.


I’d like to tip a hat to Allan Odgaard, developer of TextMate, for his thoughts on Textmate 2.0.

To realize this I felt it was necessary to start from scratch, and it has involved a lot of experimentation, rewriting, and it is why I didn’t feel like discussing progress in the open because I had no idea about how many of my ambitions would pan out. The program itself has been in a constant state of flux with essential stuff missing because my focus has initially been on all the stuff I didn’t know how to do, as I could always do the “easy” stuff later (and doing the easy stuff first just leads to rewriting it when new insights are gained).

I couldn’t agree with him more. The biggest gain for me in developing my own blog engine versus one off-the-shelf is practical experience and experimentation. If I hacked together some pre-fab solution, I’d have very little understanding about how those pieces worked. Requiring that my product work exactly to specification, though, forces me to evaluate every gem, bundle, or plugin with a much more critical eye.

Kyle Wilson’s essay, Software is Hard, is another great article I’d like to refer you to. It offers some interesting points and retrospective on the software development world. The essay is still quite valid, despite being four years old, and I encourage you to read it.

Leave a Reply

Your email address will not be published. Required fields are marked *