I wanted every crossing of the I-90 floating bridge in 240 drive folders of dashcam footage, 1,958 GB, for a montage. I wasn’t going to watch the footage to find them, and my Rivian R1T’s GPS was too coarse to. What found them was the color of the lights in the Mount Baker tunnel, which sits at the Seattle end of the bridge. Brightness couldn’t see that tunnel. A red/blue ratio found it on 71 of the 79 bridge drives scanned, and a person looking at one frame per candidate confirmed 68 crossings. How to sort months of dashcam footage with Claude Code has the rest of the job this was one stage of.

Signals instead of pixels

The footage already describes itself if you read the right parts of it. Each 15-minute segment carries one GPS fix, at its start, in the container’s location tag. That sorts drives by area, but one fix per 15 minutes can’t place a bridge crossing to the minute, let alone the second.

The finer signal is in the keyframes. The truck writes one keyframe per second. Decoding only those, downscaled to 64 × 48, gives a per-second record of a drive and skips the 29 frames between them. Each second becomes four numbers: the mean change in green from the previous keyframe, which I called motion, and the mean red, green and blue. That record was computed once, cached as CSV, and every detector afterward read the cache instead of the video.

The first calibration read a motion of zero everywhere, parked or moving. The cause was ffmpeg duplicating the keyframes back up to 30 fps, so every frame was compared with a copy of itself. -fps_mode passthrough fixed it. The bug showed up only because the check ran on a known parked segment and a known moving one before it ran on anything else. A detector that reads zero on both cases is measuring itself.

Why brightness failed

A tunnel should be the easiest thing in a drive to find: the outside goes away and the picture gets darker. In this footage it doesn’t get darker. The camera’s auto-exposure raises the gain as the light drops and holds the frame’s brightness close to what it was in daylight. That’s what the exposure control is for, and it erases the one property a brightness threshold depends on.

Why color worked

Exposure scales brightness, and the hue of the lamps comes through. The Mount Baker tunnel is lit by sodium lamps, and sodium light is orange. Inside the tunnel, the front camera’s mean red rises above its mean blue. That ratio is the whole detector.

It runs with three guards:

• The red/blue ratio has to stay above 1.0 for 25–150 seconds, so a single orange frame or a long orange stretch doesn’t count.
• A rolling median smooths the ratio first, so one bright frame inside a tunnel doesn’t break the run in two.
• The first and last 3 minutes of every drive are ignored, because parking garages look the same to the ratio.

On the 79 bridge drives scanned, it found a tunnel on 71. Seven of the eight misses were after dark. My reading is that the ratio describes light, and once the light outside is artificial too, a tunnel stops standing out from the road around it.

Detector proposes, person confirms

Finding a tunnel isn’t the same as finding the right one. A drive on I-90 passes more than one stretch that reads as a tunnel, including the Mercer Island lid, and most drives had several candidates. The obvious rule, pick one tunnel by its position in the drive, was right about two times in three.

I could have spent the effort on a better rule. Instead the tool writes a guess for every drive and a contact sheet to check it against, then stops. Each row of the sheet is one drive, and each tile is a frame from the bridge side of one candidate. The bridge is unmistakable in a frame, so the right column is obvious, and the edit is one number in a picks file, which the cut turns into synced clips. Reviewing that way confirmed 68 crossings. Two night drives couldn’t be confirmed, because a dark frame of a dark bridge proves nothing, and one drive had no crossing among its candidates.

The layout of the sheet mattered as much as having one. The first version was a flat grid of every candidate frame, and it was easy to match a tile to the wrong drive. One row per drive makes that mistake visible rather than merely possible.

The sheet is also an instrument, and an instrument can be wrong. At one point I announced that the picks for some drives were the Mercer Island lid, not the Mount Baker tunnel. The sheets had been built with a seek that ffmpeg applied after tiling, so they showed a different window than the one they claimed. Extracting the same frame two ways exposed it, and the picks had been right all along. When a result contradicts work that was already verified, check the instrument before the conclusion.

The review step reads like an admission that the detector wasn’t good enough. I think it’s the reason the detector could stay simple. Take a rule that’s right two times in three, and add a sheet a person reads at a glance. That beats a rule that’s right more often and still needs someone to check it.

Signals that could not separate the cases

The same per-second record answered four other questions, and each answer was no for the same reason: the signal moved for the thing I wanted and for something I didn’t.

