kvch.me

An engineer's work log without the busywork

I have tried to keep a digital work log since I became a software engineer. The benefits were obvious: I could look back at past decisions, preserve important lessons I had learned, and have everything I needed when writing self-reviews for performance evaluations.

Every attempt failed after a few weeks because documenting my day took almost as much effort as doing the work. Now I think I have stumbled onto something I can actually keep doing long term.

In this post I am walking you through how I made tracking my daily tasks, decisions and context easier using an AI skill. I am also sharing surprising consequences of adopting AI for work logging.

Why I wanted to log my work

For years I wanted to keep a digital record of my work because I kept forgetting what I did and the context behind the things I had done.

A few months after investigating an incident, I could barely remember what the root cause was or how we fixed it. I would approve a pull request after carefully reviewing the design, only to forget why I thought it was the right solution. During meetings I captured important decisions and ideas in my notebook, but after a few weeks they had faded from memory. The notes were still there somewhere in my notebook, but it was too slow to find the right note. Not to mention that I might just jotted down a few words with little context. So even if I found the note, I might not be able to decipher what I wrote down.

Besides helping me in my day to day work, it can also be used for writing self-reviews. I wanted to show my value to the company. Performance evaluations are important to get right. Every self-evaluation required reconstructing months of work from memory, pull requests, calendar events, and issue trackers. Having everything captured in one place would make that process more efficient, and I no longer risk of forgetting something important.

Digital work logs are searchable. So I needed one.

My struggle with manual tracking

The central work log of my career has always been captured in physical notebooks. Every TODO, every meeting, every idea was captured in a notebook using the rapid logging method. It felt great to dump everything on a piece of paper. However, as you can imagine it was a nightmare to look back at past logs. So I attempted multiple times to track important milestones, daily decisions digitally. My logs were finally easy to search, but it was hard to maintain. The longest streak I had for tracking my work for 2-3 months in a Notion page.

Keeping the digital work log up to date required a tremendous amount of discipline. Every evening I had to reconstruct my day from pull requests, issues, my notebook, calendar events, and whatever else I had touched. It was busywork. I hate busywork, so I gave up.

I can just use my notebook, and never really look back on what I did in the past. I told myself that these logs are only useful for a short period of time to help me cope with my failed attempts.

How AI helped me stick with it

As I mentioned in the introduction, I have created an AI skill to track my work. It takes at most 15 minutes a day to run through this process.

I leverage AI in multiple ways:

Daily activity collection

Now my AI session runs the most mind-numbing part of work logging for me. It collects my daily activity:

Activity categorization

My progress tracking has two layers: daily activities and projects. I have a separate projects file that contains each project I am working on. It has a description, impact, stakeholders, and hints for the LLM for categorizing my activities. Most of my daily actions are connected to my bigger projects.

Daily interview

This is the last phase of the work logging. The AI asks me if there were any important decisions, incidents, deployments during the day that is missing from the activity collection. In this step I sometimes add more context to decisions or incidents. But most of the time I skip it unless there was an unexpected incident or an important meeting.

What I log

My logs are very detailed, I try to capture as many things as I can because AI handles the tedious work.

Sample daily log

As activity fetching and project correlation is delegated to an LLM, I can focus on providing the missing details and nuances to my work. I can keep detailed records of my everyday tasks.

Critical points to capture:

  1. my main goal for the day and its outcome
  2. activities on my or my colleague's project
  3. incidents, investigations, bug fixes
  4. proposals, notes, documentation
  5. meetings from my calendar, important decisions made in calls
  6. important shell commands (recovery from incidents, etc.)

You can read an example daily log: (I have redacted several things that I did in private repositories.)

