Back to Blog

My CV is no longer a document

·4 min read

Until last week, updating my CV meant making the same edit in several places and hoping I remembered them all.

There was a Markdown version in Google Drive, a hand-maintained page on my website, a downloadable PDF, and another copy feeding the tool I use to judge job ads. They all described me, though not reliably in the same words.

Which one was the CV? Annoyingly, the answer depended on which tool was asking.

I could update one copy, close the laptop feeling finished, and still leave an old version on the website or feed an old PDF to the job-search tool. Nothing broke. A stale CV is very good at looking current, especially when the filename already says 2026.

Everything still looked current

Version drift doesn't complain the way most breakage does. If I changed an achievement in the Google Drive copy, the website did not know. If I fixed the website, my job-search tool could still be reading an older PDF.

Part of the problem was that the CV had quietly picked up readers. The website publishes it, and a job-search tool reads it when comparing my experience with job descriptions. Every tailored application I send starts from it too. The more places I connected to the CV, the more opportunities I created for a plausible old version to survive.

As a technical writer, I should probably have recognised the problem sooner. I would never recommend this arrangement for a documentation set, yet I'd somehow accepted it for my own career. I had built a tiny content governance mess around my name. But you know the idiom: "The shoemaker's children go barefoot".

One source, several versions

To solve this problem I decided to create one source of truth, and make everything else derive from it.

A web CV and a PDF have different jobs. The web version should work on a phone and feel like part of the site. The PDF needs a compact layout that travels well and remains friendly to the systems employers use to parse applications. One layout would make at least one of them worse.

So I made one plain Markdown file the only place where I author the full CV. The website turns that content into its own HTML presentation, and a separate template turns the same content into a PDF. The job-search tools read the Markdown directly.

This doesn't mean however that all copies are exactly the same. Some copies should still be separate. A tailored CV is a record of what I sent to a particular company on a particular day, so it stays frozen in that application folder. My homepage summarises my experience rather than repeating the full CV. Those copies have separate jobs; only the Markdown owns the full CV.

I made stale fail loudly

My old workflow depended on me remembering a checklist: Update the source, regenerate the PDF, copy it to the right place, check that the website has the same wording, remembering which tool reads which file. The list got bigger as time went by and I have to confess my memory is not what it used to be.

Now the website refuses to build when the PDF doesn't match the Markdown. If I change the source and forget to regenerate the downloadable version, it stops and tells me what to do. I do not have to become more disciplined forever. The system catches the most predictable way I will eventually get it wrong, which is much more useful than another checklist taped to the side of my monitor.

The question I should have asked

Where is this information actually authored? Every tool I plugged into the CV made that question more important, and I forgot to stop and ask it.

This is familiar territory for a technical writer. We think about sources, generated pages, deliberate adaptations, and stale content all the time. But somehow, because the material was personal, I had stopped applying the same type of thinking I've been using for so many years now.

Now I edit one full CV and everything else follows from it. It still leaves the house as a web page and as a PDF adapted to whichever job I'm applying to, only now every copy traces back to the same file.