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.

What I Learned From My First Content Conference

I went to Confab Central last week and had a blast. After years of going to tech and news tech conferences, it was my first ever content conference, so I thought I’d make a list of what I learned.

All the Content Ladies

I don’t know what the official numbers are, but women were definitely the majority at the conference. The lines for the women’s bathrooms were literally out the door, and my small group dinner on Wednesday was 1 guy and 7 women.

This was kind of a nice change from code conferences.

Plentiful Food Helps

This was the first conference that served enough coffee. And we were served two square meals a day, plus really generous snacks. And cake. And cinnamon rolls. No one was every going to be hangry at this conference, and I can’t help but think this helps with networking.

And I loved the small group dinner arrangements.  Confab arranged these using Eventbrite: they’d made group reservations at some local great restaurants, and you could buy a ticket for a place at the table with one of the groups.  The idea being that to get to know people in such a large group was hard and this was a nice way to get a little deeper than small talk between panels. I got to go to a stellar restaurant and meet 7 new, interesting people in a really non-awkward way.

CS Means Two Things

At this conference, “CS” meant content strategy. I was used to it meaning Computer Science. It was pretty easy to keep things straight, though sometimes it messed me up a little.

IGNITE Lightning Talks Are Tough!

On Thursday, I gave a lightning talk about how technical debt was caused by the same root problems as content bloat. (Expanded slides here.) I’m a confident speaker and I’d given lightening talks before, but the IGNITE format — 20 slides that autoadvance every 15 minutes — was unlike anything I’d ever done before. You need to rely less on the effect of that perfectly timed GIF, and more on a general sense of the flow of your points. And you had better get those points down to their bare essentials!

I did make friends with the other people waiting nervously in the lineup, though, so that was cool.

You Can Refactor Content as Well as Code

This wasn’t exactly surprising, but it made me happy to hear presenters talk about content in terms of Agile methods and refactoring, both terms that draw from engineering. And my own presentation was basically trying to outline how content strategy happens in code as well as in other formats. These moments of cross-discipline translation are were exactly what I wanted to see and talk about, and I got to experience so many of them!

I Wish There Were More Communication Talks At Developer Conferences

To be clear: there are talks on communication at code conferences. But at ConFab, it was much more a sense of actionable, step-wise instructions for getting stakeholder buy-in, dealing with difficult situations, and making sure that your suggestions for change got listened to. I was particularly impressed by Ahava Leibtag’s talk on challenging conversations; I definitely learned a few things I can use, particularly when it comes to choosing how and when to give feedback on website quality.

The reason I think tech conferences could use this type of talk is because a CS-degree-having Linux wizard told me, regretfully, that this type of stuff was never covered in CS (or STEM) curricula. But yet, as we all know, it’s almost never the code that’s standing in the way of achieving something. And the more we move towards integrated tech and cross-functional teams, the more developers will need to be present in discussions, not merely as experts on high, but as full collaborators in a project. And I think some specific instructions on the non-coding side of things would really help.

OMG, Keynotes

One of the things that made me take the plunge was seeing that Anil Dash and Cheryl Strayed were giving keynotes. I’ve been following Anil Dash’s series on humane tech for a long time, and I’d read Wild, so I thought it was really cool to have speakers talking about general life stuff, in addition to speakers talking about specific skill sets.

Netflix Has a Neat Tagging System

Another talk I really enjoyed was the one on how Netflix generates those genre category titles you see above your recommendations. I don’t want to get into all of the specifics, but it was a terrific window into how human taggers are an integral part of the system.

What’s In a (Strategic) Name?

Why A Name Matters

My team just changed our name from the Platform Team to the Engineering Team. We did this after our new editor-in-chief asked us to reflect on what we wanted to be called, and on how our tech team was different from the other tech team, and on what it was that we actually did here, anyway.

I jest. It was a welcome chance to reflect, for many reasons. In the four years I’ve been here, we were at first “the tech team”, which did little to foster collaboration. Then we were the Platform Team, a name change that came with the decision to have a separate news apps team instead of just a bucket of programmers; the titular platform was our CMS/website…and then our other site’s CMS/website…and then a few instances we had running of other things that we used to run the sites…and Salesforce…and Eventbrite.

To reflect the systemic nature of what we do, this time around we chose Engineering, and changed our individual titles accordingly. I became the Director of Engineering Strategy — the addition of “strategy” was my idea. Amusingly, there’s now a Quartz post talking about why you should never have “strategy” in their job title, viz. because “Strategy people too often have ideas that aren’t rooted in the reality of the operations. And operations people too often aren’t invested in executing the plans that the strategy people craft for them.”

If other people aren’t invested in executing a plan that solely because they haven’t come up with it, we have worse problems than titles. And if the strategy person hasn’t approached things realistically, and gotten buy-in, they’re not doing their jobs well. Which, granted, I have seen on occasion, but it’s often from people who don’t have “strategy” in their title. So again, I think the title isn’t the issue.

