My company has a performance management platform.

Every month you write in what you accomplished, per project. It has a fixed hierarchy and notation rules.

At first I naturally wrote straight into that format.

But months later, reopening it, I couldn't read my own writing.

Text optimized for a form isn't written for a human to read. It's written to be fed into a system.

And there was a bigger problem. When I tried to summarize the year at year-end, the raw material existed only inside that format, scattered.

I Separated Source From Output

I brought over exactly what I do in frontend work.

Don't write the source in the output format. Write the source for humans, and transform it into output.

entries/YYYY-MM.md      ← source. Human-readable. Accumulated continuously
        │  transform (by a defined rule set)
        ▼
sgate/YYYY-MM.md        ← company-format output. Paste as-is

The source is written for me to read. What I did, why, and how it turned out, in sentences.

The output is built to be fed into a system. Notation and hierarchy exactly as the company form requires.

Splitting them solved two things at once.

  • I can read it later (because the source is in human language)
  • If the company form changes, the source doesn't (only the transform rules change)

It isn't writing the same information twice — it's writing once and extracting it two ways.

Structurally identical to how a blog produces list pages, detail pages, RSS, and sitemap from a single MDX file.

A Project Axis, Not Just a Time Axis

Monthly files alone weren't enough.

They answer "what did I do this month," but they can't answer "how has this project moved along until now."

That's scattered across twelve files.

So I added a second axis.

entries/       ← time axis. 2026-01.md, 2026-02.md, ...
by-project/    ← project axis. gongjang.md, parking-platform.md, ...

The same event goes into both. It looks like duplication, but each answers a different question.

  • The time axis answers "when, what" — used for monthly reporting
  • The project axis answers "how did this project evolve" — used for retrospectives and handoffs

In database terms, I built two indexes.

If there are two read patterns, there should be two indexes — I applied the same idea to documents.

The Raw Material Already Existed — Git

This is the part that got easiest.

Reconstructing "what did I do this month" from memory at month's end is hard. And writing from memory keeps only the memorable and drops the consistent.

But the raw material was already there. Commit logs.

I wrote a script that gathers each repository's change history weekly, and used that as the starting point for the source file.

Of course, commit logs don't become accomplishments as-is.

fix: typo is not an achievement. So rather than transcribing logs, I added a step that merges them by theme.

Twenty commits become one line: "implemented drag-to-reassign on the review board."

And the work that leaves no trace in git — meetings, negotiations, documentation, helping someone else — gets filled in by asking.

Automate what can be gathered automatically; humans supply only what isn't there.

Trying to automate everything fails; doing everything by hand means you stop doing it. Somewhere in between was right.

An Unexpected Payoff — Negotiation Material Accumulated by Itself

When I built this, I was just trying to make a monthly chore easier.

There was an upside I hadn't expected.

When salary negotiation season came, there was nothing to prepare.

The project-axis files already held what I did, when, and how — in sentences.

Instead of squeezing my memory to manufacture "here's what I accomplished," I just organized what was already there.

That difference was bigger than I expected.

Relying on memory overweights the last two or three months and drops everything from early in the year entirely.

And people forget their own work in the direction of underestimating it. You remember that something was hard; you don't remember how much of it there was.

Records prevent that distortion.

To Sum Up

  • Don't write the source in the output format. Source in human language, output by transformation
  • Two read patterns means two axes. Time axis and project axis
  • Automate what can be gathered automatically. Git logs as the starting point; humans fill the gaps
  • Don't transcribe logs directly. You need a step that merges twenty commits into one line

Looking back, this is just a development principle moved over to work records.

Keep a single source of truth and derive everything else.

The core shift was going from recording in order to report, to extracting reports from records.

And because this is something I do for myself rather than because the company asked, it stays with me even if I change companies.