100 Days of Code, as a Tiny Experiment

"A PACT is a commitment to a specific action for a set period of time. Purposeful. Actionable. Continuous. Trackable." — Anne-Laure Le Cunff, Tiny Experiments[^1]

I've been reading Tiny Experiments, and one idea stuck.

Most of us set goals like "get good at X" or "build a habit." Then we fail, and we decide the problem is us. Le Cunff says the problem is usually the frame. Instead of a goal — a far-off finish line you either hit or miss — you make a PACT: a small, repeatable action you do every day for a set number of days, just to see what happens.

Not "become a better developer." Just: do the small thing, every day, and see what I learn.

So here's mine.

The PACT

I will commit code to my repo every day for 100 days.

Let's hold it up against the four letters:

1. Purposeful. I want writing code — with Claude Code doing most of the typing — to be a daily reflex, not a when-I-feel-like-it thing.
2. Actionable. I can do it today. No gear to buy, no course to finish first. Open the laptop, ship something small.
3. Continuous. Every day. Small counts. One honest commit beats a heroic weekend and then nothing.
4. Trackable. This is the part I love. There's already a perfect tracker built for it, and I don't have to maintain it by hand.

The tracker maintains itself

That green grid at the top of this post is my GitHub contribution chart, rendered live. Every day I commit, a square lights up. Miss a day, and there's a grey gap staring back at me.

I didn't build it. I don't update it. It just tells the truth — which, if you've read my post on the TODO list nobody maintains, you'll know is exactly the kind of tracking I trust: the kind that runs without me.

That's the whole appeal of a PACT. It's not about willpower. It's about making the work visible and letting the chart do the nagging.

Why not a goal?

Because I've set the goal "code more" a dozen times and it means nothing. There's no day where I've done it. There's no square to fill.

A PACT is different. It doesn't ask did you succeed? It asks did you show up today? — a question I can answer with a yes or a no, every single day. And at the end of 100 days I won't have "become a better developer" (whatever that means). I'll have 100 squares, or I won't, and either way I'll have learned something about how I actually work.

That's the experiment. Not will I win — but what will I find out.

The book, one lesson at a time

I didn't just read Tiny Experiments once and shelve it. I loaded it into MarrowMinded, an app I built that sends me one lesson a day from books I've already read.

So now the book itself is a daily habit feeding a daily habit. Each morning I get one idea from it. Each day I make one commit. If you want to dig into the ideas in the book, that's where I keep them — one small piece at a time, instead of a 300-page block I'll forget in a week.

Takeaways

• Swap the goal for a PACT. Not "get good at X" but "do X, daily, for N days." A question you can answer every day beats a finish line you keep missing.
• Make it trackable by something that isn't you. The best tracker is the one you never have to maintain. Mine is a chart that updates itself.
• Small counts. One honest commit keeps the streak alive. The point is showing up, not the size of the day.
• Run it to learn, not to win. A tiny experiment doesn't ask did you succeed — it asks what did you find out.

Running your own tiny experiment? I'd love to hear what your PACT is — and whether the chart nags you as much as mine nags me.

[^1]: Anne-Laure Le Cunff, Tiny Experiments (2025). The PACT framework comes from her work at Ness Labs.

The Feature That Found a Bug

Part of Building GribGrab — a series on what I learn building a weather app with Claude Code.

GribGrab had four ways to pick a place: type a city, paste coordinates, tap GPS, or reuse a saved one. All of them are text. None let you just point.

So I added a map. Drag it around, and the forecast loads for whatever sits under the crosshair. That's the whole feature.

The interesting part came after.

I could've used a library

There's a library for this — Leaflet. Drop it in, done in an hour. I didn't. I wrote the map myself, about two hundred lines.

Why? GribGrab runs on one rule: no code from anyone else's server. It keeps the app light and private, and I'm the only one who can break it. The cost is real — I now own every pinch-zoom quirk Leaflet would have handled. But it's a cost I can see.

That's the trade with a library. It doesn't remove the work. It hides it, and hands you the bill later.

Then I tapped the Arctic

The moment the map worked, I could tap anywhere. So I tapped the North Pole. The chart went completely gray.

The app shades the night-time hours grey. Up there it had shaded the whole week.

The reason is nice. At the poles in summer the sun never sets. My weather source says so honestly: sunrise at midnight, sunset at midnight the next day — 24 hours apart. My old code read both as "00:00," called the whole day night, and greyed everything out.

That bug had been live for months. Nobody hit it, because reaching the Arctic meant typing its coordinates, and who does that? The bug wasn't new. The map just built a one-tap road to it.

A new feature is a flashlight

This is the part I keep relearning. You think a new feature adds a room. It doesn't — it adds a door, onto rooms that were always there in the dark. This one literally: the room I walked into was a chart greyed out into permanent night.

The map didn't create the polar bug. It created the first easy path to it. Same as a search box surfaces the query nobody typed.

So shipping something new is also my cheapest bug finder. Every door shows you a room you never checked.

The quiet cost

The map isn't free — not in privacy. A map is a grid of little numbered image tiles, and to draw your view the browser has to ask OpenStreetMap's servers for the exact tiles you're looking at. Each of those requests carries your IP address and which squares of the world you asked for. That's how they'd know — not from anything I send them, but from your own browser fetching the picture. Pan to your house and you've told them roughly where you are.

Fair trade for a map you can point at. But it's a trade, so it goes in the privacy policy in plain words. A feature that phones a third party always has a bill. The least I can do is print it.

Takeaways

• Ship it, then poke the corners. Tap the ocean, the poles, the empty box — the edges you'd never reach the slow way.
• A library moves the work, it doesn't delete it. Fine sometimes. Just know you're choosing where the bill lands.
• New paths surface old bugs. Make something easy that was only possible, and expect it to walk into code nobody had run.
• Say the privacy cost out loud. If a feature phones a third party, tell users. "Free" usually means someone else pays in data.

New doors, old rooms. Go open one. → gribgrab.com

A Skill Is Just You, Written Down

I keep telling people: if you can describe what you want, you can build it now. I build my apps that way. I talk, Claude Code types.

This week I built something different. Not an app — a set of small tools for Claude Code itself. And there's no code in any of them.

They're all in one public repo: claude-code-skills.

Update · 4 July 2026 — Two more since I hit publish: translate-en-to-pl and translate-pl-to-en. They don't just translate — they confirm what I meant first, then hand me three versions with the register and the reason for each one spelled out. Which quietly breaks my "they're all thinking tools" line below. Fine by me: a skill turns out to be just as good at doing a thing as thinking one through. Still only me, written down.

Update · 5 July 2026 — Added clarify-doc, the one I'll use most. Give it something you've written and it checks whether a reader can actually follow it — same word for the same thing throughout, each sentence leading to the next, each paragraph to the next — then rewrites it plain. It leaves its notes as invisible comments right on the lines they're about, so the rendered page stays clean. This whole update log got a pass from it before I hit save.

What a skill is

A skill is a folder with one file inside: SKILL.md. The top says what it is and when to use it. The rest is plain instructions, like a note to a helpful colleague.

No code. No install. You drop the folder in, and Claude decides on its own when to use it.

That's the hard part. A good skill fires at the right moment and stays quiet the rest of the time. The trick isn't what it does. It's teaching the tool when to use it.

My favourite: cruciable

I wanted to test an idea before committing to it. Not a yes-man. A real argument.

So I described it, and by the afternoon it existed. You give it a claim — "I should do X." It runs a three-round debate: one side for, one side against. The rules: answer each other first, then add something new. No repeating. Examples welcome. At the end it hands you the strongest point on each side, and the one question it all comes down to.