---
date: 2026-06-11
main_goal_outcome: landed
projects: [onboarding, pa]
pr_numbers: [xataio/pgstream#871, xataio/pgstream#882, xataio/pgstream#883, xataio/pgstream#884, xataio/pgstream#885, xataio/pgstream#886, xataio/pgstream#887, xataio/<private-repo>#<issue-number>]
issue_numbers: []
repos: [xataio/pgstream, xataio/<private-repo>]
worktrees: [pgstream, plan-async-jobs-onboarding, onboarding-snapshot-experiments]
decisions: [Pgstream v0.9.x release next week is the LAST v0.9.x release — users will be asked to upgrade after; Once pgstream v1.1.0 ships, xata CLI will bundle the new pgstream with the --update flag enabled (cleanup-0.9-objects-and-reinit, mechanism from pgstream#788)]
incidents: []
---

# 2026-06-11

## Main goal

- **Goal:** Continue pushing pgstream — queued 2026-06-10.
- **Outcome:** ✅ landed — five of yesterday's pgstream PRs merged (`#882`, `#883`, `#884`, `#871` community, plus indirect closes); two v0.9.x backports merged (`#886`, `#887`); new flaky-tests PR opened (`#885`); pgstream **v1.1.0 release blog post drafted** (`docs/blog/pgstream-v110.md`) and shared with the team for review; pgstream sync produced the v0.9.x-final + xata-CLI-`--update`-bundle decisions captured in front matter.
- **Why it was #1:** "Signal pgstream is alive" has crystallized into a real **launch schedule** — v1.1.0 publish target is **~Wed 2026-06-17** (blog post pending team review). Keeping the daily PR/backport cadence is what makes that date hold.

**Tomorrow's main goal:** Plan next release of pgstream **v1.2.0**.

## Projects (led)

### Data onboarding (`onboarding`)

- **Status:** Launch-week prep for pgstream v1.1.0 holding the line — blog post in team review (target ~Wed 2026-06-17), yesterday's PR queue cleared, both v0.9.x backports landed, flaky-test cleanup opened today. Plus an exploratory Fable-driven scaffold of the async-jobs framework (`<private-repo>#<pr-number>`, closed) — sandboxing, not impl.
- **Commit:** `xataio/pgstream` `94f8678` "fix two flaky tests" (worktree `pgstream`, branch `fix-flaky-tests`) — pairs with `#885`.
- **PR:** `xataio/pgstream#885` Fix 2 flaky tests — **open** (authored, branch `fix-flaky-tests`).
- **PR:** `xataio/pgstream#884` Eliminate panics in transformers when multiple workers are configured — **merged today** (the `transformers-in-parallel` refactor opened 2026-06-10).
- **PR:** `xataio/pgstream#883` New target: `stdout` — **merged today** (opened 2026-06-10).
- **PR:** `xataio/pgstream#882` Add new healthcheck endpoints: `/health` and `/ready` — **merged today** (opened 2026-06-10).
- **PR:** `xataio/pgstream#871` Add optional processor to strip null bytes from string columns by @blurskye — **merged** (community PR).
- **PR:** `xataio/pgstream#887` [Backport v0.9.x] Collect all error messages before stopping pgstream — **merged**. v0.9.x backport of `#841` (which itself merged 2026-06-08).
- **PR:** `xataio/pgstream#886` [Backport v0.9.x] Eliminate panics in transformers when multiple workers are configured — **merged**. v0.9.x backport of `#884` (merged today, on the same day — fast turnaround thanks to the `#830` backport automation).
- **PR (closed, not merged):** `xataio/<private-repo>#<pr-number>` Init async job executor — **closed**. Was a Fable-assisted exploratory pass at scaffolding the async-jobs framework designed 2026-05-28 (`docs/async-jobs-framework.md`). Closed because the async-jobs framework is a **huge body of work**, not a one-PR effort — this was sandbox play to see what Fable would produce, not a real implementation push. The framework still wants a real, staged implementation later.
- **Older PRs surfaced by the backport mechanism** (no action expected): `#841`, `#833`, `#788`, `#760` — state updated as their commits were referenced from `#886`/`#887` and the backport label flow.
- **Decision:** Pgstream **v0.9.x release next week is the LAST v0.9.x release** — users on v0.9.x will be asked to upgrade. (Source: pgstream sync today.)
- **Decision:** Once pgstream **v1.1.0** ships, **xata CLI will bundle the new pgstream with the `--update` flag enabled**. The `--update` flag is the cleanup-0.9-objects-and-reinit mechanism shipped by `pgstream#788` "Add upgrade flag that cleanups 0.9 objects and reinits". So the cutover for existing xata-CLI users is automatic after v1.1.0. (Source: pgstream sync today.)
- **Meeting:** pgstream sync — produced the two decisions above. Target publish date for the v1.1.0 release blog post is **~Wed 2026-06-17** (blog post draft is `docs/blog/pgstream-v110.md`, currently in team review).
- **Docs new:** `xataio/pgstream/docs/blog/pgstream-v110.md` — v1.1.0 release announcement blog post (draft, in team review, target publish ~Wed 2026-06-17).
- **Docs touched:** `xataio/pgstream/docs/configuration.md`, `cli.md` (likely follow-on docs for the merged PRs).
- **Doc that turned out unnecessary:** `xataio/pgstream/docs/schema_only_clone_issue.md` — drafted via `l3afpad` to spec a "schema-only clone" feature, then dropped: **schema-only snapshots are already supported in pgstream**, and the original use case (schema-only branching) can already use that path. Future-you should not interpret the file's existence as a real open spec.
- **Open:** Land `#885` (flaky tests); v1.1.0 blog post review feedback; v0.9.x final release prep next week; start v1.2.0 planning (= tomorrow's main goal).

### Product analytics (`pa`)

- **Status:** Staging PA database fixed — roles set up correctly now. Pure ops recovery, no PR or commit on PA side today.
- **Bug:** Staging PA database failed to reconcile the **superuser** via CNPG because the **`<role-name>` role** was set up incorrectly — the bad role shape blocked CNPG's managed-roles reconciler, which then refused to apply any role changes (including the superuser one). Symptom surfaced as a stuck `managedRolesStatus.cannotReconcile` on the cluster status subresource.
- **Recovery:**
  1. Clear the stuck status: `kubectl patch cluster <cluster> -n <namespace> --subresource=status --type=merge -p '{"status":{"managedRolesStatus":{"cannotReconcile":null}}}'` — drops the `cannotReconcile` block so CNPG retries reconciliation. (Cluster ID is the staging PA Xata-branch cluster.)
  2. Open a superuser `psql` via kubectl plugin
  3. Re-grant role membership inside psql, e.g. `GRANT reader_group TO reader_user GRANTED BY postgres;` (pattern — actual grants depend on which roles got mangled).
- **Shell — recipes worth keeping:**
  - `GRANT <group> TO <user> GRANTED BY postgres;` — the role-grant form that worked here (with explicit `GRANTED BY postgres` so the grantor is the superuser, not the current session role).

## Reviews / cross-project contributions

- `xataio/<private-repo>#<issue-number>` [merged] [OrgLimits] Add createdAt index — `[<private-repo>]`, reviewed. Indexing follow-up on the OrgLimits work (related to the merged `#<pull-number>`); not in a user-led project.

Project tracking

Apart from daily logs, I keep a separate project tracker as well. It contains high level things like description, status, business value, etc. I keep projects in a separate file. You can see an example project from my log:

led_projects:
  - slug: pooling
    name: Connection pooling
    status: delivered
    meta_ticket: xataio/<private-repo>#<isssue-number>
    # Milestone 1 delivered 2026-05-21.
    next_steps:
      - Pooling for replicas, not scheduled, xataio/<private-repo>#<isssue-number>
    goal: >
      Ship a built-in PgBouncer pooler on every Xata branch, with auto-PAUSE/RESUME
      on switchover and failover — pooling that's transparent to customer apps.
    business_outcome: >
      We regularly get notifications from users hitting their database's
      max_connections limit. These users can leverage the pooler to multiplex
      thousands of clients onto a stable Postgres connection set; the alerts
      go down and the customer pain (and support load) goes with them.
      Also makes Xata viable for serverless / edge / agentic workloads where
      connection churn is high.
    repos:
      - xataio/xata-cnpg
      - xataio/<private-repo>         # only when keyword matches
    keywords:
      - pooler
      - PgBouncer
      - pgbouncer
      - cnpg_pooler_pgbouncer
      - PAUSE
      - RESUME
      - poolerIntegrations
      - "Connection pooler"
    worktree_hints:
      - pooler
      - cnpg

Separating planning from logging

You might ask if I abandoned my notebook in favour of digital logs. I did not. I have realized that writing in my notebook was about planning my day. My plans can go out the window in an blink of an eye. An incident comes in. Someone needs help. Or I spend half the afternoon waiting for access to a testing environment. By the end of the day, my notebook no longer reflects reality.

Logging my day became a separate part of managing myself. At the end of the day I capture what I did and what I learnt. I use it to find records of decisions, how I managed a past incident if it happens to show up again. My work log now captures important information for the future me.

In the evening I still write my future TODOs in my notebook. Putting plans on paper feels good. But only the things that really happened are supposed to land in the work logs. The work log is not a future log. It is a record of what actually happened.

Lessons learnt

Garbage in, garbage out

You can only get out as much as you put in. The skill can automate and capture many things for you, and the interview format is very useful. However, it is you who is responsible for deciding what is important to keep and what needs to be discarded. Furthermore, you are responsible for providing enough enough context that the future you can understand your past actions.

Using the LLM as a coach

After a few weeks I asked it if it noticed any patterns in my work. It pointed out one task that kept slipping every week. I hadn't realized how much mental energy it was consuming until it called it out. I finally did it the next day, and the background frustration that was building up in me disappeared almost immediately.

It also highlighted repetitive tasks that were good candidates for automation. It identified things that was part of my routine, but doing it manually did not provide any value.

Surprising benefit of saving visited web pages

As I mentioned in the section "Daily activity collection", I am loading every documentation page I read in Hister.

On a Friday I asked what I could improve the following week. Instead of giving generic advice, it pointed me to section in a page I did not read. I opened the page just to copy-paste an S3 bucket URL, and never went back. But Hister fetched the whole page, and the LLM read everything. It found that the data set I needed will be released in Parquet format next week, eliminating an unnecessary data conversion step I had planned. So it could have saved me days of work.

The only hiccup in the story is that the Parquet format was not released as promised on the page. Unfortunately, it did not help me in the end. But the possibility is exciting.

Build your own work logging skill

One thing I deliberately did not show in this post is the actual AI skill. I am not going to share the exact skill because you need to experiment with it on your own.

The skill should be tailored to you. Mine knows where to look because it understands my environment: GitHub repositories, directory structures on my computer, calendar, Hister history, AI conversations, project tracker, and the structure of my daily logs. You can start building your own skill easily.

Start with a simple prompt:

capture an engineer's daily work log with structured,
LLM-optimized sections covering commits, PRs, issues,
decisions, coding sessions, bugs diagnosed, deploys,
rollbacks, and incidents

For me, that meant collecting pull requests, issues, meetings, and documentation I had read. For someone else it might be Jira tickets, Slack threads, design documents, or terminal history.

The goal is to reduce the friction of data collection.

Once you stop spending your energy collecting information, you can spend it on the part that actually matters: recording the decisions, trade-offs, and lessons that future you will want to remember.

What is next?

I have only been using this workflow for a few months, so I do not want to oversell it. But it seems that adding AI to workflow removed enough of the friction that I finally stick with the habit.

If I am still using it a year from now, I will write a follow-up.