Why I Didn’t Post For A Long Time

If you look at the posting dates, you’ll see that there was about a two year gap previous to these last few posts. The reason I didn’t post was plain and simple aporia. No, I’m not going to link to Wikipedia. Yes, it is a fancy Greek philosophical word, meaning at its root “no way to go” and referring, in short, to a state of mental paralysis — importantly, though, an overly-informed and self-aware state of mental paralysis. And that’s exactly what happened to me: as someone working in the digital media industry, I knew way too much about clean code and web standards and development methods and social media, and most painfully, why I wasn’t (and possibly couldn’t) follow any of the best practices relating to these things.

When I started this blog, it was a way for me to write; at first I just used WordPress.com quite happily. As I learned to code, I fell victim to the first stage of developer hubris, better known as “build it yourself” syndrome. I wanted to build my own WordPress theme, dammit, and use my own colors, and display posts entirely in my own way, using my own taxonomy.

Now, on the one hand, this was totally understandable. I was relishing the challenge of learning about templates and functions and how to build things correctly and how to design stuff and even how to deploy app stuff with databases. Neat!

But of course, with great power comes great responsibility. I had decided that my second career was going to be as a designer/developer, and my blog was a big, messy workshop to try things without affecting any clients I was working for.

As I learned more, it became apparent to me that I was more interested in the development side than the design side. And when I got a full-time job with a digital publication, I learned so much about how to build things correctly, and how to scale. Or rather, how not to build things, if you want to scale. About how to use defaults and libraries and plugins and even third party services that don’t require you to pay attention to them all the time.

I also learned, gradually, that categories are categories are categories. Which is to say that no one has come up with some new, exciting method of classifying content that doesn’t rely on, basically, categories and tags of various sorts. And I learned that the problem of how to contextualize any given piece of writing is damned hard — so hard, in fact, that probably no one is going to solve definitively.

All of this is to say that I started to realize how many things WordPress’s defaults had gotten right. I realized that the existing category/tag system was really great, and that it was quite a relief to use a theme that was going to just become responsive for you, or a system that was keeping up with API-driven development already — hell, our very own work system didn’t do this yet.

So at some point I just switched the theme back to a default that looked nice and loaded well. And that was a relief.

But there was still more to be confused about, as someone who codes: development and deployment. For non-coders, deployment just means “putting your site online somehow”. To a software engineer, what’s important is that there’s a repeatable system for putting your stuff online, quickly and repeatably. So, for example, if you’ve made a change to your website, ideally, you should be able to make the code for it live with a single command in your terminal. And while we’re at it, your development version — i.e. the version of your website you run on your laptop while working on it — should a copy of your real database, so that everything’s the same.

And of course I hadn’t set any of this up for my own site initially, because I hadn’t known about all of that when I started. So I was filled with developer-guilt about how I should be doing these things. And then came more options: now you can use Docker! (Non-tech people: just don’t ask, it’s like Inception for websites.) And now there are code hooks to deploy your code directly from where it lives! So many things to do, and so many things that I didn’t really want to deal with in my free time, given that I dealt with them all day at my job. Oh, and of course you should back up your site regularly. Obviously.

I still haven’t dealt with any of that beyond backups, which are always a good idea for everything.

And even the actual material I’m writing and posting, knowing best practices makes it difficult to even think about the grand arrogance of putting something up on the web and expecting people to look at it. Because you should have art in your post, mostly because when you post it to Facebook and Twitter you’ll need that art to be sucked in via meta tags, because people are far more likely to click on something that has art. All of this assumes, of course, that your goal is to get a lot of people to read your stuff — and OMG, in that vein, shouldn’t you be cross-posting on Medium, or maybe just giving up on personal blogs and using Medium for everything? And by the way, don’t forget to cross-link within your posts, because that’s also important, because people’s attention spans are limited and their loyalty is thin.

And oh jeez, what about my web presence? I have my name as a domain name, but it’s easier to maintain my actual webpage as a Github page, but I also like the name of this blog. If I were really on the ball, I’d have all my web presences sort of centralized, so it wouldn’t drive me nuts! And I’m a woman on the internet, so how much of a web presence do I want, really?

Oh, well.

You know what I’ve really learned? That there’s a reason you have multiple people working on digital publications. That it’s far better to have a really good design person making the art for your posts, and that full-stack development has become so complicated, that really no one should expect to be able to cover every part of it, and that social media is really, truly its own time-consuming job that it’s worth paying people for.

But on the other hand, I’m loathe to give up my own site. I like having my own material in my own database, even if it’s a pain in the ass to deal with a database. (Oh, yeah, that’s another thing: static sites — which don’t use a database — are all the rage. But I’d rather use the RSS from this site to power something, if we’re going to go in that direction.)

And a bunch of best practices are things I don’t want to do: newsletters popups, (ugh) and ads and analytics (no way, I hate tracking),  and writing Markdown, (nope nope nope, don’t even get me started on that one).

Here’s something I am going do to: publish some of the posts that I started and never published. Because, here’s the thing: I was writing the whole time. I just wasn’t publishing. Because at the beginning, I shared the common delusion that hitting the publish button meant everyone in the world would see what I’d written.

But that’s another thing I’ve learned: with the sheer amount of stuff on the web, hitting publish means next to nothing.* So I’ll start hitting publish with impunity, and I’ll see if I feel like adding pictures or socializing or doing of that other stuff. And return to the original purpose of this blog, which was to have a place to write.

Motivation follows action. That is the only way out of aporia.

*Unless you have a large audience already and say something offensive/stupid/etc.