`du` Plus `sort` Is How You Find Disk Hogs Without Clicking Through Folders for an Hour

The usual disk-space failure mode: your machine says storage is nearly full, and then you spend thirty minutes opening random folders instead of measuring anything.

Why this workflow matters

Developer machines accumulate large things quietly: container layers, derived data, caches, screenshots, node modules, local model weights, build outputs, logs, archives. Disk pressure rarely announces its source politely.

That is why du matters. The POSIX man page describes it as reporting file space usage, which sounds basic, but it is exactly the kind of basic truth you need before cleanup decisions become intelligent.

The command people should know

Start with a readable summary of immediate children:

du -sh ./*

Then sort the result:

du -sh ./* | sort -h

Now the directory sizes are human-readable and ordered. You are no longer cleaning based on vibes.

Why this is better than file browser guessing

Because large disk problems are not always where you emotionally expect them to be. The folder you think is enormous may be fine, while some forgotten cache directory is eating tens of gigabytes.

Measurement first changes the conversation from:

1. “I think Docker is the problem”

to:

1. “This exact directory is 34G, so now I know where to inspect.”

That is a huge difference in debugging quality.

Useful variants

See top-level items in the current directory:

du -sh ./*

Check a specific parent directory:

du -sh ~/Library/*

Show the largest entries at the bottom:

du -sh ~/Library/* | sort -h

Or reverse for biggest first if your platform supports it:

du -sh ~/Library/* | sort -hr

The exact command can vary slightly across environments, but the principle does not: measure, then rank.

Why developers clean the wrong thing

Because they optimize for familiarity instead of size. They delete a few screenshots because they understand screenshots. Meanwhile, Docker, simulators, caches, or large model files keep dominating the disk.

This is why a ranked view is so useful. It forces your attention toward the biggest candidates instead of the most obvious ones.

A practical cleanup approach

Once the heavy directories are visible:

1. confirm what the directory actually contains
2. decide whether it is reproducible or valuable
3. clean the specific tool using its own supported mechanism when possible

That last point matters. If Docker is huge, use Docker cleanup commands. If Xcode derived data is huge, clean derived data intentionally. The size report tells you where to look; it does not replace domain-specific cleanup.

Why this belongs in a developer’s default toolkit

Disk issues are not glamorous, but they are recurring. A short du | sort workflow saves time precisely because it avoids blind cleanup. The command line becomes a diagnostic instrument, not just a place to run builds.

The real advantage is confidence. Once you know exactly which directories are huge, cleanup stops feeling like desperate deletion and starts feeling like a targeted maintenance task.

Final recommendation

When your machine is low on space, stop clicking through folders randomly. Use du to measure directory sizes and sort to rank them. The fastest route to cleanup is usually not more browsing. It is one honest list of what is actually big.

Sources

• POSIX du manual page
• GNU Coreutils manual