What I Want From “Social”

Facebook. Google+. Tumblr. Pinterest. Any of the other myriad social content services now thoroughly entrenched in the web – they’re all going after the same kind of interaction, if in subtly (or even obviously) different ways. Even with so many options, however, I have yet to find one that really embodies what I’m looking to get out of a social content experience.

(Disclosure and disclaimer: I work for Google, though not for any of the Social product teams. The opinions in this post are completely my own, do not reflect those of my employer, and should not be taken as indicative of current or future development efforts.)

Ease and versatility of content creation

Text composition and formatting

Blogging platforms (e.g. WordPress, Tumblr, etc.) probably do this best… in that they do it at all. Social content sites can generally be broken down into two fairly distinct categories: blogging platforms, and platforms with little-to-no formatting options. At best, non-blogging platforms tend to support bold, italic, auto-linked URLs, and maybe a handful of other styles (e.g. Google+’s strike through).

My ideal social content platform would support a broader set of formatting options, while maintaining a consistent style. A reasonable set of formatting options would be those represented by attribute-less HTML tags – for instance, superscript and subscript, headings, and monospace/preformatted text. This avoids the possibility of too much eyesore (I’m specifically not looking for unrestricted colored text support, for example) while still allowing the usage of well-established formatting standards to present content in a more organized and elegant manner.

An ideal content platform would also make these formatting tools accessible to any level of user. While I as a technical user might prefer writing my posts in Markdown, someone else might be much more comfortable with a WYSIWYG or WYMIWYG creation process.

Multimedia sharing

An ideal platform also needs to support other media beyond text – photo galleries, shared videos, and so on. These should be presentable in a consistent and clean format that doesn’t need extra formatting effort on the part of the content creator. Modern social networks tend to handle this fairly well for embedded content, while most blogging platforms handle this poorly.

Clear and powerful access control

Google+ circles are pretty much the reference implementation I have in mind here – it’s the first service that I’ve used any significant amount that I actually felt got access control right. From the start it makes it clear what you’re sharing and with whom, with the concept of circles baked into every aspect of the site.

I stopped using Facebook months ago, but when I left, my perception was that while they were trying to get some of the same concept implemented via friend lists, it was very much an uphill battle due to how much of the site was implemented around the symmetric friending model.

Many other content sharing platforms have very little access control at all – Twitter basically only has 2 options for sharing (all tweets are followers-only, or all tweets are public), and others have none (e.g. Tumblr).

Interest-based curation tools

This is an area in which Pinterest shines. By giving users the ability to create separate personal boards for each topic, and then subscribe to other users’ topic-specific boards, Pinterest allows a very fine-grained control over not only whose posts you see, but also what they’re about. As it turns out, just because you like someone’s posts about one topic doesn’t necessarily mean you’ll want to see everything they’re interested in (case in point: politics).

Note that this is different from, say, Facebook groups (or a classic example, LiveJournal communities). With such groups, access control and interests are conflated – to see any posts from the group, you must see all posts from the group, and to share something with the group, you must share it with everyone in the group. As a result, it’s generally necessary to have a group moderator if any modicum of privacy is desired.

The Pinterest model avoids the need for group moderators by keeping the topic separate from the set of users a post is shared with (though in Pinterest’s case, this is because they have basically no access control). Keeping topics separate from access control allows for the asymmetric access control model of circles without sacrificing the ability to customize topic consumption.

Intuitive discussion and moderation capabilities

Discussion format

Content creation and distribution is only half of the social media platform equation – the other half is dialogue. Forums are devoted entirely to encouraging dialogue with features like the ability to easily refer to past parts of a discussion (via quotes or links to individual posts) and the ability to display both threaded and sequential views of a conversation. Many other social platforms, however, have neglected such functionality, instead adopting the stripped-down “comment stream” model of dialogue. While there is plenty of dialogue that can go in within a flat comment stream, it’s primitive at best compared to the interaction capabilities of more modern forum software. In a complex conversation with multiple lines of discussion, it can be difficult to tell who is referring to what without more explicit indication.