• Parked footage. Near-zero motion found parked time reliably, but there was little to find: 23 GB of the 1,760 GB scanned, because with Gear Guard turned off, the truck stops recording seconds after it parks.
• Hard stops. A sudden change in the picture marks braking, but turning changes the picture as much. Of 875 candidates, all 12 at the top were turns into parking lots or ordinary stops.
• Traffic jams. Sustained low motion should mark crawling traffic, but the neighboring cars keep moving, so the picture keeps changing and a jam looks like driving.
• Garage boundaries. A gray band at the top of the frame marks a concrete ceiling on a clear day, but an overcast sky is the same gray. The boundary was set by timing instead.

None of these is fixed by tuning a threshold. When a signal can’t tell two cases apart, a better number for the threshold still can’t.

Close passes did work once the frame’s overall brightness change was subtracted from the side cameras: 37 of the top 60 were real passes. A person still had to sort them.

Signals the camera leaves alone

A camera processes its own picture before anything reads it, and that processing exists to make the picture look normal. Auto-exposure made a tunnel look like daylight and left the lamp color intact. Before measuring anything in recorded video, ask which properties the camera flattens and which it passes through, and build on the second kind.

My claim: VBScript’s friction is what produced PowerShell’s object pipeline, and the same friction is what moved cloud tooling from imperative scripts to declarative templates. The history is worth a few minutes because it predicts what the next tool will fix.

On Error Resume Next

In 2003, mapping a printer by security group or reading the BIOS version of 500 servers had no command. It had Notepad, and a .vbs file run by Windows Script Host.

VBScript had no safety rails. The line that opened most production scripts was:

On Error Resume Next

It tells the interpreter to ignore any failing line and carry on. Distributed systems talk about failing fast; a VBScript failed silently and left the system in whatever state the last successful line produced. Nobody wrote it out of carelessness. Without it, one missing printer stopped that user’s logon script at that line, and every mapping after it was skipped. Structured error handling in VBScript was awkward enough that swallowing errors was the pragmatic choice.

WMI as the engine, VBScript as the crank

The lasting legacy of that era isn’t VBScript’s syntax. It’s that VBScript was how a generation of administrators met WMI, Windows Management Instrumentation, Microsoft’s implementation of the DMTF’s WBEM standard. WMI exposed the operating system as a queryable database: disks, services and processes as rows, with a SQL-like language to select them.

The database was good. The interface to it was this:

' Free space per logical disk
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_LogicalDisk")

For Each objItem in colItems
    Wscript.Echo "Disk: " & objItem.Name & " Free Space: " & objItem.FreeSpace
Next

Seven lines to read one property, and every line is ceremony: a COM moniker, a query string, a loop and string concatenation to print. The verbosity forced administrators to learn loops, variable types and COM objects, which is the one thing VBScript did for the profession. It was a high barrier, and it separated the people who clicked from the people who scripted.

From parsing text to passing objects

Every VBScript that read another program’s output parsed text. Jeffrey Snover’s Monad Manifesto (2002), the design document behind PowerShell 1.0 (2006), names that practice as the problem. Text output is a contract nobody declared, so a script is coupled to the exact formatting of whatever it reads. When “Free Space” became “FreeSpace”, the script broke.

PowerShell separated the data from its presentation. The same query, in the modern cmdlet:

# Objects, not text
Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID, FreeSpace

Side by side, the two snippets show a change of model, not of syntax. VBScript was imperative: you told the computer how to connect, how to iterate and how to print. PowerShell is declarative at the call site: you ask for the object and the pipeline handles the rest. Formatting happens once, at the end, by a formatter that knows the object’s type.

Why this matters for cloud work

Cloud tooling made the same move, a decade later. The first generation of AWS automation was imperative scripts around the CLI: create an instance, wait, attach a volume, tag it. CloudFormation (2011) and Terraform (2014) replaced that with a declared end state and an engine that computes the steps.

VBScript was the imperative-scripts phase of Windows administration. It was hard to debug and didn’t scale past the person who wrote it. It was also necessary: it’s how administration got from the GUI to anything automated at all, and the pain of it is what made the next model’s advantages legible.

What would change my mind

The argument rests on one causal claim: that text-parsing friction, not some other pressure, is what produced the object pipeline. The Monad Manifesto supports it in Snover’s own words, which is the best evidence available short of the design meetings. The account could be a retrospective tidying of decisions made for other reasons, such as .NET adoption inside Microsoft. If it is, the lineage still holds but the lesson doesn’t.

I still keep a folder of old .vbs scripts. I do not run them. They are a record of what the tooling cost before someone decided the cost was the problem. The next time a CloudFormation template takes an afternoon to debug, the alternative was On Error Resume Next.