More frequently, I’ve seen many department directors (including past me) view their job as representing (or protecting) their departmental interests. When it came to my title, I wanted to somehow represent the big-picture nature of our team’s task, including the fact that we’ve helped change the way our organization makes web things. We’ve move to a much more agile process. We’ve started asking people to bring us user stories instead of feature requests. I included content strategy in my latest job description, because after two years of dealing with our technical debt, I’d concluded that content governance (or lack thereof) was the root cause of many technical decisions that were made.

So I added “strategy”, to try to accurately represent the fact that I (and my team) were active participants in shaping the our content and processes beyond just the technology.

Why A Name Doesn’t Matter

My advanced degree, in Classics, blithely requires you to master two separate languages, Greek and Latin, as well as to have a passing acquaintance with a few more. The idea is that the Roman Empire was built on top of the Greek one, and the two cultures were related by geographical proximity and exchange. Which is fair, and isn’t a bad introduction to the global notion that almost everything has several different words to represent it. In fact, Classics is what brought you the notion of Indo-European, a theoretical language from which most European languages sprung — this is a language, let us remember, that is totally made up, and was never spoken by anyome. It’s sort of a like a grand unifying theory of language, which is also something humanists like to look for.

Fast-forward to now, when I work at a small organization; we don’t have the resources to hire separate people for the subsets of this amorphous trade. And I’m not trying to say that specialization isn’t valuable – it is! Having experts in one area or another is necessary, particularly as you scale. But there’s also a commonality among tech things that aren’t easily boxed in as programming-language based skill categories: these tend to be called content, or product, or UX, or whatever we’re calling it these days.

But I also kind of don’t care what we call it, because our small size has allowed me a chance to observe that what’s important, really, is the mindset: the realization that code — and by extension features — won’t solve your problems. The realization that you need to focus on asking people to define problems instead of solutions, and that you need to, in Katie Zhu’s (product and engineering) words, ship outcomes not features. What unites strategy, in all of these job arenas, is a sense of standing in the middle of sometimes-competing priorities and sorting them all out. Though due to my previous training, I often think of this as an exercise in translation.

That’s my grand unifying theory, anyway. Old habits die hard.

What I’m Good At

The opportunity to change titles also brought a chance to reflect on what I liked doing best, a question that is reflected in two careers. My first career was that of an academic who studied and taught Rome. Asking why Rome became the empire it did is a lot like asking about the cause of the civil war, in that the right answer is, “It’s complicated”. (Great training for the “it depends” answer of a good engineer).

But one of the main things that allowed Rome to extend its empire was acqueducts, those arch-like things that carried water where it was needed. As far as ancient architecture goes, they’re incredibly unsexy. They’re pragmatic, long-term civic infrastructure that needed to be maintained by the ancient equivalent of home repair contractors. As one of my former professors liked to quip, “If really want to know what made Rome great, it was concrete.”

When I was still a classicist, I had the training to see a paradigm shift happening, which is part of why I changed careers. I could see that the wires of the internet (and yes, at its heart, it’s still tubes) were the new acqueducts, and that it was probably a good idea to get acquainted with the bones of our new epoch, STAT.

I applied my classics training then, and I still  apply it now: I’m in the business of building infrastructure, social acqueducts, and other long-term goals.

I’m a big believer in structure, social or otherwise Why? Well, a hundred sociologists could give you rigorous arguments, but the basic tenet is this: the individual will of one person isn’t going to enact justice. A system that is built to be fair will. That’s why organizations need to focus on, for example, systemic solutions to things like sexism and unconscious bias; all of the best intentions of individuals will not do it. And executing that system requires un-sexy maintentance type stuff: carefully designing job descriptions, actively recruiting diverse candidate pools, using rubrics to compare candidates, and making sure to ask them the same questions to have fair comparisons. Things that some might feel quash their individual expression, if they didn’t come up with the idea.

(Incidentally, that’s why we need to stop lionizing individual lone wolves. A point that’s been made by others, and/or a post for another time.)

Speaking of annoying buzzwords,  I’m glad we’ve started to notice that un-sexy maintentance, not sexy “innovation”, is what really matters. Because I like maintenance. It’s part of liking long term plans. And sure, I like building — and helping to build — if we’re talking about things that will last a long time. Short-term viral growth is boring to me, as a historian turned engineer. I like building things — teams, apps, structures — that will last a long time.

On the everchanging architecture of the web, building things to last is a helluva job. Sometimes it feels like astrology as much as making good decisions. But I still like it. Whether you call it strategic or not.





Data Philosophy: A Day in the Life of a Tech Newsroom

“What makes a Muppet, a Muppet?” wondered our designer. He’d made a prototype illustration, but wasn’t happy with it — he didn’t feel it was immediately recognizable as a Muppet.