There’s also the matter of moderation, an area with which forum administrators are generally quite familiar. As the number of people conversing in a single place grows, so does the chance that one or more users will behave in a way not conducive to the kind of conversation the content creator is interested in promoting. The tools provided by many social networks to moderate ensuing discussion are lackluster at best – typically nothing more than the ability to remove a comment or globally block a user (if that).

There’s also the possibility of allowing other commenters to participate in the moderation process. This includes both a community voting system a la Reddit, or pointing things out to a designated moderator (such as the post owner). If there’s an ability to report a problematic user on a social platform, it usually reports them to the owners of the platform and not the creator of the post, which means that it’s useless for situations that aren’t against the platform’s TOS but are against the wishes of the original poster. Providing more ways for commenters to point out troublemakers to content creators would lessen the burden on content creators to police discussions.

So to sum it all up…

You could roughly say that what I’d really like to see is a social content sharing platform with the circle model from Google+, the topic-subscription functionality from Pinterest, the content creation tools of WordPress and Markdown, the discussion and moderation power of a forum, and the multimedia sharing capabilities of Facebook/Google+.

Put that way, it almost sounds simple… until you realize that each of these is something that an entire site has devoted itself to doing well. Doing all of them in a single site would be at the very least challenging, and doing them well in a single site would be a truly herculean effort. Doing all of it, doing it well, and gaining enough market share to hit the critical mass of users necessary to give a social platform real staying power… well, let’s just say I’m not holding my breath.

That said – if you manage to pull it off, make sure to let me know.

Why I’m a Programmer

I tried googling this question, and was surprised by how infrequently it’s actually addressed. Most of the results are for one-off jokes. The only significant post I found that was actually trying to answer the question in detail was a post by Anne Epstein. That post, however, focused more on the “how I became and thus now am a programmer” interpretation of the question.

The version I want to explore is “why I remain a programmer” – what my motivations are for doing what I do. I think it’s an important version of the question to consider, because it’s the one that others are really going to want to know about when they’re choosing a career path. It’s the one that avoids propagating a sense of technical entitlement. Lastly, it’s probably the one that I, as the author, can actually get the most use out of considering on an ongoing basis.

So why am I (still) a programmer? The trivial answer would be “because I enjoy it,” but that’s a cop-out answer which is useful to no one. So let’s go a bit deeper. Why do I enjoy it? There are a few reasons.

First, I enjoy problem solving – both on a micro and macro scale. Programming involves copious amounts of both. Figuring out the most efficient way to implement a feature or tracking down a bug in existing code are examples of small-scale problems that programmers solve. Figuring out software solutions for problems like hurricane disaster relief coordination, personal bookkeeping, or project funding are examples of the larger scale. Whatever project I wind up working on, it winds up having interesting challenges.

Second, I enjoy creating. Programming is wonderful for this: it’s a medium that, unlike many others, allows me to create something out of nothing. I’m not limited to physical constraints; if I can imagine it, I can create it (with enough thought and effort). Programming lets me create things that tie into the rest of my life and improve it, whether for fun (e.g. addons for a game), productivity (say, automating parts of my daily routine), or profit (work, modeling my personal finances, et cetera).

Third, it’s a career. It’s an area that has a lot of demand and probably will continue to be in demand for the foreseeable future. As such, it’s also an area that pays well. This does contribute to my enjoyment of programming. While I don’t tend to be frivolous with my finances, having a solid income makes staying in the black a lot simpler, and allows me to save and invest for the future, whether that be good times or bad. As someone who eventually plans to raise at least one child, I feel an obligation to help make that child’s financial future reasonably secure.

Despite my gripes about some areas, the tech industry has become one of the better and more progressive industries in many of the areas where it matters. My employer’s healthcare benefits are amazing. Flexible schedules, liberal parental leave policies, and other such benefits are commonplace. Sure, there are some bad apples, but demand is high enough you can usually shop around. Having this kind of work environment and social support structure improves my overall quality of life.

Documentation Lock-In

