Anwendungsfall

Entwickler-Tagebuch

Deine Arbeit, festgehalten, bevor das nächste Standup beginnt

Du pushst Commits und öffnest Pull Requests auf GitHub, klärst Reviews in Slack, bewegst Tickets durch Linear, sitzt in Standups und Sprint-Reviews in Google Calendar und trackst Fokus-Blöcke mit Toggl. deariary fügt das alles jeden Morgen zu einem einzigen Eintrag zusammen: ausgelieferte Commits, die Threads, die zählten, bewegte Tickets und die Stunden, die du tatsächlich im Flow verbracht hast.

Zu verbindende Dienste

Registriere dich bei den folgenden Diensten und aktiviere das Tracking (z. B. GitHub-Commit-Events, Slack-Workspace-Zugriff, Toggl Time Entries).

GitHub Erfasse deine Coding-Aktivitäten automatisch Slack Halte deine Gespräche und Highlights fest Linear Verwandle deine Linear-Aktivität in ein Protokoll dessen, was du ausgeliefert hast Google Calendar Verwandle deinen Terminplan in Tagebuch-Kontext Toggl Track Sieh, wohin deine Zeit wirklich geht

Ein Tag in deinem Leben

9:00 Uhr

Standup startet. Der Tag enthält schon Sprint-Review um 14 Uhr, ein 1:1 mit dem Lead um 16 Uhr und zwei Review-Blöcke dazwischen.

9:45 Uhr

Nehme DEV-482 ("Fix rate-limit backoff on ingest worker") und ziehe es in In Progress.

10:30 Uhr

Starte einen 90-minütigen Fokus-Timer auf dem Ticket. Kopfhörer auf, kein Slack, erster Block echter Arbeit.

13:15 Uhr

PR #1421 gegen das Ingest-Repo geöffnet. 14 Commits, 6 Dateien angefasst, CI beim ersten Lauf grün.

15:00 Uhr

Review-Anfrage in #eng-reviews gepostet. Ein Thread entsteht, 8 Nachrichten, ein guter Vorschlag zu Jitter.

18:40 Uhr

DEV-482 auf Done umgestellt, mit angehängtem PR-Link. Der Laptop geht ausnahmsweise vor dem Abendessen zu.

Nächster Morgen

Dein Devlog wartet schon. Tickets, Commits, Reviews, Meetings und Fokus-Stunden, alles in einem Eintrag.

Beispiel-Tagebucheintrag

Samstag, 14. März 2026

Pläne & Meetings

Standup, Sprint-Review und ein 1:1 mit dem Lead. Der Kalender sah schon beim ersten Kaffee dicht aus, aber die zwei Review-Blöcke dazwischen haben lang genug gehalten, um wirklich etwas auszuliefern.

Das Sprint-Review deckte den Ingest-Zuverlässigkeitstrack ab. Das 1:1 landete beim Scope für nächste Woche, leicht gestutzt.

Code & Tickets

DEV-482 "Fix rate-limit backoff on ingest worker" am Ende des Tages geschlossen. PR #1421 gegen das Ingest-Repo geöffnet mit 14 Commits in 6 Dateien, und CI ging beim ersten Lauf grün (ein kleines Wunder).

Ein Review-Thread entstand in #eng-reviews, 8 Nachrichten tief. Ein guter Hinweis, Jitter zum Backoff hinzuzufügen; noch vor dem Merge eingearbeitet.

Fokus & Rhythmus

Zwei Toggl-Blöcke, 4h 20m fokussierte Zeit. Der Block um 10:30 Uhr trug das Ticket bis zum PR. Der Nachmittagsblock war kürzer, aber genug, um Review-Feedback zu adressieren und an einem flaky Test zu pairen.

Gespräche

Hin und Her in #eng-reviews zur Backoff-Änderung. Nebenthread in #infra über das nächste Ingest-Deploy-Fenster, mit einem Screenshot des Dashboards nach dem Fix.

Ein Standup, ein grüner CI-Lauf, ein Review, das sauber gelandet ist, und ein Ticket, ausgeliefert vor dem Abendessen. So ein Tag verdient sich ein kleines Feierbier.

Highlights

ingest-worker / Pull Requests 2 geöffnet, 1 merged

api-gateway / Pull Requests 1 merged

ingest-worker / Issues 2 geöffnet, 1 geschlossen

Ingest / Abgeschlossene Issues 3

ingest refactor / Erfasste Zeit 4h 20m

Fotos & Videos

Pairing an einer Papierskizze des Ingest-Backoff-Flusses

Ubuntu-Terminal, das am Ende des Tages grün leuchtet

Deine tägliche Routine

Vollautomatisch

Commits, PRs, Reviews und Issue-Aktivität aus jedem Repo, das du anfasst.
Nachrichten, die du in verbundenen Channels sendest, Threads, in denen du antwortest, und Reaktionen, die du bekommst.
Tickets, die du öffnest, bewegst oder schließt. Statusänderungen und Kommentare werden erfasst.
Standups, Reviews und 1:1s aus deinen Arbeitskalendern.

Einmal einrichten, dann laufen lassen. Du musst nichts von Hand loggen, damit es im morgigen Tagebuch auftaucht.

Liegt bei dir

Starte einen Fokus-Timer vor einem Deep-Work-Block, stoppe ihn, wenn du fertig bist
Schreib eine PR-Beschreibung, die das Warum erklärt, nicht nur das Was
Wirf einen Screenshot oder eine kurze Notiz in einen Review-Thread
Hinterlass einen Kommentar bei einem Ticket, wenn sich eine Entscheidung ändert, nicht nur, wenn es geschlossen wird

Das sind die Teile, die aus einem Log von Events ein Devlog machen, das du wiederlesen willst. Ein Toggl-Block rahmt den Tag in Kapitel ein, und eine Zeile Gedankengang in einem PR oder ein Kommentar an einem Ticket gibt dem Eintrag seine Stimme.