Yesterday I attended a Write the Docs meetup where Andrew Etter spoke about his recently published book, Modern Technical Writing: An Introduction to Software Documentation.
I haven’t read Andrew’s book yet, so I appreciated this introduction from the author. One thing that strikes me is how interwoven are two aspects of technical writing: firstly, the processes (the way we glean our material and our efficiency and efficacy in writing content); secondly, the tools we use. Every now and then, I’ve heard people say we shouldn’t focus so much on the tools when discussing our profession and how best to perform our role. I’ve thought that too, at times. But it seems to me that these two aspects of our work are becoming more and more interdependent. The tools make a specific way of working possible, and the way we think of our work determines the tools we choose.
From what Andrew said about his book yesterday, the content of the book seems to agree with my above musings. Now, I should go and read that book.🙂
Modern Technical Writing, the book
Andrew pointed out that you can read his book in about 45 minutes, and that he’s been allotted an hour for this talk! This comment raised a good laugh.
The book is about 11,000 words. Andrew summed it up (with a smile) in about 12 words, which roughly correspond to the highlighted words in the list below:
- Learn – learn your subject matter and get to know your audience.
- Write in lightweight markup – it’s the easiest way to get from a pleasant writing experience to a useful website. Markdown is a good solution, because people want to use it. You’ll therefore have plenty of people willing to contribute to your docs.
- Treat the docs as code – version control and continuous updates. The stability of the docs over time depends on the quality of your updates.
- Create static websites.
The book, Modern Technical Writing, started as a wiki page. Andrew needed information about technical writing to pass on to others. He did a bit of research, to see if anything already existed that he could use. Having found nothing that fit the bill, he decided “I’m the writer”, and wrote it himself.
What makes a book sell?
Andrew spoke amusingly about an FAQ on the Kindle Direct Publishing site: “Why am I not selling? I am a good writer.” The fundamental question is, how do you get people to buy something you’re selling? Andrew said with a smile that he has no idea! He doesn’t do much marketing or promotion via social media. Here’s his recommendation:
If you have something you feel strongly about, something you’ve shown to your friends and got good feedback on, something you think adds value to the world, then put it out there.
The publishing process
Andrew chose Kindle Direct Publishing as the mechanism for publishing and earning royalties. The rules around pricing are really complicated. The magic happens when you upload your book to Amazon, and they transform it to a Kindle book. Amazon is the market leader in online publication, and your book benefits from this.
One drawback is that you cannot test your book before publication. You just upload it, view the highly inaccurate preview, and then publish it.
Andrew showed us a screenshot of his book on Amazon right next to Strunk and White’s Elements of Style. To be near Elements of Style is mind-boggling. But it lasted a very short time. He dispelled any myths that self-publishing is lucrative. He has, however, received very nice messages from people all over the world.
Charging a price for the book
If you give something away for free, there’s the perception that it’s not really valuable. If you give it a price, people are more likely to see it as worth something.
For his book, Andrew thinks that the price of around $4 is in the right range.
What technical writers do
What is the “differentiated value add” of a technical writer? That is, what do we do that no-one else does?
- Consistency – specifically, consistency in tooling. Without tech writers, each engineering team would pick their own tools, which would result in chaos.
- Accountability – someone has to be responsible for creating good documentation. Andrew remarked with a smile that you have to be able to fire someone if the documentation is bad.
- Creation and curation – writers review and take care of others’ content as well as writing it.
- Culture – having good writers around makes everyone else aware of what good writing looks like.
- Good documentation leads to efficiency improvements in many ways. It helps the organisation and customers save time, and time is a precious resource.
Andrew talked a bit about the writing process, project prioritisation, and the team. He joked at the beginning of the presentation that these topics may form part of the second edition of the book, if he ever considers writing one.
The old way versus the new way of producing documentation
Andrew talked about old methodologies and tools versus the new ones, and walked through some code samples. I didn’t make notes of this part of the talk. The details are in Andrew’s book.
Thanks to Andrew Etter for an engaging presentation and congrats on your successful book!
Where do technical writers belong in an organisation? Which team should we be part of? This is an interesting question that many of us are asking. I don’t have an answer. In fact, there are probably as many answers as there are possibilities, because each organisation is different, and so is each technical writing role. But I do have some musings and two presentations to introduce.
Where we end up in the organisation can affect the way other people see us and our contribution to the company. It can affect our own perception of our purpose and goals. It may even affect our ability to do our job, if our position in the company determines the access we have to information, technology, and other resources.
Sometimes, we’re lucky enough to have a say in where we end up. That’s when it becomes really interesting, because the choice may not be easy.
Where do we belong?
Here are some of the possibilities:
- Engineering and product management: Technical writers work closely with the software developers to understand the ins and outs of the product. It’s also very useful if technical writers can give early input into the design of a product, taking advantage of the user-focused nature of a technical writer’s role.
- User experience: Technical writers, UX designers and UX researchers are focused on the needs of the customer. They often work closely together in producing the documentation and other user aids, even if they’re not part of the same team.
- Support: The documentation is an essential resource for the support team. Working as part of support can give technical writers direct access to the requests and problems reported by customers.
- Marketing: The documentation is an important marketing asset, and the level of technical detail in the documentation tends to yield excellent SEO (search engine optimisation). Technical writers and marketers often find themselves writing about the same products and topics, especially at the launch of a new product or feature. Marketing teams have great resources for customer analysis, and a flair for words.
- Developer relations: This is a team of people with various roles, including technical writers, software engineers, developer advocates, marketing leads, and others. The team acts as an interface between the internal teams who’re developing the products, and external developers/customers who’re using the products. The products are developer-focused, including APIs, SDKs, libraries, and so on.
- Change management: See the comments on this post for discussion.
- Any more?
Two takes on working with product teams
Recently I presented a webinar on working with an engineering team, and I attended a talk by Craig Simms on integrating more closely with a product team. It’s interesting to compare these two takes on the topic.
Webinar: Working with an Engineering Team
The ASTC (Australian Society for Technical Communication) and I recently collaborated to host a webinar on working with an engineering team. You can watch the recording below, and on Vimeo. The slides are available on SlideShare.
Click the play button to view the video above.
Talk: Integrating with Software Product Teams
At a recent Write the Docs meeting, Craig Simms presented a talk on how technical writers can integrate more closely with software teams. It’s a zestful account of the journey he and his colleague have taken towards becoming integrated with a product team, and the lessons learned during that journey. The recording is on YouTube, and embedded below.
What do you think?
Where do technical writers fit in, and do you know of any other presentations that talk about integrating with various teams?
This week we hosted the first ever Write the Docs meetup in Sydney. It was great to see so many familiar faces and to meet so many new people too.
The Sydney meetup
We had 22 attendees at the inaugural Sydney meetup. The venue was the Google offices in Pyrmont.
Swapnil was an excellent host. Between the two presentations (see below) he asked attendees to introduce themselves and say what they liked most about technical documentation or being a technical writer.
What attendees like about technical documentation / technical writing:
- I like to explain things.
- The scope of technical documentation extends all the way from consumers to developers.
- I like editing a doc when someone complains about it – that means they need it.
- I like to help things go smoothly.
- I’m married to a technical writer.
- Technical documentation says exactly what it means. It cuts out all the fluff, even when describing an error in the product.
- I get to do problem solving in a creative environment.
- I like the ability to make the documentation a tool that someone can use rather than just read.
- Technical documentation captures stuff before it’s lost.
- I truly enjoy the research that goes in before writing the docs. Discovering bugs!
Presentation: Integrating more closely with software product teams
Craig Simms, from Campaign Monitor, presented a talk on how technical writers can integrate more closely with software teams. Campaign Monitor works off an agile development process. As processes change, the technical writing team must change to keep up.
Craig’s presentation was amusing and engaging. He told the story of how technical writing started at Campaign Monitor as a community building role, but it quickly became apparent that it was a core technical writing role. Quite quickly, the two writers in the company felt that their role description and placement in the company didn’t reflect the value that technical writers bring to an organisation. They decided they needed to join a product team.
Craig described the two years of adventure he and his co-writer have had, attempting to get into a product team. They’ve not yet succeeded, Craig said with a laugh, but he gave a zestful account of the lessons learned, and the steps they’ve taken towards that goal. One of the questions that’s arisen is this: Is product the right place for technical writers? An attractive alternative is to be part of the marketing team.
This quotation from Craig’s presentation in particular rang true with me:
Define your own value, and never stop telling people.
Here’s the recording of Craig’s presentation:
Presentation: Wrapup of Write the Docs Prague
Swapnil Ogale presented his summary and take-aways from the recent Write the Docs Prague conference.
Swapnil talked about these topics:
- Why he attended the Prague conference.
- Attendee demographics – he showed a lovely picture of the venue and participants.
- Range of topics covered – wide, including fiction and health!
- A deep dive into 2 presentations he found most useful.
- The unconference part of the event – spontaneous sessions on what people wanted to talk about.
- Key takeaways from the conference.
An interesting statistic:
70% of participants are working on dev docs, APIs and UI text.
Here’s the recording of Swapnil’s presentation:
Where next for Write the Docs Australia?
I’ve been lucky enough to attend both meetings of the Write the Docs Australia group. Perhaps I can keep a good thing going and join the third, wherever it may be. Brisbane, anyone?🙂
So many options to choose from! As a technical writer in Australia, I can join a Write the Docs Australia meetup, the ASTC (Australian Society for Technical Communication), the US-based STC (Society for Technical Communication), and more. I’ve been putting some thought into the differences between Write the Docs on the one hand, and organisations such as ASTC and STC on the other. For me, they all have their place and membership of all of them is valuable.
I’m currently a member of Write the Docs Australia, and have also attended Write the Docs meetups in San Francisco, Silicon Valley and Portland. I’m a paying member of the ASTC and the STC, and support both by presenting at conferences or webinars whenever practical. I’ve also presented sessions at conferences organised by other bodies, such as TWIN and tekom.
For me, Write the Docs differs from the more formal organisations in that it’s an informal community of people interested in technical documentation. The heart of the community is a series of meetups that happen in various parts of the world. There are also a few annual conferences. You don’t need to join an organisation – you just join a meetup, and then turn up.
Write the Docs is focused on documentation, rather than on technical writing. The community explicitly welcomes anyone with an interest in technical documentation. This includes technical writers, engineers, UX designers, support engineers, editors, and more.
The primary focus of Write the Docs meetups is API docs and developer tools, but other types of tech docs are becoming popular too. It’s up to us, the members of the community, to decide what we talk about.
So, for me, there’s a place for both types of organisation, even in a community of writers as small as Sydney or Melbourne. My aims are to share knowledge, learn, meet people, and spread good cheer.
And I haven’t even touched on the various social media groups and mailing lists on Slack, LinkedIn, LISTSERV, and so on.
What brought on these musings? The first Sydney Write the Docs meetup ever is at 6pm on Thursday 3rd November. Come along if you have an interest in, or a story about, tech docs – from any perspective.
Have an idea for a talk for future meetups? Add questions or comments to this post, or add them as comments on the meetup page. Swapnil Ogale, the founder of Write the Docs Australia, would love to hear your ideas!
Technical writers have heard quite a bit recently about Markdown. Putting aside the question of whether Markdown is the right choice for technical documentation, it’s interesting as a tech writer to know more about the language itself. What is Markdown, where can we see it in action, and how can we try it out? Here are some pointers. If you have any other tips or stories about Markdown, I’d love to hear them!
Markdown is a markup language designed for quick and easy creation of simple documents. The syntax is pared down to the minimum, with the result that:
- The syntax is easy to remember.
- A Markdown document is easy to read, since much of the content is free of markup tags.
Along with the markup syntax, Markdown comes with a parser (a piece of software) that converts the markup to HTML, so you can display the document on a web page.
Other well-known markup languages are HTML, XML, reStructuredText, various forms of wiki markup, and many others.
Example of Markdown
Here’s a chunk of the above text in Markdown format, with an added level 2 heading, “What is Markdown?”
## What is Markdown? [Markdown](https://daringfireball.net/projects/markdown/) is a markup language designed for quick and easy creation of simple documents. The syntax is pared down to the minimum, with the result that: * The syntax is easy to remember. * A Markdown document is easy to read, since much of the content is free of markup tags. Along with the markup syntax, Markdown comes with a parser (a piece of software) that converts the markup to HTML, so you can display the document on a web page.
Equivalent in HTML
Here’s the same text in HTML:
<h2>What is Markdown?</h2> <p><a href="https://daringfireball.net/projects/markdown/">Markdown</a> is a markup language designed for quick and easy creation of simple documents. The syntax is pared down to the minimum, with the result that:</p> <ul> <li>The syntax is easy to remember.</li> <li>A Markdown document is easy to read, since much of the content is free of markup tags.</li> </ul> <p>Along with the markup syntax, Markdown comes with a parser (a piece of software) that converts the markup to HTML, so you can display the document on a web page.</p>
Getting started with Markdown
When I first encountered Markdown, I already knew HTML and the wiki markup syntax used in Confluence. For me, the best approach to Markdown was:
- First quickly scan the most basic syntax elements, to get an idea of the philosophy behind Markdown and to pick up the patterns. I’ve included some pointers below, to give you an idea of the patterns in the syntax. Note, though, that there are variations in Markdown syntax.
- Then find a good cheatsheet and refer to it whenever you need to check up on something. Here’s a good cheatsheet.
- If something doesn’t work, consult the full syntax guide.
Where can you try it out?
The best way to learn is to do.
- Grab my Markdown code from above, or write some of your own.
- Paste it into the text box at the top of Dingus.
- Click Convert.
- Scroll down the page to see first the HTML code and then the rendered version (HTML Preview) of your text.
Here are those pointers I promised, to get you started.
# My level 1 heading # Another level 1 heading ## My level 2 heading ### My level 3 heading #### You get the drift
No markup, just an empty line before and after each paragraph.
Put the link text inside square brackets, followed by the URL in round brackets.
Another way of doing links is to define a variable for the URL somewhere on the page, and use that variable instead of the URL in the text. This is useful if you need to use the same URL in more than one place in the document, or if you want to keep the messy, long URL away from the text.
[Markdown] is a markup language, blah blah blah - this is the rest of my page. [Markdown]: https://daringfireball.net/projects/markdown/
* My list item * Another list item * A list item embedded within the previous one * Another embedded item * An item in the main list
There must be an empty line before and after each list, otherwise it gets mixed up with the preceding or following paragraph.
There are a few ways to do numbered lists. Here’s one:
1. My list item 1. Another list item * An embedded bulleted list item * Another embedded item 1. An item in the main list
You can mix and match bulleted and numbered lists, with varying degrees of success.🙂
There’s plenty more you can do with Markdown, and there are a couple of syntax varieties to trap the unwary. For example, GitHub has a special flavour of Markdown.
Recent articles about Markdown
There’s been a fair bit of discussion about the pros and cons of Markdown recently. Here are a few of them:
- Eric Holscher wrote a popular and much commented post in March this year: Why You Shouldn’t Use “Markdown” for Documentation. Congrats Eric, this is a really great example of in depth analysis and reasoned opinion. It also sparked a large amount of impassioned conversation, which is still going on in forums around the world.
- Tom Johnson has a section on Markdown in his course on documenting REST APIS: More about Markdown.
- Victor Zverovich compares Markdown and reStructuredText: reStructuredText vs Markdown for documentation.
- Ben Cotton comparesMarkdown, reStructuredText, DocBook and LaTeX: Markup lowdown: 4 markup languages every team should know.
In my day job, I write docs in both HTML and Markdown. I prefer HTML for comprehensive technical documentation. Markdown is good for very simple documents, but the syntax becomes clumsy for more complex things like tables, anchors, and even images. On the other hand, there are excellent benefits to using Markdown for quick collaboration on a document.
As is so often true, we need to choose the best tool for each use case. It’s a good idea to get to know Markdown, so that you can form an opinion and be able to use it when you need it.