This technical blog is hardly the ideal, but I'll use this space here to summarize some of the guidance that my colleague Randolph West and I presented at a Microsoft MVP PGI this week. Their summary and mine specifically on the technical blogging are hopefully a resource for you, especially if you are early in your career or a Microsoft Student Ambassador.
Technical blogging can grow your technical depth and writing skillsets simultaneously. Ideas, tips, and recommendations:
Blog content ideas:
- Reference, samples, labs, especially for newcomers to the field.
- Deep dives into a topic you're interested in.
- Summaries and use cases of new features or changes.
- What's new? pages in Microsoft Docs are rich with blog ideas
- Checklists, best practices and lessons learned are great blog content.
- Your clients and customers are a fertile farm of reusable scripts, patterns and antipatterns, tools, and blog posts. "It depends" answers are great blog posts.
- Technically reusable content from client to client is a value add. A public bucket or toolbox of lessons learned is valuable.
- Remember the best way to learn a topic is to try and teach it (or explain it in a public blog).
Tips on blogging:
- You don't have to be unique (but don't plagiarize). You can write about any topic, even if it's been covered by bigger names. Your voice is valuable.
- Don't steal content or plagiarize, but you can admire and emulate (and attribute with links) the style/format of another author or blogger. Emulate things you like about someone else's process or research style or content format.
- Make it into a story if you can, "It tried this, it broke, I tried this, it didn't work, I fixed it this way..."
- A problem with no solution is worth blogging about. Sometimes, blogging about a problem is a great way to work the problem, and figure it out in the process.
- Write regularly, set a schedule. Pick a topic. Not every post has to be a novel.
- Do you ever write too much? Blogging can be great practice in distilling the core problem/concept to a palatable, communicable summary. It's easy to be wordy and redundant. It's a skill to practice writing more concise technical summaries. "If I Had More Time, I Would Have Written Less"
- Challenge your preconceived notions. Be humble in defeat and write about it. If you're proven wrong, your immediate reaction is usually to be defensive. The second reaction should be to learn from it, perhaps blog about it.
Get an editor, or volunteer to edit for blogs, newsletters, articles.
- Ask for a volunteer (or pay a) technical editor for your own blog.
- Listen to feedback. You trusted someone to edit you for a reason.
- Edits can feel like a gut punch. Don't take it personally.
- Politely ask to be someone else's volunteer technical editor for their blog.
- Provide constructive feedback, challenge assumptions, test technical scripts.
- Easier to find inconsistencies or gaps in someone else's work, it can be instructive to your own work.