Why writing in Markdown and exporting is a good workflow
Markdown separates what you are saying from how it looks, which is why it has become the default for documentation, notes and technical writing. You write plain text with a handful of conventions — hashes for headings, asterisks for emphasis, dashes for lists — and the formatting is applied consistently when it is rendered.
The practical benefit is that you stop fiddling. Word processors invite an hour of adjusting spacing and heading sizes that adds nothing; Markdown gives you no way to do that, so the document gets written instead.
It also stays readable as plain text forever. A Markdown file opens in anything, diffs cleanly in version control, and will still be legible in twenty years, which is more than can be said for most proprietary document formats.
What converts well and what needs attention
Headings, paragraphs, bold and italic text, ordered and unordered lists, blockquotes, code blocks and links all convert predictably. For the overwhelming majority of documents — notes, README files, reports, specifications — the output needs no adjustment at all.
Tables convert, but wide ones are the usual source of trouble: a table with many columns has to fit a fixed page width, and something has to give. Keeping tables narrow, or accepting smaller text for them, produces better results than hoping the conversion will solve it.
Images referenced by a relative path need to resolve when the document is converted. This is the most common cause of a missing figure in the output, and it is worth checking the finished PDF rather than assuming, since a broken image reference frequently produces no visible error at all.
Common uses worth knowing about
Documentation is the obvious one: a README or a specification written in Markdown becomes a distributable PDF for people who will not go looking in a repository. Meeting notes and technical write-ups are the same case at a smaller scale.
Less obviously, it is a good way to produce simple formal documents. A letter, a statement of work or a short proposal written in Markdown comes out clean and consistent, and it is far quicker than fighting a template.
It also works well for anything generated by a program. Markdown is easy to produce from code, so a script that assembles a report can write Markdown and let the conversion handle presentation, rather than trying to generate a formatted document directly.
A quick reference to the syntax you will actually use
Almost every document needs only a handful of conventions. A hash at the start of a line makes a heading, and more hashes make a smaller one — one for the title, two for sections, three for subsections. Text wrapped in single asterisks becomes italic and double asterisks becomes bold.
Lists are a dash or an asterisk at the start of a line for bullets, or a number followed by a full stop for numbered lists — and the numbers do not need to be correct, since they are renumbered when rendered, which makes reordering painless. Indenting by two spaces creates a nested level.
Links are the text in square brackets followed by the address in parentheses, and images are the same with an exclamation mark in front. A line of three or more dashes makes a horizontal rule. That is genuinely enough for the overwhelming majority of documents, and everything else can be looked up on the rare occasion it is needed.
Two habits make Markdown documents convert more predictably. Leave a blank line between blocks — between a paragraph and a list, or a heading and the text under it — because renderers rely on that separation and omitting it is the most common cause of a list that fails to format. And keep heading levels sequential rather than skipping from a first-level heading to a third, which produces a document whose structure reads oddly and whose generated contents page is wrong.