I Built a Journal for Developers Who Don't Journal

George Rios — Fri, 06 Mar 2026 20:52:31 +0000

Worktale is a CLI tool that reads your git history and turns it into a personal work journal. No cloud. No account. No code leaving your machine. Your git history already has the story. Worktale just tells it.

I've been writing software professionally for over twenty years. In that time I've shipped hundreds of features, fixed thousands of bugs, and mass-deleted entire modules at 1 AM with the quiet confidence of someone who knows the tests will catch it. (They usually did.)

But if you asked me what I built last March, I'd stare at you. Blank. Nothing. The work was real. The memory of it isn't.

That's the problem Worktale solves.

The Forgetting Tax

Every developer I know has the same gap. You spend months deep in a codebase--shipping, iterating, solving genuinely hard problems--and then someone asks you to write a self-review, update your resume, or explain what you've been doing for the last quarter. And you open your git log and try to reverse-engineer your own career from commit messages like "fix thing" and "wip."

It's absurd. We have perfect records of every line we changed, every file we touched, every branch we merged. The data is right there. But nobody looks at it. And nobody turns it into anything useful.

I got tired of that.

What Worktale Is

Worktale is a CLI tool that reads your git history and turns it into a personal work journal. No cloud. No account. No code leaving your machine. You install it, point it at a repo, and it gives you a structured record of everything you built.

npm install -g worktale
worktale init
worktale dash

Three commands. That's it.

It tracks your commits, calculates your coding streaks, breaks your work into daily summaries, and gives you an interactive dashboard in your terminal. You can generate digests of your day, browse your history by week, and actually see the shape of your work over time.

The whole thing runs on a local SQLite database. No telemetry. No analytics. No network requests. Your work stays yours.

Why Local-First
I've been burned enough times by tools that promise privacy and then quietly phone home. Or tools that work great until the company pivots, gets acquired, or decides your free tier is actually a premium feature now.

Worktale doesn't have that problem because there's no server. There's no account. There's nothing to pivot or deprecate. It's a binary on your machine that reads your git history and writes to a local database. That's the architecture. That's the privacy policy.

This isn't a philosophical stance dressed up as a feature. It's a practical decision. Developer activity data is sensitive. Your commit patterns reveal what you're working on, when you're working, and how you think. That data belongs to you. Not to a startup's analytics dashboard.

The Dashboard

The TUI dashboard is the thing I'm most proud of. It's a full React app running in your terminal via Ink. Three views: Overview, Daily Log, and History. You tab between them, navigate with keyboard shortcuts, and get a real-time picture of your development activity.

It shows your current streak, today's stats, your most active files, commit activity heatmaps, and daily breakdowns going back as far as your git history goes. If you've been working on a repo for three years, you'll get three years of data on first run.

No setup. No configuration. Just worktale dash.

Who This Is For

Worktale is for the developer who ships consistently but has nothing to show for it. The one who does great work and then can't articulate what that work was when it matters.

If you've ever:

Blanked during a performance review
Stared at a resume wondering what to put for the last year
Forgotten the feature you shipped two months ago
Wanted a simple record of what you actually built

This is for you.

It's also for anyone who wants to build better habits around reflection. Not in a productivity-guru, morning-routine kind of way. In a "let me spend 30 seconds seeing what I did today" kind of way. The nudge feature reminds you at end of day to check in. Optional, non-annoying, easily ignored.

The AI Part (Optional, Local)

Worktale can optionally generate daily digests using Ollama--a locally running AI engine. It reads your commit messages (just the messages, never your code) and produces a human-readable summary of your day.

The key word is "locally." No data goes to OpenAI, Anthropic, or anyone else. If you don't have Ollama installed, Worktale uses a template-based system that works without any AI at all. Zero network requests.

I built it this way because I wanted the feature without the trade-off. AI-powered summaries are genuinely useful. Sending your commit data to a third party is not.

Open Source, MIT Licensed

Worktale is fully open source under the MIT license. The code is on GitHub. You can read every line, fork it, modify it, or contribute to it.

I'm building this in the open because the tool only matters if developers trust it. And trust starts with transparency.

What's Next

Cloud publishing is on the roadmap--a way to optionally share your work journal publicly, like a developer portfolio that writes itself, not totally unlike my other project RemoteDevelopers, but the local-first core will always work standalone. Cloud will be additive, never required.

For now, the CLI is the product. Install it. Run it on your repos. See what you've actually been building.

npm install -g worktale

Your git history already has the story. Worktale just tells it.

Worktale is live on npm and GitHub

Website: worktale.org

Follow @worktaleapp for updates.

C# Deserves Better. So We Built It.

George Rios — Sun, 01 Mar 2026 21:03:33 +0000

Go to any new API platform, any hot developer tool, any freshly launched SDK. Scroll to the code examples. You'll see Python. You'll see TypeScript. Maybe Rust if they're feeling adventurous. Five years ago, you'd see C# right there alongside them. Ruby too. Now? Nothing.

This isn't because C# got worse. It got better--dramatically better. Minimal APIs, native AOT, top-tier performance benchmarks, a type system that would make TypeScript developers weep with envy. But somewhere along the way, the ecosystem stopped showing up. The community stopped demanding a seat at the table. And the rest of the industry quietly moved on without us.

The .NET Visibility Problem

Here's the thing about ecosystems: they're self-reinforcing. When a new developer sees Python and TypeScript examples everywhere, they learn Python and TypeScript. When they build products, they build them in Python and TypeScript. When they launch developer tools, they write docs for--you guessed it--Python and TypeScript.

Meanwhile, .NET developers are out here building enterprise systems that process millions of transactions a day, running cloud infrastructure that never goes down, writing code that is genuinely excellent--and getting zero credit for it in the broader developer zeitgeist.

The language doesn't need a glow up. The ecosystem does.

So We Built nugx.org

For years, .NET developers have relied on NuGet--and it's solid. The registry works. The CLI works. But when it comes to discovering packages, understanding dependencies, or comparing alternatives, the default experience leaves a lot on the table.

So we built nugx.org--an alternative NuGet front-end designed for how developers actually work:

Better search. Results ranked by relevance, not alphabetical order. You shouldn't have to know the exact package name to find what you need.
Popularity and usage signals. Download trends, version adoption, maintenance activity--the signals that actually help you decide between three packages that do the same thing.
Dependency graphs at a glance. Before you install a package, you should know what you're pulling in. Not after. Not buried in a CLI output nobody reads.
A cleaner, faster UI. This is 2026. Developer tools should feel like developer tools, not government portals from 2011.

It's free, it's open, and it's live right now. If you're a .NET developer, go break it and tell us what's wrong. Seriously.

Why Build This in Public

I've spent my career building software for clients behind NDAs and closed doors. That work pays the bills and I'm proud of it. But there's a problem with only building in private: nobody sees the craft. Nobody benefits from the decisions, the tradeoffs, the hard lessons.

Building in public isn't about clout. It's about accountability. When you ship something the community can see and touch and criticize, you can't hide behind vague roadmaps and polished pitch decks. The code either works or it doesn't. The experience either respects the developer or it doesn't.

nugx.org is the first public artifact of something bigger we've been building. And I want people to watch the whole thing happen--warts and all.

Interested in learning more? Continue here...

DEV Community: George Rios