memorydial

Every morning my son and I walk to daycare through quiet streets.

We have one rule, his rule: when we see a dog, we stop and we look.

Some days we see the man with three St. Bernards. A woman with two Bernese Mountain Dogs. Last Friday she only had one. We looked worried.

“Tiberius is sick today. He will be around next week.”

When a big dog appears, my son kicks his legs and looks at me with an expression that says are you seeing this.

We do not care for small dogs.

We started keeping count. Three or more was a good start to the day.

But the question we could not shake: which route has the most dogs?

The Grid

The grid: six streets north-south, four avenues east-west. Street E is the main road. We can only cross it at the lights. Everything else is fair game.

Twelve valid routes from home to daycare, each shaped by where we can cross.

We had no data.

I needed a way to pick a random route, count dogs as I walked, and see the results later. The Garmin on my wrist could do all of it.

The Build

He was napping.

I wanted a Garmin app that would tell me which way to go, count dogs with up and down buttons for false positives or dogs deemed too small, and sync to a dashboard on my laptop.

Garmin apps are written in MonkeyC. MonkeyDo runs them. I chose Python and Django for the backend. The watch would sync through the Garmin Connect app.

The watch needed to pick a random route. We can only cross Street E at the lights on 4th and 2nd. Everything else is fair game. I mapped twenty-four possible routes.

I worked on the spec and tried to catch any edge cases, what happens when there's no connection? How do I know which leg of the route I'm on?

I fed it into Claude Code's planning mode. Reviewed. Then enabled yolo mode and let it run.

The app worked in the simulator on the first try. We adjusted fonts and configured ngrok so data could flow from watch to server.

I synced a test walk. The terminal lit up. The dashboard updated.

One kilometer. Ten dogs. Ten seconds.

Test data. Ten dogs in ten seconds would be a miracle, a stampede, or the best day ever.

The Walk

I deployed it to the Raspberry Pi that weekend and tested the sync one more time. Then we went on with our weekend.

Monday morning. First real test.

My son in the stroller. Watch on my wrist showing Route 1. Left for 200 metres.

We walked. I watched for dogs. He pointed at trees, birds, a crack in the sidewalk.

No dogs.

Not one.

The entire route, start to finish, and not a single dog. No St. Bernards. No Tiberius. No doodles. Not even the small ones we ignore.

I ended the walk. The watch synced. The dashboard updated.

Total walks: one. Total dogs: zero.

The watch tells you to stop eating. No willpower required. Just a signal, like a fuel gauge.

John Walker called it the Eat Watch. The AutoCAD founder wrote The Hacker's Diet in 1991. An engineer's approach to the body: treat it as a system. We are bags of water. Calories go in, calories go out. Weight is the integral of the difference. Engineers had been solving problems like this for decades. Why not fat?

Walker proposed a thought experiment. You set a calorie budget for the day. The watch counts down as you eat. When you hit zero, it tells you to stop. No willpower. No decisions. Just a signal, like a fuel gauge.

He never built it. This was 1991. He ran the numbers on paper, then spreadsheets. The watch was a metaphor for weight loss without guesswork.

So I built it. I've been making apps with Claude Code, and I wanted something outside my comfort zone. Could I build the Eat Watch? Make an app for my Garmin? How far could I get with zero experience? I'd never touched Garmin development or heard of MonkeyC before. I opened Claude, started the spec, and three hours later I had an app on my wrist.

The app: a daily calorie budget, a reset hour. The watch stores both. One word at the top: EAT in green. One number below: calories remaining. When the number hits zero, the text changes to STOP in red. At your reset hour, it starts fresh.

I look at my wrist. Green. I can eat.

But right now I'm tapping buttons. Guessing portions. The watch only knows what I tell it.

MyFitnessPal has the real numbers. Every meal logged, every snack timestamped. If I can sync that data to my wrist, the Eat Watch becomes what Walker imagined: a closed loop.

That's the next build.

A white onion almost broke me.

I was cooking dinner, logging as I went. I weighed the onion, chopped it, threw it into the pan, then opened MyFitnessPal. The first result had more fat than a stick of butter.

I knew that was wrong. I spent the next five minutes hunting through a database of user-submitted shite, guessing which entry was accurate. For an onion.

Why am I still using this crap?

Right then I decided to build my own.

It came together with Claude Code pretty quick. A Django Web app, SQLite Database and a cheap GPT model deployed onto a raspberry pi and made accessable over the web via Tailscale.

You describe food in plain English. It returns reasonable nutrition data. Just type what you ate.

When I'm cooking, I know what's going in. Last week I made chili. I pasted the ingredients straight from a YouTube description: ground beef, kidney beans, tomatoes, onion, half a packet of American cheese. Told it six portions. It came back: 340 calories, 26g protein per bowl.

When I'm out, I don't know what's in the burrito. I don't need to. I type “chipotle chicken burrito, no sour cream” and it comes back: 650 calories, 42g protein, 80% confidence. Good enough. Logged and done.

Here's what the big apps miss: a rough estimate you record beats a precise measurement you don't. Tracking is a habit. Habits need to be easy.

Last week I wanted to re-log yesterday's breakfast with one click. Took an hour. Now it's there, because it's mine.

And mine doesn't store passwords in plain text.