Then it lets me decide.

I've used it on real decisions since. It's good to watch both sides of your own head argue it out, in order, instead of going in circles.

The other four

All thinking tools, it turns out:

• mental-models — walks me through a hard choice using Naval Ravikant's frameworks, one question at a time.
• thinking-partner — a ten-minute session that ends with one clear next step.
• stoic-mentor — a Stoic mentor that asks instead of tells. I keep it in English and Polish.

None of them are clever. That's the point.

The twist

A skill isn't code. It's taste.

mental-models is how I like to break down a choice. stoic-mentor is the questions I want asked when I'm stuck. write-post wrote the first draft of this post.

I didn't teach Claude a task. I wrote down how I think, and handed it over.

Why share them

The most honest thing you can show isn't a polished demo. It's what you actually use on a normal Tuesday.

Sharing them cost me nothing — a README, a licence, one push. But these are the tools I use when no one's watching. That's building in the open: don't tell people what you can do. Hand them the thing you made.

Takeaways

• A skill is instructions, not code. If you can write a good note, you can write one.
• The hard part is the trigger. When it fires matters more than what it does.
• Write down how you think. The best tools aren't clever. They're yours.
• Share what you actually use. Real proof is the daily tool, not the demo.

Take any of them → github.com/jaal/claude-code-skills

Now It's Apps' Turn to Get Cheap

Once the foundational tools are good enough, technique and training outperform hardware. — Seth Godin, "You don't need a better camera"

Seth wrote that about cameras this week. The gist: past a certain point, a better one won't make you better. New snow tires beat a new car for winter driving.

It got me thinking about something bigger. The tools don't just get good enough — they get cheap enough, over and over, until the only expensive thing left is the idea.

Take blogs. In 1995, having one was a project. A server, or money for hosting. Some HTML, maybe a web server to configure. And even then you were shouting into an empty room — no feed, no algorithm to find you. Real money, real knowledge, real time.

Ten years later, none of that was true. You signed up for Blogger, picked a theme, and wrote. Free. Today you can stand up a blog on your own domain in the time it takes to make coffee.

I keep noticing this pattern. The cost of making a kind of thing starts impossibly high, then collapses.

The same arc, over and over

• Words. A blog went from servers-and-HTML to a free signup in about a decade. Now anyone can publish under their own domain in seconds, for almost nothing.
• Music. Recording once meant a studio and a label. Then a laptop and a cheap interface made a bedroom good enough.
• Video. Cameras, editing suites, broadcast deals — then YouTube and a phone in your pocket.
• Graphics, then video again — this time with AI. What used to need a designer, or a film crew, now needs a prompt.

Each time, the same thing happens. The expensive parts — the gear, the skill, the distribution — fall away one by one. What's left is taste and the idea: knowing which thing is worth making, and being the one to think of it. Those don't get cheaper. When everyone can make the thing, the only edge left is picking the right thing and making it well.

And each time, a wave of people who could never have made that thing before suddenly can. With something like Claude Code, the distance from "I wish this existed" to a thing that runs is an afternoon — you describe it in plain words, it writes the code.

The other half: getting found

But making was only ever half of it. The other half is getting someone to look.

Before social media, that was pure word of mouth. Seth tells a story from the days before a Share button existed: people would print out his posts and leave them on a colleague's desk with a note — "you have to read this." They faxed them between offices. They forwarded the email to the whole team. Not to promote Seth — to look smart themselves. A good idea was a thing you passed along, because passing it along made you look sharp.

And he still works that way. Seth doesn't really promote the blog. He just shows up — every single day, for years — and writes something that might be useful to someone else. The showing up is the whole strategy.

Apps are next

Software was the holdout — two costs in one: writing the code, and running it. Both are caving now, just not in step. Running went first; cloud platforms ate most of that pain over the last decade. Writing's going now, with AI doing the typing. And this week I felt the running side fall even further.

The making I've written about before: I build my apps with Claude Code and barely touch the code by hand. What got me this week was the running. So I ran an experiment — moved two apps, GribGrab and MarrowMinded, from Render to Railway, just to feel how it goes now.

I didn't really do it. I told Claude Code to, and it did — figured out the build, the start command, wired up the database. One command, a couple of minutes, a live URL. Turbo fast.

Not all smooth. The first deploy landed on top of my database and wiped it, because the tool defaults to whatever service you touched last. One flag fixes it. Every platform has an edge like that; the trick is finding it before it finds you.

Money? Roughly a wash — a few dollars either way.

So price didn't decide it. Time did. The gap between "works on my laptop" and "live on the internet" used to be a chore. Now it's one prompt. And when shipping is that cheap, you ship more — even the small things you'd never have bothered with.

What this is really about

So it's not the tools. It's the direction. Shipping an app used to be a wall. Now it's a button — same as blogging, music, video, images before it. The expensive parts fall away, and you're left with the only two questions that ever mattered: do you have something worth making, and can you get anyone to see it?

Takeaways

• Let an AI agent write the code. You keep the taste and the decisions; it handles the typing.
• Pick a platform that ships in one command. I tried both Render and Railway and I'm happy with each — the point isn't which one, it's that the hop from "works locally" to "it's live" is now a single step.
• Every tool has one sharp edge — find it early. Mine was Railway deploying on top of my database and wiping it. Trip over it once, write it down, move on.
• Ship the small thing. When deploying is free and instant, build the tiny app you'd never have set up a server for. The point isn't the app. It's that you finally can.

What have you been sitting on because shipping it felt like too much? The wall's gone — go make something. → gribgrab.com

I Lost My Setup Once. Now It Lives in a Repo.

This week I switched to a new laptop. Nothing dramatic — nothing lost or stolen. Just the old one out, a new one in.

Almost everything moved over on its own. Documents, apps, settings — all saved in the cloud, all there when I logged in. Everything except one folder: my Claude Code config, plus a small file that lists my projects. That stuff was never saved anywhere. So it was just gone, and now I have to set it all up again from memory.

I'd been here before. You don't notice these things until they're missing — the shortcuts, the small tweaks, the settings you build up over months and never write down. Then you spend days trying to remember a setup you can't quite picture.

No use crying over spilt milk. So this time I decided to do it right.

The Quiet Risk

I use Claude Code in my terminal every day. Over time it had become mine — custom hooks, a start-up routine, project settings, a few skills I'd written.

All of it lived in one folder on one laptop: ~/.claude.

The day I moved machines, none of it came with me. Same mistake as last time, just a different folder.

The Fix: My Config Is a Git Repo Now

The answer was obvious once I said it out loud. If my writing lives in a Git repo, why not my setup?

So I turned ~/.claude into a private repo on GitHub. But config folders are messy. They hold old history, cached files, and the odd password. I didn't want any of that going to the cloud.

The trick was to flip the usual rule. Instead of listing the files to skip, I skip everything, then add back only the safe ones:

