Updating a resume sounds small until you try to do it properly.
You change the content, then you need a clean PDF. Then a web version. Then you decide the web version should be deployed like everything else. Suddenly you are no longer editing a document. You are maintaining a pipeline.
That was the real experience this time.
The source lived in markdown. The output had to become a static page. The page had to go into a Docker image. The image had to reach the server. And somewhere in the middle, the whole thing got stuck in the most familiar developer state of all: not broken enough to panic, not working enough to finish.
the cv is now a small system
A CV used to be one file. In practice, it isn't anymore.
You need one version that is easy to edit, one that looks good when you send it, and one that works on the web. If you are doing technical work, you also need a way to update it again next month without starting from zero.
That's why markdown was the right place to start.
Markdown keeps the content clean. It works well with version control. It doesn't trap you inside layout decisions when what you really need is better wording.
Most resume pain is fake design work. Spacing. Fonts. Bullet tweaks. Tiny cosmetic edits that eat an hour and solve nothing.
Plain text is less glamorous, but it keeps the attention on the part that matters: what did you actually do, and how do you explain it honestly?
then the boring technical problems arrived
The plan was straightforward:
- update the CV in markdown
- render the site
- build the image
- push it
- deploy it
Then the usual nonsense showed up.
Git credentials started asking for attention. The image push got denied. Every step felt close enough to done that it was tempting to keep pushing without stopping to rethink the flow.
That is where time disappears.
Big failures are easier. At least they are clear.
The annoying problems are the half-failures. The ones that leave you in that ugly middle state where each next step looks like it might work, so you keep going for another ten minutes, then another thirty.
By the end, the technical issue is almost secondary. What really hurts is the drag.
this is what modern admin work feels like
People talk about resumes as if they were only about positioning.
How to frame your story. How to present your experience. How to look coherent in a market that changes every six months.
That part is real. But there is another part that gets less attention: operational friction.
A lot of professional work now depends on small systems that almost work.
The content is ready, but the export is stale.
The export is fine, but the site is outdated.
The site is ready, but the deploy path is wrong.
The deploy path is correct, but the credentials are stale.
So the task stops being "update my resume."
It becomes: fix the path between the content and the public version.
the useful shift
The best takeaway from this was simple: stop treating important personal documents like random files.
Treat them like small products.
Not products in the startup-bro sense. Just in the practical sense.
They need:
- a clean source
- a repeatable build path
- a boring deploy
- less room for mystery next time
That mindset changes the work.
Instead of improvising every update, you build a path that future you can trust.
And trust is the whole game with this kind of thing. Not because the document is sacred, but because attention is limited.
what mattered in the end
In the end, the important part was not Docker, Git, or Swarm.
It was being able to update the CV without turning it into another messy evening of manual fixes and forgotten steps.
The infrastructure around a document should not be more stressful than the document itself.
That was the lesson.
A resume update in 2026 is still a writing task.
It just comes with a deployment pipeline attached.