A few years ago I submitted a pull request that felt pretty solid. A couple hundred lines of changes, some new business logic, a refactor or two baked in because I was already in there. I was proud of it, but then I waited and waited. A week later, the review came back with 42 comments. Not 42 nitpicks, but 42 actual questions and concerns, some of which pointed out that I had built the whole thing on top of an assumption that was wrong from the start.

I had to throw out about a third of the work.

What Is a Feedback Loop, Exactly?

A feedback loop is the cycle between "I did a thing" and "I found out if the thing worked." Write some code, run it, see what happens. That's the basic "development" loop that we do hundreds or thousands of times a day. The shorter the time between those two moments, the tighter the loop, and the less work you throw away when something is wrong. The difference between a 30-second loop and a 30-minute loop is massive.

Why Smaller Is Better

When something is wrong, you want to find out after 10 lines, not 300. The 42-comment PR hurt because I had spent so much time on a flawed assumption. A quick conversation earlier in the week or smaller, more incremental PRs would have saved hours.

Short loops also make it easier to learn. When the gap between action and result is tight, your brain can connect the two. Long delays break that connection. You forget what you were thinking when you wrote the code.

Long loops also invite context switching. When you're waiting on a build or a review, you move on to something else. Switching back is mentally "expensive," and smaller loops let you stay in flow.

The best thing is that the scope of failure stays smaller. A bug in a 10-line change is easy to find, but the same bug somewhere in a 400-line PR is going to get past even the best human reviewer.

Where to Shrink Your Loops

There are four areas where I've seen the biggest "wins".

1. Local Development

This one is the most immediate. If you're making a change, saving the file, manually refreshing the browser, and waiting on a slow boot sequence every single time, that friction is adding up constantly.

For my <scott.keck-warren.com> site, I use make develop, which spins up Jigsaw with hot reload. For Laravel projects, I lean on php artisan serve paired with a watcher. The goal is that feedback from a change should arrive in under a few seconds. If it's taking longer than that, your local setup deserves a look.

If you're still hitting F5 manually every time, I would suggest you start there. It's a small thing with a surprisingly large daily impact.

2. Automated Tests

This is where a lot of teams feel the pain without realizing it. A test suite that takes 15 minutes to run isn't really feedback: it's a blocker. Developers stop running it locally and only find out things are broken in CI, which means the loop just got 30 minutes longer.

Making the tests faster helps, but often the better move is running fewer tests more often. Run only the tests related to what you're working on right now. Most PHP testing tools support this. With PHPUnit, you can filter by test name or file. Pair that with a watcher (I like phpunit --watch setups or just a shell alias), and you get near-instant feedback on the code you're actually touching.

Save the full suite for pre-push or CI and run just the relevant slice constantly while you work.

3. Code Reviews

This is where the 42-comment story lives. The single biggest thing you can do to speed up code review feedback is make your PRs smaller.

Smaller PRs get reviewed faster because they're easier to reason about. They will come back with fewer comments because there's less surface area for things to go wrong. Conversely, when comments do come back, they're easier to address because you still remember exactly why you made every decision.

I try to keep PRs under 200 lines of meaningful change. If a feature is bigger than that, I look for a way to split it. Something like a refactor PR first, and then the feature on top. It feels like more overhead, but it consistently moves faster end to end.

4. Deployments

Infrequent big deploys are stressful. Something goes wrong, and you're hunting through a huge changeset trying to figure out which of the 80 commits caused the issue. Frequent small deploys are boring, which is exactly what you want from a deployment.

If you're deploying once a week, try twice a week. If that works, try daily. The first few times feel uncomfortable, but it becomes normal fast, and once it does, you'll wonder how you ever felt okay shipping a week's worth of changes in one go.

Feature flags help here too. You can deploy code that isn't active yet, which separates the act of shipping from the act of releasing. That buys you a smaller, lower-risk deploy without slowing down the feature work itself.

One Thing You Can Do Today

Pick the longest feedback loop in your current workflow. Not the hardest to fix, just the longest. Maybe it's a test suite you stopped running locally, a PR you've been fattening up for two weeks, or a deploy process that only happens on Fridays.

Shrink that one loop and see what happens to your day.

The 42-comment PR taught me the cost isn't just time. You're also paying in rework and the slow erosion of momentum that comes from rebuilding things you thought were done. Tight loops don't fix everything, but they remove one of the most consistent sources of that drag.