/*
!/settings.json
!/hooks/
!/skills/

Now I can't upload my history or a password by accident. The repo can only ever hold the few files I picked.

The Part I Like: It Backs Itself Up

A backup you have to remember isn't really a backup. So I made it automatic.

Claude Code can run a small script each time it finishes a task. Mine checks if anything in the config changed. If it did, it saves and uploads the change on its own, quietly in the background:

• Nothing changed? It does nothing.
• Something changed? It saves it with a timestamp and uploads it to the private repo.

I don't think about it. I change a setting, keep working, and by the time I look up it's already safe in the cloud.

What This Actually Buys Me

• A new laptop is one command away. Not days of building things back from memory.
• A history of my own tools. I can see how my setup changed over time, and undo a change I regret.
• No passwords in the cloud. The setup makes sure of it.

The Lesson, Again

I keep learning the same thing: the work is safe, but the setup around the work is easy to lose. Your shortcuts, your small tweaks, your little bits of automation — they're worth saving too.

If a tool lets you save its settings as plain files, put those files in a repo. Make the backup automatic, so you're never the one who has to remember.

Future you, staring at a blank new laptop, will be glad you did.

Back up your setup, not just your files.

The Analytics Were Mostly Me

Part of Building GribGrab — a series on what I learn building a weather app with Claude Code.

I added analytics to my weather app and felt great about it. The daily-users line mostly went up. Real people, checking real weather.

Then I looked at who they actually were.

The day that gave it away

One day stood out. Lots of "active users," a nice tall bar. Then I removed my own visits — and nearly two-thirds of that day was one person. Me. On one device, reloading the app while testing a change to the chart.

63% of a "great" day was just me debugging.

It wasn't a one-off. Over two weeks, my own testing was padding the average by roughly 18% — but unevenly. Almost nothing on a quiet day; a third or more on days I was deep in the code. That's the trap: the noise is loudest on the days you work hardest, which are exactly the days you want the chart to mean something.

The numbers weren't lying. I was just standing in them.

How I found this out: PostHog + Claude Code

Here's the part I like. I didn't click around a dashboard tool to work any of this out.

I use PostHog for analytics, and it has an MCP server — basically a way for Claude Code to talk to PostHog directly. So I stayed in my normal coding session and just described what I wanted, in plain English, and Claude Code did it for me:

• "Build me a dashboard for active users and retention." → it created the dashboard.
• "Break daily users down by person and show me who loads the most." → it ran the queries and showed me the data.
• "That top user is me. Add a filter that excludes my traffic from every chart." → it built the exclusion and applied it everywhere.

No tab-switching, no learning a query language, no hunting through menus. I talked to my data like a coworker. Finding myself in the numbers, and then taking myself out, was a five-minute conversation in the terminal.

Why you're worse than bots

Everyone knows to filter out bots, and analytics tools do it for you. But you — the person building the thing — are the heaviest user by far in the early days, and nothing flags you.

You load the app more than anyone. You reload after every deploy. You open it on your phone to check the mobile view. You leave a tab running that refreshes on its own. Every one of those gets counted. To the dashboard, you look like your most loyal fan.

One of my "users" had loaded a city 125 times in a single week from one device. That's not a superfan. That's me.

When you only have a handful of real users, one busy developer doesn't bend the numbers. He is the numbers.

I thought I'd fixed this on day one

I wasn't careless about it. From the very start I added a secret switch: open the site with ?internal in the address and it would turn analytics off for me.

It didn't work the way I assumed. It muted exactly one page — the one I landed on. Click through to another city, or come back the next day, and it had already forgotten. It started counting me again the moment I did anything.

So for weeks I believed I was excluded, while I was quietly polluting my own data the whole time. A fix that half-works is worse than no fix, because it stops you from checking.

Finding myself for real

There's no "this is the founder" flag, so I had to teach the system to recognise my own footprints. Three gave me away:

My own subdomain. I'd set up a separate web address — a sandbox — just for my own testing, so I can try things before they go live. That turned out to be the cleanest signal of all: anything coming from that address is me, full stop. No real user ever goes there.

My city and browser. My laptop shows up in my home city, on a browser almost nobody else in my numbers uses. That combination is basically always me.

The version I first showed up on. I was the only person using the app in its earliest builds — before I'd shown it to a single other person. So "first seen on a pre-launch version" is a clean tag for my own devices, including my phone, which the first two signals missed.

I handed those three rules to Claude Code, it turned them into an "internal traffic" group in PostHog, and pulled that group out of every chart. The growth lines barely moved. But the engagement lines — my "power users," my regulars — shrank hard once I was gone. That's the part that stung.

The real fix: don't record it at all

A filter cleans up the dashboard, but the junk is still in the database, and I'd have to keep that filter current forever. Better to never collect it.

So now the app simply refuses to count me when it's obviously me:

// Don't track my own testing.
if (
  location.hostname === 'localhost' ||
  location.host.includes('sandbox') ||
  localStorage.getItem('internal') === '1'
) {
  analytics.optOut();
}

My own computer and my sandbox subdomain opt out on their own. And for the live site, I visit once with ?internal — but this time the choice is remembered on that device, for good, instead of lasting a single page.

Two layers: the filter cleans up the past, the opt-out stops me being recorded in the future. One is mopping; the other is not spilling.

What changed

My dashboard finally shows strangers. I keep two versions of the users line side by side — with me and without me — so the gap between them is the first thing I see. When the two drift apart, I know I've just been busy, not popular.

The uncomfortable lesson: early analytics flatter you by default, because the person reading the numbers is the same person making most of them. You have to deliberately take yourself out to see anything true. Until you do, you're not measuring your product. You're measuring your own enthusiasm.

Takeaways

• In a young project, you — not bots — are the biggest source of fake data. Remove yourself before you trust a single number.
• Your traffic spikes on the days you work hardest, exactly the days you want to read as growth.
• A half-working fix is dangerous. My day-one ?internal switch only muted one page, so I felt safe while polluting everything. Make sure your fix holds across a whole session, not one click.
• Give yourself an obvious tell. A separate subdomain for your own testing makes "is this me?" trivial to answer.
• Two layers beat one: a filter to clean the history, an opt-out to stop recording yourself going forward.
• If your tools have an MCP server, use it. I built the dashboard, found myself, and applied the filter by talking to PostHog through Claude Code — no UI, just plain English.

How much of your product's "engagement" is really just you, hitting refresh? I didn't know until I subtracted myself — and most of a good day disappeared. → gribgrab.com

The TODO List Nobody Maintains

Part of Building GribGrab — a series on what I learn building a weather app with Claude Code.

While building my weather app, I did the thing everyone does: I started a TODO.md.

It was great for a week. Then I stopped using it.

Three reasons it stopped working

1. My new ideas were better than the old ones. Every time I sat down to work, I had a fresh idea. It was usually more interesting than anything already on the list. So I'd chase the new thing, and the old items just sat there getting older.

2. The list never showed up. It was a file in a folder. To see it, I had to remember it existed and go open it. I never did. Out of sight, out of mind — so when I started working, the list wasn't in my head at all.

3. Keeping it updated took time. Checking off done items, adding new ones, cleaning out stale ones — that's work. Work with no payoff. So I skipped it, and after a while the list didn't match reality anymore.

Once a list stops matching reality, you stop trusting it. Once you stop trusting it, it's dead.

The fix: let the assistant do it

I work inside Claude Code all day. It already has everything it needs to keep the list honest: my commits (what I actually did), my TODO file (what I said I'd do), and today's date (how long each item has been sitting there). Keeping the list honest is just comparing those — including each item's age against the clock.

That's a chore, not a decision. So I gave it away. No new habit, no discipline. I tied it to two moments that happen on their own anyway: opening the project and committing code.

Here's how each of the three problems got solved.

Problem 2 first: make the list show up

This was the big one. I made the list appear every single time I open the project — before I do anything else.

A hook in .claude/settings.local.json hands Claude the list, today's date, and my recent commits, and asks it to brief me:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Compare TODO.md against the recent commits, then tell me: what got done, what is stale (open more than 14 days, or marked ⏳), what is missing, and what to archive (done more than 30 days ago).' && echo '--- today ---' && date +%Y-%m-%d && echo '--- TODO.md ---' && cat TODO.md && echo '--- last 15 commits ---' && git log -15 --pretty=format:'%ad %s' --date=short"
          }
        ]
      }
    ]
  }
}

Now I can't miss it. Every session opens with: here's what shipped, here's the thing you've been ignoring for three weeks, here's what you meant to do and never wrote down. The list is the first thing in my head, not a file I forget.

Problem 3: stop spending time on it

The same hook does the cleanup. Claude moves finished items to Done, stamps the dates, and sweeps anything done more than 30 days ago into an archive file. I don't touch it.

A second hook keeps it current as I go. After every commit, it checks whether the commit finished anything on the list and updates it:

{
  "PostToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        {
          "type": "command",
          "command": "python3 -c \"import sys,json; d=json.load(sys.stdin); cmd=(d.get('tool_input') or {}).get('command','') or ''; print(json.dumps({'hookSpecificOutput':{'hookEventName':'PostToolUse','additionalContext':'A git commit just landed. If it finished a TODO.md item, move it to Done (done: today), add any follow-ups (added: today), and flag stale items. Do nothing if none of this applies.'}})) if 'git commit' in cmd else None\""
        }
      ]
    }
  ]
}

It runs after every command but stays silent unless the command was a git commit. Maintenance cost: basically zero.

Problem 1: catch the good new ideas

The new ideas were the whole reason I kept ignoring the list — so now I make sure they get caught instead of lost.

At my desk, a fresh idea goes straight into the list, stamped with today's date. Away from my desk it's harder, so I lean on two simple tools: a single note pinned in Notesnook for anything I can type, and AudioPen when my hands are busy — I just talk, and it transcribes. Later, those ideas get folded into the list too.

Either way, next time I open the project the new idea is right there in the briefing next to everything else, dated, so I can see what's fresh and what's been waiting.

The thing that used to kill the list now feeds it.

What makes it work: dates

The whole thing runs on one simple rule — every item has dates:

- [ ] Fix pressure bug — wrong at altitude (added: 2026-06-20)
- [ ] ⏳ Decide on the logo (added: 2026-06-04)
- [x] Indexable city pages (done: 2026-06-08)

Dates are what let a machine handle it. Claude doesn't have to guess whether something's old — it just subtracts two dates. "Stale" stops being a feeling and becomes math.

What changed

The list went from a graveyard to a dashboard. I open the project and the first thing I see is the truth: what moved, what's stuck, what I'm avoiding. I haven't checked off a box by hand in weeks.

The bigger lesson: if you have to remember to do the upkeep, you won't. Tie it to something that already happens, give it a format a machine can read, and let the machine do the boring part.

Takeaways

• A list dies the moment it stops matching reality.
• When trust goes, the list goes. Catch it lying once and you stop opening it — and a list you don't open is already dead.
• Don't rely on discipline. Tie upkeep to events you can't skip — opening the project, committing code.
• Make the list show up on its own. A file you have to remember is a file you'll forget.
• Use dates. They turn "is this stale?" into simple math a machine can do.

When did you last trust your own TODO list? Mine I ignored for years — until I stopped being the one keeping it.

I Gave Claude Code Google Docs-Style Comments

Part of Building GribGrab — a series on what I learn building a weather app with Claude Code.

Google Docs has this collaboration system I love: you highlight a line, drop a comment, and bounce back and forth in the margin — suggestions, questions, replies. It's the back-and-forth that makes it work.

That's the one thing I missed when I moved most of my work into Claude Code. The drafts were good, but I had no clean way to say "this part — fix this."

So I rebuilt the workflow.

My Flow

It's simpler than it sounds:

1. I use VSCode to structure my folders, work on files, and talk to Claude Code through the built-in terminal.
2. When I start a project, topic, or task, I create a Markdown file.
3. The structure is always the same: goal, resources, outcome.
4. I ask Claude Code to work on that file and draft the outcome right there.
5. When I want to comment on something, I highlight the text and hit Cmd+Option+M — the same shortcut Google Docs uses for inserting a comment.
6. Then I tell Claude Code to act on the comments.
7. I iterate on the same file by repeating steps 5 and 6.

The whole thing lives in one Markdown file. Goal at the top, the draft below, my comments inline. No context lost, no copy-pasting between a chat window and an editor.

How to Set It Up

This is the part that makes it click. There's no extension — it's a single VSCode keybinding that wraps whatever text I've selected in an HTML comment addressed to Claude.

Open the Command Palette (Cmd+Shift+P), run "Preferences: Open Keyboard Shortcuts (JSON)", and add this:

{
  "key": "alt+cmd+m",
  "command": "editor.action.insertSnippet",
  "when": "editorTextFocus",
  "args": {
    "snippet": "<!-- Claude, this is my comment on the quoted text. Quote: \"${TM_SELECTED_TEXT}\" | My comment: $0 -->"
  }
}

Now highlight any line, press Cmd+Option+M, and you get:

<!-- Claude, this is my comment on the quoted text. Quote: "the highlighted line" | My comment: ▌ -->

The cursor lands right where you type your note. Two things make this work:

• ${TM_SELECTED_TEXT} pulls in whatever you've selected, so Claude knows exactly which line you mean.
• It's an HTML comment (<!-- -->), so it stays invisible when the Markdown renders but Claude reads it fine.

Write your comment, then tell Claude Code to go through the file and address them. It reads the quote, reads your note, and edits in place — just like resolving comments in a doc.

Why It Works

The magic isn't the keybinding. It's that comments turn a one-shot prompt into a conversation anchored to the text.

Instead of describing which paragraph I mean in the terminal, I point at it directly. Instead of re-explaining context, the context is the file. The draft and the feedback live in the same place, and that place is version-controlled, searchable, and mine.

It's the Google Docs margin, minus Google Docs.

Takeaways

• Keep one file per task. Goal, resources, outcome — that's the whole structure.
• Comment inline, don't re-prompt. Anchoring feedback to specific lines beats describing them in the terminal.
• Steal the shortcut you already know. Mapping it to Cmd+Option+M means there's nothing new to remember.
• It's one keybinding. No extensions, no setup tax.

How do you give feedback to your AI assistant? Still typing it all in the chat — or have you found a better margin?

I Built a Weather App, which I use every day.

This is the start of a series about what I learn while building GribGrab — a free hourly weather chart I made with Claude Code. Notes on the product, the process, and the tools along the way.

The series so far

1. I Built a Weather App — the origin story (you're here)
2. The TODO List Nobody Maintains — keeping a project list honest without touching it
3. I Gave Claude Code Google Docs-Style Comments — editing drafts inline, like in a doc
4. The Analytics Were Mostly Me — finding and cutting your own traffic out of your own stats
5. The Feature That Found a Bug — how a new map picker uncovered a bug hiding at the poles

I got tired of weather apps that just say "partly cloudy."

So I built GribGrab — a simple page that shows you a full hourly chart for the next 7 days. Temperature, rain, wind, pressure, all in one view. No account, no app. Just search a city and see what's coming hour by hour.

Why

I commute by bike. I travel. I plan outdoor activities. I want to know when exactly it's going to rain on Thursday — not just "Thursday: showers."

Most of weather app I tried wrapped that in so much UX that the actual data was buried.

So I built the thing I wanted.

The Reddit Moment

I posted GribGrab on r/weather. Someone replied — not with "nice job" — but with a detailed explanation of why raw numerical model output shouldn't really be called a forecast.

The short version: global weather models run on grids of roughly 10–25 km per cell. Your city and the hills 5 km away share the same cell. Local effects — coastal fog, mountain valleys, urban heat islands — are invisible to the model. Real forecasts apply statistical corrections trained on years of local observation data. GribGrab does none of that.

He was right.

What I Did With That

First, I updated the app's language. "Model output" instead of "forecast." A small disclaimer. Honest framing.

Then I realised this is actually a feature for the right audience. Hikers, people outdooring a lot — people who understand weather — often prefer raw model data. They want to interpret it themselves, not get a smoothed-over summary.

Where It Is Now

About 20–30 people use it daily, mostly from Reddit posts. I've added city pages for SEO — early days, but a long-term bet.

No monetization yet. Growth first.

What I Learned

Build the thing that scratches your own itch. Post it publicly as soon as it's embarrassing enough. The criticism you get will teach you a lot.

Have you checked what the weather looked like the last time your hike got rained out? → gribgrab.com

Are You Sure About That? The Prompt That Changed How I Use AI

"Are you sure about that?"

This should have been the first thing I said to AI after every initial answer. Why? It gives better responses when I doubt it from the start. I've tried it on several prompts — and the difference is real.

Why Skepticism Works

AI models are trained to be helpful. That sometimes means they confidently fill gaps with plausible-sounding information. When you challenge an answer, you force the model to reconsider — to flag what it actually knows versus what it's guessing.

The Prompt I Use

I've found two versions useful, depending on how much control I want.

Short version

Always flag uncertain or speculative claims with [uncertain] or phrases like "I'm not sure about this." State well-established facts directly. Don't inflate responses with loosely supported points.

Long version

When answering questions, clearly distinguish between what you know with confidence and what is uncertain. For well-established facts, state them directly. For anything speculative, poorly documented, or based on indirect reasoning, flag it explicitly using phrases like "I'm not certain", "this is speculative", or a marker like [uncertain]. Do not pad responses with loosely related points just to seem thorough. If you don't know something, say so plainly.

Both versions do the same job. The short one fits in a system prompt easily. The long one leaves no ambiguity.

What Changes

Once you add this to your setup, you start seeing [uncertain] markers appear. You notice the model hedging more. You trust what's left unhedged a little more.

It's not that the AI suddenly becomes smarter. It's that it stops pretending to be more confident than it is.

What's your experience? Try it yourself and see what changes.

I Read a Lot. I Remember Almost Nothing. So I Built This.

I finish a book. I feel good about it. Two weeks later, I can barely recall what it was about.

That's the problem. And it's not a lack of effort — I read consistently. The problem is the format. You read a book once, in big chunks, and then... nothing. The ideas don't stick.

I'd read about the Ebbinghaus forgetting curve before — the idea that we forget roughly 70% of what we learn within 24 hours. I knew about it. I just didn't do anything about it.

So I built MarrowMinded. The name comes from the idea of extracting marrow — the most nutritious part of the bone. Books have marrow too. Most of what surrounds it is just filler.

What It Does

MarrowMinded gives me one lesson per day from a book I've already chosen. Not a summary. Not a chapter. One concept, structured into seven sections:

• A short quote from the text
• The key thesis in one sentence
• The idea explained in depth
• A specific example from the book
• How it applies to my life today
• A concrete task for the day (5–30 minutes)
• A reflection question

That's it. One lesson. Every day.

How does it look?

Why One Lesson?

Business books are mostly padding. An author has 40 pages of insight and writes 300 pages of anecdotes around them. The anecdotes make it readable. They also make it forgettable.

The insight from Effortless or Naval's Almanack is there. The signal is real. But the format — read it once, all at once — is broken.

One focused concept a day, repeated over months, beats a 3-hour reading binge I won't repeat or remember. Drip beats flood.

How I Built It

The stack is deliberately minimal. One Python file (FastAPI + SQLite), one HTML file with vanilla JavaScript. No framework, no build step. Books are plain .txt files. Lessons are generated once by AI and cached as JSON — so on day one of any book, there's no API cost at all.

Multi-provider AI support under the hood (Claude, GPT, Gemini, Groq), but Claude is the default. The prebuilt lessons cost me around $50 in tokens total. The whole thing took 10–12 hours to build, mostly evenings.

It runs on Render's free tier.

The Part That Surprised Me

I use it every morning. That's the metric I actually care about.

Building something you genuinely use changes everything about how you build it. You cut the features you don't need because you'd notice if they were wrong. You keep it simple because complexity would slow you down before breakfast.

I have eight books loaded in right now — a mix of English and Polish titles. Every morning, one lesson, one task. That's the whole thing.

Do you have a reading habit? And more importantly — do you actually remember what you read?

If you're curious how it works, have questions about the stack, or want to build something similar — ask. And if you'd like to take a look at the repo, just say so.

Siri Feels Like 2014—And Apple Doesn't Seem to Care

I've been using Opera Neon on my laptop. Together with Claude Code and Claude, I can do a lot. Research, writing, coding, data analysis—you name it. The AI works so well that I forget it's even AI.

Then I ask Siri to do something.

"I can't do that."

The contrast is jarring.

What Siri Can Actually Do

Don't get me wrong—Siri is useful for the basics:

• "Open app X"
• "Set a timer for 10 minutes"
• "Volume up"
• "Call John"

These work fine. Siri handles simple commands without friction.

But the moment you ask for anything more complex? It falls apart.

Where Siri Breaks Down

Last week, I asked Siri to create a card in Trello.

"I can't do that."

Fine. How about creating a reminder with a specific note attached?

"I can't do that."

These aren't edge cases. These are basic productivity tasks. Things I do daily with other AI tools without even thinking about it.

The Dissonance Is Real

Here's the thing: I've had voice conversations with Perplexity. It feels like watching "Her" v0.1. Not perfect, but you can see where it's going. It responds naturally. It understands context. It adapts.

Having a conversation with Siri feels like talking to a primitive chatbot from 10 years ago. More frustrating than helpful.

And that dissonance—the gap between what top-tier AI can do and what Siri offers—shows just how far behind Apple and Google really are.

What This Means

I'm not saying Siri needs to match Claude's reasoning capabilities overnight. But the difference isn't just about features. It's about expectations.

When you use Claude, Opera Neon, or even ChatGPT daily, you start expecting AI to understand you. To adapt. To work with context and nuance.

Siri doesn't do that. It's still a list of hardcoded commands wrapped in a voice interface.

Imagine the Alternative

Think about how good Apple's OS could be if their AI were even close to Claude's level.

Not as good. Just close.

Imagine asking your phone a complex question and getting a thoughtful, contextual answer instead of "Here's what I found on the web."

Imagine voice assistants that actually assist instead of just executing preset commands.

We're not there yet. But some of us are getting close.

Just not Apple.

What's your experience? Do you still use Siri regularly? Or have you noticed the same gap I have? I'd love to hear your take.

In Ten Years, Everyone Can Be a Developer

In ten years, everyone can create their own app. Hell, even a browser!

How many times have I written on this blog the magic sentence "mark my words"? I believe a certain number of times. Maybe even too many.

But here's another one: mark my words.

I'm a product manager. I don't have developer skills. Probably won't learn any soon, at an acceptable level.

But hey, I don't have to anymore.

The New Execution Model

I'm certain—in ten years, everyone can be a developer. You have an idea, and the execution is a matter of how well you operate with AI. And how stubborn and resilient you are.

That's it. Idea + AI fluency + persistence = shipped product.

A Gorillaz Browser, Anyone?

Let's say I'm a die-hard Gorillaz fan. I want to create a browser with their leitmotif. Here's what Claude suggests when I ask for 5 unique selling points:

Me: Let's say I want to create a desktop browser for the Gorillaz band fandom. What would be 5 USPs?

Claude:

Phase-shifting UI — The browser's visual theme dynamically transforms to match the current "Phase" era of Gorillaz (Phase 1's raw comic aesthetic, Phase 4's psychedelic neon, etc.), making the browsing experience feel like living inside the band's evolving universe.

Murdoc's Dark Web Radar — A built-in privacy/tracker blocker styled as Murdoc's suspicious paranoia meter, showing blocked trackers with lore-accurate commentary and insults from the characters.

Kong Studios New Tab — Every new tab opens as an interactive Kong Studios hub—your bookmarks, speed dial, and widgets are embedded into the animated studio environment with the four characters present.

Noodle's Translation Engine — A built-in multilingual page translator with a personality layer, framed as Noodle's polyglot skills, with optional character voice narration for selected text (using the band's iconic audio aesthetic).

2D's Playlist Sidebar — A persistent music sidebar that surfaces Gorillaz tracks, remixes, and fan-curated playlists synced with Spotify or YouTube, styled around 2D's melancholic but dreamy personality—with mood-based recommendations tied to your browsing context.

Not bad for 30 seconds of work.

How This Actually Gets Built

Then I "hire" AI code assistants. When I have enough resources (AKA $$$), I "hire" ten AI agents, and I have my browser within a month.

When I see how fast the AI environment changes—and it looks like exponential growth—I'm certain it's possible.

What This Means

The barrier to building software isn't technical knowledge anymore. It's vision. Persistence. The ability to communicate what you want clearly enough that AI can help you build it.

That's a completely different skill set. And it's one that more people have access to.

The question isn't whether you can code. The question is whether you can imagine, iterate, and stick with it long enough to ship.

What would you build? If you could create any app or tool without needing to write code yourself, what would it be? I'd love to hear your ideas.

Managers Aren't Getting Younger—The Data Proves Me Wrong

I'm a big football fan—or soccer, if you're in the US. I love the history, the data, the statistics. Recently, I had a friendly argument with a fellow football enthusiast. My claim: young managers are taking over elite football. His claim: not at all.

Here's the thing about the Internet: you can't just let people be wrong.

The Hypothesis

I wanted to test my theory quickly and effortlessly. My hypothesis: the average age of trophy-winning managers has been decreasing over time. In other words, managers are younger when they win major trophies now than they were in the past.

To test this, I used Opera Neon. Here were my three prompts:

Analyze Champions League teams from 1992 until 2025. See who was the manager when winning the trophy. Check their age. Calculate the average age of all managers and the 5-year moving average.

Analyze UEFA Cup/Europa League winner teams from 1992 until 2025. See who was the manager when winning the trophy. Check their age. Calculate the average age of all managers and the 5-year moving average.

Analyze Premier League teams from 1992 until 2025. See who was the manager when winning the trophy. Check their age. Calculate the average age of all managers and the 5-year moving average.

The Results

Plot twist: managers aren't getting younger. My gut feeling was completely wrong.

The chart above shows the 5-year moving average for all three competitions. The trend is clear: manager ages have been increasing, not decreasing.

Champions League (1992-2025)

• Overall average age: 47.79 years
• Youngest winner: Pep Guardiola (38, Barcelona, 2009)
• Oldest winner: Raymond Goethals (71, Marseille, 1993)
• Recent trend: The 5-year moving average increased from 43.8 in 2007 to 56.2 in 2024-2025

UEFA Cup/Europa League (1992-2025)

• Overall average age: 48.35 years
• Youngest winner: André Villas-Boas (33, Porto, 2011)
• Oldest winner: Gian Piero Gasperini (66, Atalanta, 2024)
• Recent trend: Moving average rose from 42.6 in 2014 to 56.6 in 2025

Premier League (1992-2025)

• Overall average age: 51.61 years
• Youngest winner: José Mourinho (42, Chelsea, 2004-05)
• Oldest winner: Alex Ferguson (71, Manchester United, 2012-13)
• Recent trend: Moving average peaked at 63.4 in 2010-11 (Ferguson's dominance), then dropped to around 50 in recent years

The Power of AI Research

Here's what made this effortless: I spent less than a minute writing three prompts. Opera Neon handled all the research in the background, pinged me with updates, and delivered complete analysis. No Wikipedia rabbit holes. No manual spreadsheets. Just pure, automated research.

The data reveals experienced managers—particularly Carlo Ancelotti and Pep Guardiola in recent years—have actually driven the average age upward, not downward.

What's Next?

To get a fuller picture, I could analyze the top 4 finishers instead of just trophy winners. That would reveal whether younger managers are breaking into elite football at the highest level, even if they haven't lifted trophies yet.

What I Learned

Data beats gut feeling. Every time.

I was convinced young managers were taking over. The numbers show the opposite. The 5-year moving averages are trending upward across all three competitions, proving that experience still dominates elite football.

And AI made hypothesis-testing absurdly easy. One minute of prompts. Zero manual research. Complete analysis delivered on a silver platter.

What's your take? Do you think younger managers will start dominating in the next decade, or will experience always have the edge? Let me know what you think.

Not Good at It? Or Just Not Honest About It?

"I'm not good at sports. Languages. Mathematics. You name it."

When I hear myself—or someone else—say those words, I get a glitch.

Is this true? Is this something I actually believe? Or is this just an excuse I tell myself?

The Real Question

Is this really about not being good at something? Or is it about not being honest with myself?

Am I too afraid to admit I haven't thought it through? Too scared to say I have other priorities right now?

The Trick We Play on Ourselves

It's hard for me to believe I can't reach a decent level at anything.

So instead of admitting this to myself, I pull a trick. I figure out yet another plausible explanation. I construct a narrative that sounds reasonable but dodges the real issue.

"I'm not good at languages" sounds better than "I haven't prioritized learning a language."

"I'm just not a math person" feels safer than "I chose to focus my energy elsewhere."

Why Honesty Matters

Facing reality—acknowledging where we actually are—is the first step toward change.

Without honesty, it's hard to even start.

When I say "I'm not good at this," I'm closing a door. I'm telling myself the story's already written.

But when I say "I haven't prioritized this," I'm acknowledging a choice. And choices can always change.

What I Learned

The language we use with ourselves matters.

"Not good at it" suggests something fixed. Permanent. Beyond our control.

"Haven't prioritized it" acknowledges agency. It admits we're making trade-offs, whether we realize it or not.

Both might describe the same current reality. But only one leaves room for change.

What about you? Is there something you tell yourself you're "not good at"? What happens when you reframe it as a choice about priorities instead?

AI Ain't Funny: Testing Which AI Tells the Best Jokes

I've had this nagging impression: AI is good at many things, but not at telling jokes, being funny, or creating witty punchlines. Every time I ask an AI to be funny, I get dad jokes. Or should I say "dAId jokes"? ;-)

Then I read this article from The Athletic about ski jumpers. Let's just say it was begging for a punchline, meme, or literally any kind of reaction.

The story? Ski jumping's latest "marginal gains" rumor: athletes may be injecting hyaluronic acid into their penises—not for vanity, but to "measure bigger," get looser suits, and catch more air like a sail. No one's named, but WADA says it'll investigate if evidence appears.

Instantly, several punchlines and retorts came to mind in my native tongue. They were witty, if I do say so myself :-D

But then I wondered: how would AI handle this? I'd been suspecting AI wasn't funny, and I wanted to test that theory once and for all. This article was perfect—easy material for anyone with a sense of humor.

The Experiment

I asked several AI providers to create funny punchlines, taglines, and retorts. The goal was simple: compare them and subjectively decide which one was actually funny—and which one won the dAId jokes competition.

Here's the prompt I used:

Here's the article: https://www.nytimes.com/athletic/7024688/2026/02/05/ski-jump-penis-enhancement-wada/ Read it carefully. Prepare 3 witty punchlines (up to 200 characters) I can use to create a meme for that article.

The Results

Gemini

When they said 'every inch counts' in the Winter Olympics, I don't think this is what they meant.

Forget the V-style—apparently, the new way to get more lift is the 'D-style.'

WADA: 'Is it doping?' FIS: 'It's a sail.' The rest of us: 'It's a bit much for 5 extra meters.'

ChatGPT

When they said 'go big or go home,' ski jumpers took it personally.

WADA checking ski jumping… now scanning everything FROM THE GROUND UP.

Olympics 2026: Breaking records and bending… rules?

Claude

WADA investigating 'Penisgate.' No hard evidence yet, but officials promise to rise to the occasion.

Scientists confirm every centimeter counts. Ski jumpers taking notes. Norway already caught 'adjusting' their suits.

Athletes willing to inject acid into their junk for 2.8 extra meters of flight. That's Olympic-level commitment, folks.

Neon

When you said "enhance your performance," I didn't think you meant at the tailor. Ski jumpers: redefining suit measurements, one bulge at a time.

WADA officials: "We'll investigate." Also WADA officials: Googling 'can you really ski jump with that?'

Other sports: blood doping. Ski jumpers: bulge doping. Aerodynamics just got a lot more... interesting.

Perplexity

When the ski jump goes from gravity to groin-gravity in one leap.

Took off like a champ, landed like science class—strictly no physics allowed.

Peak performance, zero chill: physics says "drop" and so does the ground.

My Subjective Ranking

1. Claude, option 1 - "Penisgate" with the "rise to the occasion" pun? Chef's kiss.
2. Claude, option 2 - The Norway callback was specific and landed well.
3. Neon, option 3 - "Bulge doping" is genuinely clever.

What I Learned

Here's the thing: AI isn't terrible at humor. But it's safe. Too safe.

The best human jokes walk a line. They're specific. They reference real things. They take risks. AI models are trained to be helpful and harmless, which means they naturally pull their punches.

Notice how Claude's responses were edgier than the others? Interesting. But even then, they felt calculated. Like someone trying to be funny rather than actually being funny.

The dAId joke theory holds up.

Which one made you laugh? Or better yet—what punchline would you have written? I'd love to hear what you came up with.

Markdown Will Be the New Doc Format. Screenshot This.

Take a screenshot of this prediction. Come back in a few years and prove me wrong: Markdown will be the new doc format.

I've spent the last few months conducting product analysis with Claude Code, examining user behaviors in our product. That means hours in the Terminal. Prompting, prompting, and more prompting.

And something interesting happened.

The Accidental Shift

Since most of my analysis happens locally, I stopped using Google Docs. Stopped using Google Spreadsheets. I create summaries, notes, and instructions locally via Claude Code.

Claude uses .md. Markdown.

And you know what? It works absolutely fine. I have everything I need in a clean, nice, minimalistic format. No formatting bloat. No compatibility issues. No waiting for documents to load.

Just text. Structured text.

Why This Matters

Here's the thing most people haven't noticed: AI coding assistants are changing how we create documentation.

Not intentionally. Not because someone decided "Markdown should be the standard." But because when you're working with an AI, Markdown is the path of least resistance.

It's already there. It's fast. It's readable.

The Network Effect Nobody Saw Coming

How will this affect Markdown adoption? I suspect significantly.

First, it's happening quietly. Most people outside the developer community don't even realize this shift is occurring.

But people using AI on daily basis are creating more documentation than ever before. They're doing analysis. Writing specifications. Creating knowledge bases. And increasingly, they're doing it in Markdown through AI assistants.

That's a massive behavior change happening under the radar.

What Happens Next

When developers document in Markdown by default, their teams start reading Markdown. Then those team members start writing in Markdown. The format spreads.

Add to that: more people are using AI assistants. More of those assistants default to Markdown. More people get comfortable with the format without realizing they're learning it.

It's not replacing Word documents for corporate reports. Not yet, anyway.

And let's be clear: Google Docs and Microsoft Word aren't going anywhere for collaborative work. Real-time collaboration with comments, suggestions, and tracked changes? Word and Google Docs still dominate. When you need multiple stakeholders reviewing a document simultaneously, seeing exactly who changed what, and managing permissions across an organization, those tools are irreplaceable.

Markdown has version control through Git, sure. But that's a developer workflow. Most people aren't going to learn Git just to collaborate on a document.

But for individual knowledge work, technical documentation, analysis, and internal communication? Markdown is quietly winning.

Why I'm Confident

I'm making this prediction because I've watched it happen to myself. I didn't decide to switch to Markdown. I didn't evaluate alternatives. I didn't plan a migration.

I just started working differently. And Markdown became my default because it was there, it worked, and I had no reason to leave.

If that's happening to me, it's happening to thousands of others.

Screenshot this. We'll see.

Do you use Markdown? Did you choose it deliberately, or did you just... end up there?

What Would You Do If You Weren't Afraid?

Once upon a time, I walked down an alley and there was a litter bin. Gray, dirty, ugly, and a bit dented. Nothing to see there.

But it was a special bin.

It had a label on it that said: "What would you do, if you weren't afraid?"

It caught my attention. I'd never heard that before.

The Ultimate Stopper

What a powerful question.

I started wondering. Indeed, fear is the ultimate stopper for me. What if I did a thought experiment where I eliminated that factor? What if I could do everything, knowing there wouldn't be any fear?

Excellent question.

When to Use It

Once in a while, I ask myself this question, especially when I get stuck.

Not every day. Not as a mantra. Just when I notice resistance. When I'm avoiding something. When I'm making excuses. When I know what I should do but can't seem to start.

That's when this question cuts through everything else.

Try It Yourself

Ask yourself this question. See where it will get you.

You might be surprised by what comes up. Not because the answer is revolutionary, but because you already knew it. You just needed permission to admit it.

PS: Here was my answer back then. If I weren't afraid, I would open a pizza food truck for surfers on Canary Island.

What's yours?

I Stopped Using Stack Overflow. So Did Everyone Else.

I stopped using Stack Overflow. I recently noticed this. Before that, it was my primary point of contact. When I had a question about developing, and Google returned Stack Overflow in the results, I automatically headed there.

And then I stopped. I don't know when exactly. Probably when I discovered AI could answer my questions and the quality was at least good enough.

Was I the only one? I decided to check that.

Here's what I found.

The Data Tells a Story

I queried the Stack Overflow API for every month from August 2008 to December 2025. That's 18 years of data, covering the entire history of Stack Overflow.

The numbers tell a dramatic story.

Peak (March 2014): 207,258 questions per month December 2025: 4,470 questions per month

That's a 98% decline from the peak. But the decline didn't start immediately. Stack Overflow grew exponentially from 2008 until it peaked in 2016 at 2.1 million questions per year. Then it started declining.

Here's the complete history:

The Growth Years (2008-2016):

• 2008: 57,159 questions (4 months of operation)
• 2009: 340,305 questions (+495%)
• 2010: 688,587 questions (+102%)
• 2011: 1,180,358 questions (+71%)
• 2012: 1,613,093 questions (+37%)
• 2013: 2,018,896 questions (+25%)
• 2014: 2,117,461 questions (+5%)
• 2015: 2,179,745 questions (+3%)
• 2016: 2,187,227 questions (+0.3%) ← Peak year

The Plateau and Early Decline (2017-2022):

• 2017: 2,101,316 questions (-3.9%)
• 2018: 1,878,739 questions (-10.6%)
• 2019: 1,756,920 questions (-6.5%)
• 2020: 1,856,838 questions (+5.7%)
• 2021: 1,536,518 questions (-17.2%)
• 2022: 1,340,557 questions (-12.8%)

The Collapse (2023-2025):

• 2023: 792,293 questions (-40.9%)
• 2024: 401,603 questions (-49.3%)
• 2025: 130,099 questions (-67.6%)

When It Changed

Look at those year-over-year changes. Notice anything?

From 2009 to 2013, Stack Overflow grew by double digits every single year. Sometimes triple digits. It was unstoppable.

Then growth slowed. By 2017, it started declining modestly. 2020 even saw a brief uptick (+5.7%), possibly from pandemic-driven coding activity.

But 2020 to 2021: -17% decline. 2021 to 2022: -13% decline. People were still asking questions, just fewer.

Then 2023 hits. A 40.9% drop in a single year. Followed by 49.3% in 2024. Then 67.6% in 2025.

What happened in late 2022 that would cause this? ChatGPT launched on November 30, 2022.

The timing isn't a coincidence.

Looking at the full 18-year history, you can see four distinct eras:

• Growth Era (2008-2014): Average of 95,426 questions/month
• Peak Era (2015-2018): Average of 173,896 questions/month
• Decline Era (2019-2022): Average of 135,225 questions/month
• Collapse Era (2023-2025): Average of 36,777 questions/month

The most dramatic shift happened between the Decline and Collapse eras. Right when AI assistants became widely available.

What This Actually Means

Stack Overflow didn't become worse. The questions didn't disappear because developers stopped coding. They disappeared because developers stopped needing to ask them publicly.

When I hit a coding problem now, I don't:

1. Search Google
2. Click through to Stack Overflow
3. Read five different answers
4. Try them all until one works

I just ask Claude or ChatGPT. I get an answer immediately. It's specific to my exact problem. It explains why it works. And I can ask follow-up questions.

Why would I go back to Stack Overflow?

The Methodology Question

Before you ask: yes, I validated this data. I analyzed 24.1 million questions across 216 months (August 2008 - December 2025). I checked the API responses, tested multiple endpoints, and documented every limitation of this approach.

The Stack Overflow API's total field might not be perfectly accurate. It could be off by thousands. But it can't be off by millions. The trend is real.

If you want the full methodology breakdown with all the caveats about deleted questions, timezone handling, API limitations, and validation queries you can run yourself, I documented everything here.

What about you? When's the last time you asked a question on Stack Overflow? And if you stopped—did you notice when?

Data & Methodology

This analysis is based on 24,177,714 questions collected via the Stack Exchange API v2.3, covering 216 months from August 2008 through December 2025.

Key Findings:

• Peak month: March 2014 (207,258 questions)
• Peak year: 2016 (2,187,227 questions)
• Decline from peak to December 2025: 98%
• Most dramatic drop: 2023 (-40.9% year-over-year)

For complete methodology, data validation queries, limitations, and reproducibility details, see the full methodology document.

Don't Make Me Think About Your Email

Here's the message I got in my Imbox this morning. (I use "Imbox" since I use Hey as my email provider—more on that here).

What does it say? To be honest, nothing actionable or informative to me.

Here's What Happened

1. There's a fitness club chain called Zdrofit
2. I visited one of their locations a couple of times
3. I received this email:

Hey! With the start of the new year, we're sharing good news—starting January 7, we've extended opening hours at selected Zdrofit clubs! 🏋️‍♀️

New hours: 📅 Mon. – Fri.: 6:00 – 23:00 📅 Sat. – Sun.: 7:00 – 22:00

Not sure if this change applies to your club? Check the website or ask on-site. 📍

Well. It's not useful to me.

What They're Really Saying

"We're too lazy to check if this information is useful to you, so we're sending it anyway. You figure out if it's relevant. By the way, we don't care if you actually wanted this email or not."

That's not how you build trust. That's how you train people to ignore you.

The Three-Item Checklist They Ignored

Before you send any marketing email, check these three boxes:

1. Ask for Permission

First of all, I didn't give permission. I visited this gym occasionally, maybe three times total. When they set up an account for me, they didn't ask if they could stay in touch. All I wanted was to pay for a day pass and use their equipment.

Now they think they have the right to send me "informative" emails.

They don't.

No permission = No email.

2. Add Value

The email says: "We have gyms in our chain. Some of them may or may not have changed their operating hours."

What's in it for me? Nothing. Absolutely nothing.

To make this useful, I'd have to:

• Visit their website
• Navigate to the club locator
• Find the specific location I went to
• Check if anything changed

That's four steps. Four steps to discover information they already know and could have just told me.

No value = No email.

3. Don't Make Me Think

This is the core problem. They sent information that requires me to investigate whether it's relevant.

That's backwards.

If you have my data—and you do, because I used your service—you should use it to make my life easier, not harder.

No simplicity = No email.

My Response

I opted out. Thanks to Hey's interface, it took one keyboard shortcut. Two clicks maximum.

Gone.

How It Could Have Been Done

If this email had followed the three rules, here's what it might have looked like:

Subject: Extended hours at Zdrofit [specific location name]

Hey [Name],

You've visited our [specific club location] in the past, and we wanted to let you know we've extended our hours starting January 7:

New hours: Mon. – Fri.: 6:00 – 23:00 Sat. – Sun.: 7:00 – 22:00 (Previously: Mon-Fri 7:00-22:00, Sat-Sun 8:00-21:00)

This means more flexibility for early morning or late evening workouts.

If you'd prefer not to receive updates like this, [click here to unsubscribe].

See you at the gym, [Actual person's name]

Notice what changed:

• Specific club location (I know this applies to me)
• Before/after comparison (I understand what changed)
• Why it matters (I know how it benefits me)
• Easy opt-out (I control the relationship)
• Personal sign-off (There's a human behind this)

That's an email worth reading.

If You're Responsible for Email Marketing

Here's your checklist. Print it. Tape it to your desk. Use it before you hit send.

Before You Send ANY Email:

1. Permission Check

• Did this person explicitly opt in to receive this type of message?
• Can they easily opt out?
• Would I be surprised to receive this if I were them?

2. Value Check

• Does this email solve a problem or provide useful information?
• Is the information specific and actionable?
• Would I personally find this worth reading?

3. Simplicity Check

• Is everything they need to know in this email?
• Does this require them to do extra work to understand?
• Could this be clearer or more direct?

If you can't check all three boxes, don't send the email.

The Books That Explain Why This Matters

If you work in marketing and haven't read these, start here:

• "Don't Make Me Think" by Steve Krug - About reducing cognitive load (applies to everything, not just websites)
• "Permission Marketing" by Seth Godin - About earning the right to communicate

Both books teach the same fundamental idea: respect people's time and attention.

When you fail to do that, they'll do exactly what I did.

They'll unsubscribe.

Have you received emails like this? What's your threshold for hitting "unsubscribe"?