He’d come to the tech area for input, and we were happy to oblige. We analyzed the hell out of the visual ontology of Muppetdom. We searched for web images of Muppet schematics. We agreed that the mouth should be open, and maybe there needed to be wrinkles around it it. The head seemed more Muppet-like tilted to the side. I thought there needed to be more obvious fuzziness, while my co-worker thought only the eyebrows needed to be fuzzy. We debated the need to soften harsh angles, and whether the nose should be indicated by a hard crease or a soft planar shape.

The next day, a passing editor joked that they’d heard about our philosophical discussions and wanted in. Easily accomplished, as one software engineer had just said out loud: “What makes a person, a person?” Soon, the office was filled with talk of whether a politician was defined by their office, and what said office meant – was it a building that existed around the politician? Did it exist with no politician in it? Was it a place, a personality feature, or a vocation?

The irony is, I spent ten good years avoiding similar discussions – endless philosophical debates on semantics and meaning and OMG do we have to deconstruct everything to nothingness?! One hint of such discussion and I’d find the people at the other end of the bar, probably shipping Buffy. But there’s a crucial difference in the tech room discussions: While everyone involved enjoys the speculation, it’s usually in service of building something real.

(As real as a virtual thing can be. It’s stored in hard circuitry, anyway.)

In the first case, the designer needed to produce a recognizably Muppet-like illustration. In the second, we had a more difficult task at hand, a database issue where we were trying to decide how many categories we needed, and whether we could use the same one for our site’s users and for the politicians in our directory – all real people, you see, but with different sorts of information needing to be stored. Hence the question of what makes a person a person; yes, the bane of philosophy for millennia, but also the bane of a machine trying to define a person as a series of categories ergo the bane of a programmer trying to define what the machine knows.

Anyway, I understand now why Google has been, at times, hot for people to run out and get philosophy PhDs. To them, grad school must seem like a magical wonderland of people who like to do this stuff! All day! Ad infinitum! Alas, Google’s got it wrong. By all means engage in philosophical sport if you like, but do it while getting paid to design databases, or at least make your money building software first. Also, good luck telling your grad advisor about the need for pragmatic end goals — they tend to look down on that, or at least did when I was still there.

A few weeks later, I saw again how practical some of those “useless” humanities skills could be. We were dealing with a bunch of data, inconveniently and messily produced by actual humans. Because the humans refused to use the exact same word for every description, we had to come up with a way to make the data more computer friendly, viz. by categorizing it. There were maybe 225 entries to deal with. Not even close to being Big Data.

Dealing with a small bunch of messy human data is the same as doing history, as far as I’m concerned. And it’s an obvious (and not even monumental) task for a competent grad student in many fields – history, anthropology, library science, sociology, etc. I said as much to the room;  the room laughed. The programmers were already talking about using Mechanical Turk to crowdsource the categories, because in their view anonymous data input is the only reliable way to let humans categorize stuff. Both I and the reigning editor deemed this a no-go. And even the software engineer had to admit that writing a useful parsing script (which of course they’d started to do) was probably as time-consuming as having people do it.

When I mentioned the grad student solution, I suppose it seemed like joke about how desperate PhDs are, or maybe people thought the task was too complicated to leave to the “soft sciences.” It was frustrating to try to communicate that, in actuality, there are non-science people trained in exactly this. People who could help, and who would enjoy the task. And that any parser we’d write would be just as unscientific because of the small data set and the fact that a fallible human was writing it.

The point being that basic skills such as analysis, categorization, and yes, even being skeptical about categories, are not science skills. They’re not even tech skills, particularly. They’re skills you learn from sifting through data, and thinking about categories and the people who make them.  Like a lot of soft skills , they’re not an easy sell — “Hey, I classify stuff real good!” — but if you can spin it to the specific situation, you might get somewhere. And do not, under any circumstances, tell people that what you’re really doing is humanities.

Training People Digitally, For Real

This weekend I’ll be at NICAR, the conference that last year inspired me to ponder what humanists could learn from journalism. That means I don’t have a lot of time to write. But I wanted to share an screenshot from the NICAR schedule that I think is worth a thousand words:

Screen Shot 2014-02-23 at 8.35.48 AM

This is what a genuine commitment to helping people learn tech stuff looks like. I myself will be attending several of the hands-on classes, because there are data skills I have yet to learn. That’s the thing, there’s always more to learn:


To my mind, this is what the digital liberal arts should be doing. Not worrying about the theory, but getting more people involved in the practice. Not navel-gazing about where we’re going, but making sure that humanists are equipped to enter the larger tech conversation. If haven’t bothered to learn some of the above, you’re not going to be taken seriously in a tech conversation. You can debate the fairness of that but the fact is, if you don’t get in the game, other people will be making the decisions about what digital archiving, publication, and communication looks like.

Just my two cents. And seriously, y’all, if a kid can do it, you can too.