Documentation is important. It’s how all the collective knowledge about a piece of software (or many pieces of software) is recorded and organized for use by those who maintain it. Once you get beyond a couple of developers, documentation becomes not just important, but required – without it, it’s not feasible to keep everyone on the same page.

While you could theoretically decide to keep things bare bones and put all of your documentation in plain text files, most developers aren’t masochistic and opt for something more flexible. Tools abound for creating, editing, generating, and browsing documentation – everything from markdown to wikis to static site generators (and plenty of combinations, too).

Given that documentation becomes a necessity so quickly, a given project often winds up choosing some set of these tools fairly early on in its lifespan. Sometimes it’ll be whatever the current fad is, sometimes it’s the system one of the developers used on an earlier project and liked, sometimes it’s just whatever happened to pop up first on Google. In general, though, such tools are typically chosen with at most only the current needs of the project in mind.

The problematic reality

It’s a common situation that a few years or even just months down the road, the documentation system is no longer really suited to the task at hand. Perhaps it’s missing features that would be extremely useful now that the project has matured, or perhaps folks have discovered that the system they chose is a maintenance nightmare and would rather have something more robust.

The more complex a documentation system is, though, the harder it is to move to something else (while preserving existing knowledge). Even something as simple as links between different documentation pages can present a serious headache: not only do you have to worry about migrating the content of pages from one system to another, you also have to make sure all the links are pointing to the right places. In effect, you wind up writing a compiler+linker combo: a compiler to translate the content of your old documentation system to your new one, and a linker to fix up all the references.

Of course, that’s not even counting any potential mismatches or incompatibilities in the content itself. Perhaps your existing documentation system supported templates in one form, and your new system does too… but in a completely different format. You’ll most likely wind up having to translate all the templates by hand, and then adjust your “compiler” to invoke them in the new format. Alternately, maybe your old system supported JavaScript, and so you have to make a choice between finding a new system that also supports JavaScript (and fixing anything which breaks in the transition), or dumping JavaScript support and either removing or reworking anything that was using it.

All of this makes it a lot more painful to change documentation systems after the fact. It’s not surprising that so many large projects wind up having documentation systems that seem needlessly sub par: it’s probably not because they like them that way, it’s because they’re effectively stuck with them.

Thinking ahead

So what to take away from this? Nothing’s going to make the problem completely go away. As long as useful documentation exists, some of these problems are going to crop up, and getting rid of documentation obviously isn’t the solution. Instead, the best strategy is probably twofold.

First, try to plan for the future as much as possible. If a tool only barely meets your needs now, it’s almost certainly not going to meet them later on down the road. Note that “meeting your needs” can apply to many aspects – not just the raw numbers. In addition to such absolute performance, there’s also things like minor irritations and maintenance hassles. If the system you choose is “good enough” but almost makes you fed up now, chances are you will get fed up with it later. Avoid compromising on the underlying system, because chances are you’re going to be stuck with it for a while. Documentation often gets even less refactoring love than code does (and code often doesn’t get nearly enough).

Second, since knowing the future is often hard (and the services of those who can do it reliably are often priced in souls/hour), plan for change – especially in the early stages of a project. When things are just starting to take off and get a little more complex, hold off on adopting a giant flashy feature-rich documentation system. Keep things simple instead: rich in information, light on complexity. Avoiding complex features will make migration into another system a lot easier down the line, once you get a better sense of where the project is headed and what its documentation needs will be.

Bonus tip: for web-based documentation, use an editable URL shortener for external links into the documentation. When you change documentation systems, the URLs for pages are likely to change at least a bit, breaking external links. If external sources use the shorturls, though, you can just update where those shorturls point. It’s a lot easier to update a bunch of shorturls in a database you control than it is to try to get everyone else to update their links.

Another Day, Another Post, Another Creep

The other day I posted on Google+ about a somewhat disturbing aspect of Pandora’s account settings (the issue has since been at least partly patched). That generated a fair amount of interesting discussion, which I always welcome, but it also resulted in something not so welcome – creeping. Over the course of the day, I saw all sorts of stuff:

The iffy

