Automating what shouldn't require effort: the resume as an engineering exercise
How I transformed resume updates from a repetitive task into an automated system with data validation, contracts, and CI/CD pipelines
Também em Português
Updating a resume was never hard. It was just tedious. For a long time, this was one of those processes I accepted as a natural part of professional life: open a document, update experiences, adjust dates, export a PDF, and move on. It required no intellectual effort, brought no new learning, yet it needed to be done repeatedly. Only after a few years did I realize this had a name: toil.
What is Toil?
Toil is repetitive, manual, automatable operational work with no lasting value. It’s the kind of task that doesn’t scale, teaches nothing new, and tends to grow linearly with the system. The term is widely used in SRE (Site Reliability Engineering) to identify work that should be eliminated through automation.
The problem was never the resume itself. It wasn’t the format, the editor, or the layout. The problem was repeating the same process, always the same way, with no cognitive gain. This kind of work is treacherous because it seems small, almost irrelevant, but it accumulates. It takes time, mental energy, and most importantly, normalizes the idea that certain things “are just like that.” Toil doesn’t live only in production environments or operational tasks; it silently infiltrates our daily lives.
The trap of superficial automation
My first reaction was technical, as it usually is. I switched from ODT to Markdown, then Markdown to AsciiDoc, added scripts, created templates, automated parts of the process. It worked better than before, but something was still wrong. I had automated the tool, not the problem.
Evolution of attempts
Traditional document
ODT/DOCX manually edited. Each update required opening the editor, formatting, and exporting.
Markdown + Scripts
Migration to plain text. Improved versioning, but still manual duplication for each language.
AsciiDoc + Templates
More formatting power, but the fundamental problem persisted: data and presentation mixed together.
Structured data + Schema
The resume stops being a document and becomes validated data. Templates are just renderers.
Beware of superficial automation
Changing technology without changing the mental model is a common trap when we talk about automation. You can have the most sophisticated pipeline in the world, but if the fundamental problem wasn’t addressed, you’ve just automated inefficiency.
The turning point: data, not documents
The turning point happened when I stopped treating the resume as a document and started treating it as data. By adopting a formal resume specification based on a schema, it became clear that the information needed a contract. From the moment data became validated, versioned, and structured, the final format stopped mattering. HTML, PDF, or any other output became just different representations of the same set of information.
- 1
Separation of data and presentation
Resume information lives in structured data files, following a defined schema. Templates only transform this data into readable formats.
Common vs. specific data
Name, email, links, and shared experiences exist in a single place. Language-specific data (descriptions, summaries) are isolated in separate files.
Automatic merge and validation
A simple process combines common data with language-specific data, validating against the schema before any rendering.
Multiple outputs, same source
HTML, full PDF, one-page PDF — all automatically generated from the same source of truth.
This change in perspective solved problems that previously seemed “natural.” Having versions in Portuguese and English no longer meant content duplication.
System architecture
The diagram below shows the data flow from YAML files to the final artifacts — three output formats for each language, all generated from the same source of truth:
The flow is straightforward:
- YAML Data is the source of truth —
common.yamlcontains shared data (name, contacts, experiences), while language files (resume.en.yaml,resume.ptbr.yaml) contain only translations - Validation against JSON Resume Schema ensures data correctness before any processing
- Typst merges the data and applies templates, generating 3 formats for each language: full PDF, one-page PDF, and HTML
The resume as an application
At some point in this process, the resume stopped being a file and became an application. Today, it goes through a build pipeline like any other project: data is validated, artifacts are generated, and everything is published automatically. The result is always predictable and reproducible.
The HTML site and PDFs — both the complete version and the condensed one-page version — are generated from the same source of truth. If something breaks, the pipeline catches it. If something changes, the update is trivial.
Pipeline as living documentation
When the build process is codified in a pipeline, it serves as executable documentation. Anyone can understand how the system works simply by reading the workflows — and can trust that this documentation is always up to date, because it is the process.
Overengineering or investment?
It’s easy to look at this process and call it overengineering. And, in a way, maybe it is. But this criticism misses the central point.
The goal was never the resume. It was just a means. A controlled ground to experiment with automation, data contracts, validation, and continuous publishing without real risk. Everything learned there transfers directly to much larger and more critical problems.
Schemas aren’t bureaucracy — they’re guarantees. When data goes through validation before being used, errors are detected at the source, not in production.
Data, transformation logic, and presentation are distinct layers. Changing one shouldn’t require changes to the others.
If something can be automated and doesn’t add human value in manual execution, automate it. The recovered time is real.
Personal projects are perfect laboratories for testing ideas before applying them in higher-risk contexts.
The real lesson
Ultimately, the lesson has nothing to do with career, documents, or specific technology. It’s about learning to identify tedious, predictable, and repetitive processes and consciously deciding not to accept them as inevitable.
Whenever a task stops teaching something new, it becomes a candidate for automation.
Not to show technical sophistication, but to return time and energy to what really matters.
The fundamental principle
Automation, at its core, is not about modern tools or elegant stacks. It’s about respect for your own time. If something no longer requires thought, maybe it’s exactly the kind of thing you shouldn’t do manually ever again.
Appendix: practical implementation
As a practical complement to all this, it’s worth showing how this idea materializes. Everything described above is published and can be inspected both from a usage and implementation perspective.
Published versions
The HTML versions of the resume are the most visible entry point. They are automatically generated from the same database and published as a static site:
Besides HTML, the same pipeline generates PDFs. For each language, there are two variations: a complete version and a condensed one-page version:
English PDFs
Portuguese PDFs
Source code
All the implementation that enables this process is in a public repository:
fabioluciano/resume.fabioluciano.com
Complete source code: data, templates, validation, and CI/CD pipeline
github.com
The repository structure clearly separates responsibilities:
Templates don’t know about language, version, or context; they just receive valid data and know how to transform it into HTML or PDF. This clear separation between data and presentation is what makes the system extensible and sustainable over time.
Finally, the entire validation, generation, and publishing process happens automatically via workflows. The pipeline ensures data complies with the schema before any artifact is published. If something is inconsistent, the build fails. If something changes, everything is regenerated predictably.
The value is not in the resume itself, but in the process. The resume is just concrete evidence of a broader idea — identifying toil, creating clear contracts, and automating what shouldn’t require repeated human effort.