arnau díaz

dev log

2025 / 10 / 16  ·  trust  ·  4 min

This year I started a development log for my work notes. It made me far more effective. I know what I am doing, who I am doing it with, and what came of it.

Tools support the method. Pick one you will actually use; the method is what does the work.

What I would keep if I started again:

  • adapt the tool until it feels natural, then stop touching it
  • clarity beats volume
  • use references so navigation is fast
  • a note is useful if it moves a decision, an action or a result
  • a note is useful if you can hand it to somebody else

Structure

I use Apple Notes. It is simple, it has tags and search and note references, it syncs with my work phone, and it works for me.

  • WIP: when I start a task I start a document
  • Meetings: every meeting gets a note. Decisions captured, owners named, dates set (20251006 - API migration)
  • Weekly: WIP plus Meetings for the week
  • Monthly: four weeks
  • Resources: where a WIP goes when it is done. These become stable references
  • Success: notable outcomes, for when review season arrives

DIA

I like DIA because it is simple and structured. If you are not familiar with it:

  • decision: a choice made. The option picked, the alternatives, the constraint that mattered
  • information: facts worth keeping. People, context, metrics. No opinions
  • action: work that changes something and has a measurable outcome. Start, owner, deadline, definition of done

This is an implementation detail. Take notes in a way that makes sense to you.

Example

We are working this quarter on an API migration.

WIP 20251006 - migrate API

I create a file 20251006 - migrate API under WIP.

Monday 20251006
- Context: Migrate legacy API to new architecture. First review tests and documentation.
- Notes: 
  - I: Current API handles 10k requests/day
  - D: New architecture needs to use Go API.
  - A: I will work on reviewing first.

Tuesday 20251007
- Context: Continue review and prepare migration path.
- Notes:
  - I: Staging environment ready, tests green.
  - D: Create migration scripts for schema changes (15 tables affected).
  - A: Draft migrations today, review with @XXX and @YYY tomorrow.

Weekly 202510 - 01

- WIP: >>20251006 - migrate API
- Meetings: >>20251008 - migration sync
- DIA
  - D: Blue/green deployment under evaluation.
  - I: 15 tables to migrate; staging ready; tests green.
  - A: Finish migrations by Fri; pair with @XXX on data checks; schedule review with @YYY.

Monthly 202510 - October

Ref: >>Weekly 202510 - 01

DIA
- D: Blue/green deployment chosen; migration approach validated.
- I: 15 tables migrated; staging parity achieved; zero downtime deployment.
- A: Monitor production metrics for 2 weeks; plan next migration phase.

When WIP is done

The document moves to Resources. Now it is a stable reference I can search a year later.

If the notes turn out to be useful to anyone else, I expand them into a guide or a runbook. That is how a private note becomes a team document.

I also keep a Success folder for work I am proud of. Nobody remembers what you did in March when it is November, including you.

My day to day

I tried two ways of keeping this current.

  • move information from Weekly to Monthly on Mondays and Fridays
  • update WIP, Weekly and Monthly every day

Both work. I use the second because it has less friction, and less friction is the only reason any of this survives contact with a busy week. WIP moves to Weekly, Weekly moves to Monthly. Because everything is a reference I do not need to be verbose; if I need the detail I jump to the source in Resources.

Start with one folder. Add the others when you feel the need.

Results

  • I always know who is on what and why
  • I find decisions, information and actions fast
  • I skip more meetings, and standups are shorter
  • I finish more actions with fewer loose ends
  • I have more docs worth reading
  • Review season is a matter of reading, not remembering