At least 3-4 random hangout invitations from completely faceless entities.

Random hangout invitation

No avatar, no mutual friends, no comment, not even a public post, yet you think I want to go on camera for you?

The somewhat creepy

“Joking” comments on my appearance/relationship status.

Comparison to TV characters

No, thanks. Among other things, I’m married.

The creepy and objectifying

Comments on my appearance when I’m “using my brain”.


If only he was using his.

The seriously creepy

I have 7 profile pictures. One of them is a stylized “A”, another is Fluttershy, the rest are real photos. This guy +1’d 5 of my profile pictures in a row. Guess which two didn’t get a +1.

+1'ing all of my profile pictures

No love for Fluttershy?

Okay, maybe he just likes pictures of people… orrrrrr not.

Creepy Email

No, I’m pretty sure you’re just creepy.

The obscene

Why bother with real social interaction when you can just proposition random people for sexual acts?

Obscene private post

Yeah, that’s a no.

So about that…

While the particular rate of this kind of stuff was much higher the past day or two due to having a fairly widely shared post, it’s not exactly isolated or new. It’s one of the main reasons why the majority of my posting on social networks is done to a limited audience, not publicly; I simply don’t want to deal with the extra hassle of cleaning up or otherwise dealing with this kind of crap.

When I post on social networks, I’m looking for interesting and meaningful discussions, just like most of the people I tend to associate with. Yet somehow, there’s always the people who assume because my profile has “Gender: Female” in it, I must also be wanting sexual advances and/or expressions of desire. In a post about web security.

Yeah, I don’t get their reasoning either.

Embracing Vim, Step by Step

I’ve used Vim as my primary editor for years now after having mostly picked it up in college as a convenient editor for working on school servers. Having a lightweight editor that I was pretty much guaranteed to find already installed on any machine I happened to acquire SSH access to was what originally got me into using it; the speed and efficiency benefits were merely a nice side benefit.

As such, my first few years using Vim didn’t involve harnessing much of its power – I essentially used it at first like a version of pico that happened to have some use commands that were accessible by pressing Esc. (If you’re a Vim user, I can feel you cringing. I am too.) As the amount of time I spend coding has increased (from starting out as a hobbyist, somewhat time-starved college student to working full-time as a software engineer), however, I’ve slowly begun picking up more and more Vim tricks of the trade.

Along the way, plenty of people have suggested various books or tutorials or other such massive collections of Vim knowledge, but so far my experience has been that very little of that tends to stick. If I try to learn a giant chunk of Vim features all at once, none of them really have the chance to become a habit, ingrained in my usage patterns. As a result (and due to the perfectly reasonable terseness of the average Vim instruction), they tend to just sort of fade away.

Instead, I’ve adopted a slower but steadier pace when it comes to learning new Vim shortcuts. First, I find a handful of related commands that are both useful and relevant to something I’m doing. I then focus on integrating those commands into my daily usage. Once they become something I do out of habit rather than conscious recollection, I move on to another set. I’ve found this approach much more successful in changing my long-term usage habits, which in turn has made my overall editing experience much more enjoyable.

As an example, the most recent set of commands I’ve decided to work on incorporating are related to visual mode:

  • v% – select text from current side of a matching pair to the other side (for instance, from one parens to a matching parens)
  • vib – select all text from the parens block the cursor is currently in
  • vi' or vi" – select the entire quoted string the cursor is currently in (depending on which quotes are used)
  • viB or vi{ – select an entire curly-brace-enclosed block
  • The a variants of these (using a instead of i includes the surrounding markers, e.g. quote marks).

These particular commands are nicely demonstrated in this StackOverflow answer, including animated gifs to show the results. I’m almost certain I’ve run across these commands along with many others when perusing larger collections of Vim shortcuts before, but because I wasn’t focusing on them, they were lost in the noise. Time to fix that.

As I move on to other Vim shortcuts, you may find me writing other posts detailing each of them in turn. What you probably won’t see is a giant blog post summarizing every Vim shortcut I’ve ever learned. There are already enough monolithic guides out there.