September 2026
My best hit rate on any codebase is on arguments a function accepts and then ignores.
Most of my moto work is this. moto mocks AWS, so every backend has to match a published API surface. The signature gets written from the AWS docs on day one, which means the parameter is there and typed and named correctly. Then the body implements the common path and the parameter never gets read. Nothing fails. The call returns a plausible answer that quietly ignores half of what you asked for.
The first is a filter that filters nothing. GetConnections took a Filter and returned everything. Kafka's list took a cluster name and a cluster type and applied neither. ResourceGroups took Filters on tag sync tasks and ignored them. CodeDeploy took includeOnlyStatuses and listed every deployment regardless.
These are the worst kind to hit in a test suite, because a filter that returns too much usually still contains the thing you were looking for. The assertion passes. You find out when you write a test for the empty case and it comes back with four rows.
The second shape is a response field that is the wrong thing. QuickSight returned a version number where the API returns a version ARN. Kafka echoed your own pagination token back at you as the next token, so a loop over it never terminated. Glue took HidePassword and returned the password.
That last one is the reason I keep looking. A flag whose entire purpose is to not show you something, and it shows you the thing.
Open the method. Read the signature. Then search the body for each parameter name. If a name appears once, in the signature, that is the bug. No tooling, no static analysis, nothing clever. It takes about a minute per method and most methods are fine.
The variant worth knowing is the parameter that is read but only stored. It gets written to the object and nothing ever reads it back. Slower to spot because the name does appear in the body, and you have to follow it one hop further to see that the hop ends there.
Error paths are the same idea pointed the other way. S3Control accepted a pagination token that could not possibly be valid and carried on. FSx deleted a file system that did not exist and returned success. The API specifies an exception for both. Nothing raised one. Finding these is reading the published error list for an operation and checking which of them the code can actually produce.
It needs no context. I do not have to understand what Glue is for to see that Filter is in the signature and nowhere else. That makes it the one thing I can do productively in a repository on the first afternoon, before I know anything.
It is also unambiguous in review. There is a specification, the code does not match it, and the diff is small. Nobody has to decide whether they agree with my design taste. That matters more than it sounds: the slow PRs are not the hard ones, they are the ones where a maintainer has to form an opinion first.