Here is a line it exists to fix. It opens an incident on a status page through a REST API, with the token and the JSON body already in variables:

Invoke-RestMethod -Uri 'https://status.example.com/api/incidents' -Method Post -Headers @{Authorization="Bearer $token";Accept='application/json'} -ContentType 'application/json' -Body $body -TimeoutSec 30

It works. It’s also a line you have to read three times, and not because it’s wrong. It doesn’t scale — not in execution time, in comprehension time. The computer parses it in microseconds. A person parses it in minutes, even the person who wrote it.

Splatting turns that line into a block you can read at a glance, and it’s worth using less as a convenience than as a discipline.

Six months later

A script like this is usually written in one sitting, for a job that needs doing that evening, by someone who knows exactly what every argument is for. Commands run across several lines on backtick continuations, parameters stack one after another, a hashtable sits inline.

Six months later the person reading it doesn’t know, even when it’s the same person.

The failure isn’t correctness. The script still runs. The failure is that a one-line change, a different endpoint, means re-deriving what the whole line does before anyone dares touch it.

A script its own author can’t debug after six months has a problem, and so does every script written the same way.

What makes a line hard to read

Cognitive load is the effort it takes to hold something in your head long enough to understand it. In a command line it comes from a few places at once.

Syntax you have to parse while reading. Where does the list of extensions end? Is that parenthesis inside the script block or after it?

Get-ChildItem -Path D:\Exports -Include *.csv,*.json -Exclude *-keep.* -Recurse -File | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } | Remove-Item -Force

Density. One line means one chunk. The brain can’t break it into pieces and check them separately.

Missing context. Why D:\Exports? Why fourteen days? What makes a file worth keeping? None of that is in the code; it’s in the head of whoever wrote it, or in a document somewhere else.

Any one of these is manageable. The one-liner stacks all three.

What splatting forces

Splatting takes two steps: put the command’s parameters in a hashtable, then hand the whole table to the command with @ in place of $:

$incident = @{
    Uri         = 'https://status.example.com/api/incidents'
    Method      = 'Post'
    Headers     = @{
        Authorization = "Bearer $token"
        Accept        = 'application/json'
    }
    ContentType = 'application/json'
    Body        = $body
    TimeoutSec  = 30
}

Invoke-RestMethod @incident

Same call. More lines. Far less to hold in your head, for four reasons.

Every parameter is named and on its own line. Nothing is positional; nothing depends on order.

The structure is visible. The headers are a nested block, not a run of braces in the middle of a line. You can see that the call posts JSON, with a bearer token, to one endpoint.

Changing it is safe. Adding a header is adding a line. Deleting a parameter is deleting a line. There’s no adjacent argument to break.

Comments fit.

$incident = @{
    Uri         = 'https://status.example.com/api/incidents'
    Method      = 'Post'
    Headers     = @{
        # Read the token from the vault, never from the script.
        Authorization = "Bearer $token"
        Accept        = 'application/json'
    }
    ContentType = 'application/json'
    Body        = $body
    # Fail fast; the caller retries.
    TimeoutSec  = 30
}

None of this is for the computer. It’s for the person reading the script later — probably you, and if not you, someone who can’t ask you.

People first, computers second

There’s an old Unix principle: write programs for people first, computers second. Not because the computer doesn’t matter, but because the human is the slow part. The machine executes the dense one-liner in the same time as the splatted block. The human pays for the density every single time they read it.

Splatting is a forcing function for that principle. To splat, you have to name every parameter, arrange them in a structure, and decide what you’re passing. You can’t throw arguments at a cmdlet and hope.

Rules that are not obvious

Splatting is simple until it isn’t. These are the parts that trip people up.

It’s @params at the call and $params everywhere else. The hashtable is a normal variable; only the call site uses @. Writing Invoke-RestMethod $incident passes the whole table as the first positional argument, and the error message will be about a type conversion, not about splatting.

Switch parameters take a boolean. Recurse = $true, not Recurse = 'yes' and not a bare Recurse. A hashtable value has to be a value.

You can mix splatted and explicit parameters. This is the pattern for a common base with a per-call difference:

$common = @{
    Headers    = @{ Authorization = "Bearer $token" }
    TimeoutSec = 30
}

Invoke-RestMethod @common -Uri "$api/components"
Invoke-RestMethod @common -Uri "$api/incidents"

PowerShell merges them. Naming the same parameter in both places is an error, which is what you want — a silent override would be worse.

