You don’t have to answer questions...

“You don’t have to blog (articles). You could share... code.” Those are the words that encouraged a colleague and friend to start yet another Tridion blog. He literally called it “Yet Another Tridion Blog” and has shared mostly, well... code.

After blogging hundreds of posts about Tridion, content management, and business analysis (over 300 last I counted), I’ve developed the rewarding habit of encouraging other people to share with their respective communities. This is typically about Tridion (Sites or Docs), but I’ve seen and (hopefully) helped others jump into other online communities.

I’ve been recently asked a few times how people should share and what they might blog about. One cited it's hard to answer enough questions on one of our community forums.

Getting the same question multiple times is a sign that a blog post is in order. It’s also an easy way to get the content and ideas for the blog since I’ve just answered the question.

First of all, you don’t have to blog. You don’t have to answer. You should instead focus on learning, sharing, and participating.

What should I share? 

Share what you’re working on, properly anonymized to protect trade secrets, intellectual property, and customer information especially if you work with customers.

The hardest part of working with a system is probably having context and examples. Even the most descriptive APIs and API documentation don’t quite explain exactly how to format data, what tools to use, or what are common sets of data.

So new members of a technical community could benefit from examples of anything you’re working on, with some context on how or why.

Your level in a given language or technology doesn’t quite matter as much as the example, as long as limit sharing things that others shouldn’t do. But even then, you could disclaimer the dangerous "don't try this at home" parts.

For code, you might consider different levels of sharing and investment.

1. Minimum: connect to an API with a snippet of code 
2. For beginners or people new to an API: share some common boilerplate code and examples
3. Intermediate: which methods to implement for a particular part of an extension, good practices, and gotchas (e.g. what’s the right format for a URI when a method/function is looking for a string)
4. Advanced: Nuances of that specific technology or programming language like how to properly dispose of a client.
5. Thought leadership: create a shared repository that others could work on

You’re busy enough, so don’t try to start an ambitious new project. There are dozens to hundreds of existing examples and we need more curation, maintenance, and updates to modernize everything.

I'd add specific things I'd like to see in my online communities. But I'd be missing the point. Share the answer to questions you have been asked. Share some aspect of what you've worked on. Share code. Or don't. Blog or don't. You don't have to answer questions...