FrankWiles.com

Productive Throw Away Tools

Today I’m giving you permission to be lazy!

Actually, the word lazy has some bad connotations to it. Let’s reframe that to be efficient or ergonomic instead, because that is what we’re really doing when we build tools.

If the tool gets you over a speedbump or saves you even a couple of minutes more than it took to create it, it is worth doing!

I built two stupid simple tools and they easily doubled my productivity for the morning.

The Situation

Today I’m working on a product idea and before I invest a bunch of time in this idea I wanted to build a little proof of concept to collect all the data (think telemetry data) that would be necessary to make the product useful and thus successful. In the interest of time I don’t want to build a user interface for this, I just want to spit out the data in JSON as nicely formatted as possible. So that’s what I’m doing.

The Problem(s)

I’m saving time by not building a bunch of UI related code, which is great. But the problem is now I don’t have a great way to visualize the data I’m capturing. What the code is doing is creating a unique directory per run in the format session_YYYYMMDD_HHMMSS (e.g. session_20250607_125713) and creating a few dozen JSON files filled with my data.

In this situation I’m not really concerned with how big the data is, the total size of of one of these directories is 200K to 300K. Small enough I don’t have to care about efficiency at all.

This IS a throw away tool after all right?

I realized I have two problems:

  1. I quickly end up with dozens of these directories as I work on the code which is messy and annoying
  2. While the date/time format is an obvious way to store this but makes it harder than it should be to look at the most recent run

Neither of these are real problems.

They’re speedbumps that slow me down and make me focus on the wrong things. When my brain wants to be looking at the data it first has to figure out, several times an hour, which run is the latest and which file I want to open.

I lose the focus.

I lose the flow.

The Solution

I figured there had to be a way to have just make this easier for me. So I was super lazy and asked Claude to create me two just recipes to solve the two problems I’m having.

Here they are:

just
# Clean up old session directories, keeping the latest X (default: 5)
session-cleanup keep="5":
    #!/usr/bin/env bash
    set -euo pipefail

    # Find all session_* directories sorted by modification time (newest first)
    sessions=($(ls -dt session_* 2>/dev/null || true))

    if [ ${#sessions[@]} -le {{ keep }} ]; then
        echo "Found ${#sessions[@]} session directories, keeping all (limit: {{ keep }})"
        exit 0
    fi

    # Calculate how many to remove
    to_remove=$((${#sessions[@]} - {{ keep }}))
    echo "Found ${#sessions[@]} session directories, removing $to_remove oldest (keeping {{ keep }})"

    # Remove the oldest directories
    for (( i={{ keep }}; i<${#sessions[@]}; i++ )); do
        echo "Removing ${sessions[$i]}"
        rm -rf "${sessions[$i]}"
    done

# Change to the latest session directory
latest-session-path:
    #!/usr/bin/env bash
    set -euo pipefail

    latest=$(ls -dt session_* 2>/dev/null | head -n1 || true)

    if [ -z "$latest" ]; then
        echo "No session directories found" >&2
        exit 1
    fi

    echo "$latest"

The first allows me to run just session-cleanup and have it keep the last five runs. Or just session-cleanup 1 to keep the very last one. With just’s command line completion this really becomes just s<TAB> so it’s quick and easy.

The second gives me the relative path of the latest run. Which is useful, but not quite as useful as it could be.

So I wrote a third which opens all of the files in the latest run in NeoVim!

just
open-latest-session:
    nvim $(just latest-session-path)/*

Having a just recipe call another one is a great pattern to use FYI. Now I can execute just open-latest-session and instantly view these JSON files in NeoVim which itself makes it easy to move between each file, search for specific keys, etc.

And again command line completion makes this just o<TAB>.

What now?

I spent maybe 90 seconds prompting Claude, waiting for it’s response, and pasting it into my Justfile. I spent maybe another minute or two making my open-latest-session command as I think I had to give it a couple of tries to get the shell syntax correct.

I was time ahead after running them a few times.

Which is why this works! If I had to spend 30 minutes writing and debugging these I wouldn’t. I wouldn’t see the time risk as worth the expected gain. I’d just suffer through.

With these I was able to iterate on my REAL PROBLEMS faster. Catch mistakes where the wrong data was collected or when it was placed into the wrong bit of JSON structure more quickly.

I was focused and far more productive for hours with a couple of minutes spent on tool building.

Where in your projects should you be building STUPID LITTLE TOOLS like this?

Hopefully this was useful to you. I find these little bits of extremely specific productivity gains awesome when someone shows them to me, please share this with your friends and coworkers you think would it benefit!

Headshot of Frank Wiles

Frank Wiles

Founder of REVSYS and former President of the Django Software Foundation . Expert in building, scaling and maintaining complex web applications. Want to reach out? Contact me here or use the social links below.