Sometimes, it can take you a long, long time to learn something new.

Sometimes, you set out to learn something new before you even know what that thing is.

Sometimes, what seemed like a finish line when you started turns out to just be a pit stop along the way when you get there.

I’ve been working in WordPress since December of 2004. That’s a LONG time when it comes to using technology, right? The first 2-3 years of that journey was just me using WordPress to blog — and teaching others how to use it to blog.

It was probably about three years into using WordPress that I actually started to wrestle with code in any fashion. My first forays into working with code were about customizing themes. At that point, we had launched UMW Blogs, and there were occasionally requests to do something that we couldn’t with an existing theme. So I started playing around with theme files, trying to understand exactly how they worked.

In retrospect, a lot of what I learned about WordPress over the years came about because I gave myself a project that required me to dig deeper. Often the projects were Web sites that our division needed built for some reason. The sites for our annual conference, Faculty Academy, for example were opportunities to push myself a bit further. I would spend A LOT of time tweaking and customizing those sites. And, at the time, it didn’t always feel like this was the best use of my time. After all, we could manage without the features I was trying to add, so why bother? But it felt, all along, like what I was doing was adding up to something.

And I think it’s fair to say that very often I would find a reason to use the things I had taught  myself through these experiments in “real” work. The next time a colleague came to us asking for help doing something a bit new or different in UMW Blogs, I might have a better idea as to how to make it happen.

After a few years mucking around in themes, I became better and better at understanding how the code worked. It now became possible for me to troubleshoot problems with existing themes or plugins. Occasionally, I would hack a plugin to make it do something a bit different.

Around 2009 I thought it would be cool to learn how to write a plugin from scratch. I did actually make a few, very basic, plugins for internal use in UMW Blogs or ds106. And I wrote a few basic plugins that were designed to extend/modify the behavior of other plugins we were using. But the goal of writing something from scratch that might actually be useful to someone else kept eluding me.

This spring, a couple of projects landed on my lap that have been particularly fun to work on. Both of them spring out of courses that involve students collecting and analyzing data. One of them is historical preservation data about properties in the city of Fredericksburg. The other is data about worms. On the surface, those seem pretty different, but under the hood, they’re basically the same. Using a couple of premium plugins that we’ve bought, I’ve been setting up sites that allowed students to input pretty rich data that is then displayed (and filtered) on the front-end. Essentially, WordPress becomes an engine for a mini-database app. In some ways it’s a bit Rube Goldber-esque (we can debate whether it makes sense to jury-rig WordPress to do these things, but, for now, I’ve got nothing better), but I’ve always been a fan of MouseTrap! And, most importantly, it allows us to address the needs of faculty and students that, previously, were impossible to address.

However (there’s always a “however”), there was one thing that these projects needed that our premium plugins couldn’t do — and there were no other, existing plugins that could do it just right, either. We needed an easy way to export all of that custom data that students were inputing into a CSV file, and we needed it in a particular format so that it could be shared and manipulated.

So, about six weeks ago, I set out to write a plugin to do that. And last week, I finally finished the first version.

There is absolutely nothing sexy about this plugin. Basically, it allows you to choose a post type (post, page, or other custom post type) and then select some custom fields associated with that post type. Then, you can export all of the values for those custom fields in a CSV file. Each field becomes a column; each post instance (and it’s associated values) becomes a row.

It was hard to do this. Probably much harder than it needed to be. In part that’s because my work in this area has been so haphazard and marked with so many stops and starts. (I swear re-learn the same things over and over and over again. . .)

But it was also an accomplishment that 9 years ago seemed like a ridiculous impossibility. And, along the way, most of the time it continued to feel that way.

None of this made ANY sense to me when I started. And then it started to make a LITTLE sense. And then it made enough sense that I could actually start to speak it a little. And then I made a plugin.

I think that it may have been the most profound learning experience of my life, but it was completely unstructured. I had no specific goals or milestones. There was no textbook or curriculum. I literally Googled myself into it.

And, to be clear, what I’ve created is MINUSCULE compared to what others have created. It is a tiny drop in a bucket. A few files and functions. That is all. But for me it has been huge, and it is only a small stop on a journey.

So, there you go.