Corporate Blogging is Hard; Open a GitHub Issue Instead

(Inspired by this conversation between Jukesie and Himal)

Lots of companies encourage their staff to blog. It's free PR! It makes them look like they're on the cutting edge of technology! It helps with recruitment!

It can also be a corporate nightmare. What if the developer says something stupid? What if it accidentally reveals something top secret? What if the CEO doesn't like it?

And so, gradually, any free-wheelin' developer blog gradually succumbs to the tender mercies of the comms team. It starts with help editing and clarifying the writing. Then it turns into massaging the tone-of-voice. Before too long you have to wait for a slot on the corporate comms grid. And then you need seven levels of sign-off just to post something anodyne like "5 reasons we switched to Rust".

*sigh*

So, maybe once or twice, I cheated.

Rather than writing a blog post called "An interesting issue configuring GLaDOS with YAML" I opened an issue on our public GitHub repo.

Oh, sure, it wasn't as "bloggy". And I still made sure not to discuss anything secret or sensitive. For some of the more contentious issues, I ran it by a few trusted colleagues first. But, for all intents and purposes, it was a blog post. Nerds got to reply in the comments, people shared it on HN, people quoted it on social media.

I've since left that sort of restrictive environment. I still see my old team occasionally publishing a useful blog post. But I keep my eyes on their GitHub issues to see the real story!

What's the moral here?

Should you bypass your employer's strict social media policy? No, absolutely not. Should you ensure that your GitHub issues are well-formatted, interesting to read, and useful to others? Yes.