You can build the table conditionally. A one-liner can’t express “add this parameter only if the variable is set”; a hashtable can:

$copy = @{
    Path        = $source
    Destination = $target
    Recurse     = $true
}
if ($DryRun) {
    $copy['WhatIf'] = $true
}

Copy-Item @copy

A function can pass its own parameters straight through. Inside a function, $PSBoundParameters is a hashtable of the parameters the caller supplied, and it splats:

function Get-RecentLog {
    param ([string]$Path, [switch]$Recurse)
    Get-ChildItem @PSBoundParameters -Filter *.log -File |
        Sort-Object LastWriteTime -Descending |
        Select-Object -First 10
}

Whatever the caller passed goes through unchanged, and whatever they didn’t pass isn’t mentioned at all. It’s the cleanest way to write a wrapper, and it only exists because splatting does.

Arrays splat positionally. @('a', 'b') splatted fills parameters by position, not by name. It’s legal and almost never what you want in a script you intend to read later.

Bigger commands, bigger differences

The gap between the two forms grows with the command. Here is the incident call once it runs from a server. It goes through a proxy, sends a user agent the status page can identify, and retries when the status page answers with an error.

Invoke-RestMethod -Uri 'https://status.example.com/api/incidents' -Method Post -Headers @{Authorization="Bearer $token";Accept='application/json';'X-Request-Id'=$requestId} -ContentType 'application/json' -Body $body -TimeoutSec 30 -UserAgent 'deploy-bot/2.1' -Proxy 'http://proxy.corp.example:8080' -ProxyUseDefaultCredentials -MaximumRetryCount 3 -RetryIntervalSec 5

One command, eleven parameters, one of them a table. Now the same call, splatted:

$incident = @{
    Uri                        = 'https://status.example.com/api/incidents'
    Method                     = 'Post'
    Headers                    = @{
        Authorization  = "Bearer $token"
        Accept         = 'application/json'
        'X-Request-Id' = $requestId
    }
    ContentType                = 'application/json'
    Body                       = $body
    TimeoutSec                 = 30
    UserAgent                  = 'deploy-bot/2.1'
    Proxy                      = 'http://proxy.corp.example:8080'
    ProxyUseDefaultCredentials = $true
    MaximumRetryCount          = 3
    RetryIntervalSec           = 5
}

Invoke-RestMethod @incident

Longer, and easier to understand, modify and debug. When the proxy changes, the proxy is one line you can find. MaximumRetryCount and RetryIntervalSec need PowerShell 7. To run the same call on Windows PowerShell 5.1, you delete those two lines; nothing around them changes.

When not to splat

Splatting is a tool for commands that are hard to read. Applying it to commands that aren’t adds lines and nothing else.

One or two parameters. Get-Content 'settings.json' doesn’t improve with a hashtable.

Interactive use. At the prompt you’re the only reader, and you’re reading it right now.

Idioms everyone knows. Get-ChildItem | Where-Object Name -like '*.log' is a pattern PowerShell users recognize on sight; splatting it hides the idiom.

The rule I use: splat when future-you would have to re-read the line to understand it. For most scripts that turns out to be most of the non-trivial calls, and almost none of the trivial ones.

Documentation you no longer need

A splatted call documents itself in two places. The variable name says what the call is for; the table says how:

$openIncident = @{
    Uri         = 'https://status.example.com/api/incidents'
    Method      = 'Post'
    Headers     = @{
        Authorization = "Bearer $token"
        Accept        = 'application/json'
    }
    ContentType = 'application/json'
    Body        = $body
    TimeoutSec  = 30
}

Invoke-RestMethod @openIncident

The one-liner needed a comment above it to say what it did. This doesn’t. Comments still earn their place for why — why this endpoint, why this timeout — but what is now in the code, where it can’t drift from the code.

Readability compounds

Every future change to a script starts with reading it. A bug fix, a new parameter, an upgrade to a newer module: read first, then edit. The cost of an unreadable line is paid on every one of those visits, for as long as the script is in use. The scripts that matter stay in use for years.

Splatting is a small feature. What it represents is larger: optimize for the person who will maintain the code, not the machine that will run it. The machine is fast and doesn’t care whether the call is one line or twenty. The person is slow and cares whether they can understand it without an afternoon of archaeology.

Splatting is how a script written in one evening stays usable for the next several years.

References

• about_Splatting (opens in a new tab) — the PowerShell documentation, including $PSBoundParameters and positional splatting
• Basics of the Unix Philosophy (opens in a new tab) — Eric Raymond on writing for people first