Why Your Feedback Loop Is Slowing You Down
All too often, I see developers fall into the trap of relying on full-stack local environments or real data access. It’s nice and comfortable because you have everything you need in one spot, but if you’re waiting minutes or hours for every feedback cycle, you’re wasting time. Every second you spend waiting for a test run, a database query, or a full local environment to spin up is time lost that could be spent iterating on your code.
So, how do we move faster without sacrificing stability? The answer lies in optimizing your feedback loop.
Velocity
Being able to write code faster means shipping more features, but speed without stability is like driving a race car with no brakes. Nobody enjoys debugging spaghetti code at 2 AM. That’s where code velocity comes in. We’re taking inspiration from DORA Metrics, which measure:
- Deployment frequency (How often do you ship changes?)
- Lead time for changes (How long from acceptance to deployment?)
- Change failure rate (How often do deployments break things?)
- Time to recovery (How long to fix a broken deployment?)
We will focus on metrics 2-4 – how fast you build, how robust your work is, and how quickly you can fix issues. Deployment frequency is more of a team and DevOps driven metric than your personal way of working. So, how do we propose to improve our velocity… by focusing on your feedback loop.
Feedback loop
Your feedback loop is the workflow between making a change in the code and seeing the impact/outcome of that change, and hopefully verifying that it is behaving as expected. This can range from tweaking a UI, adding a database field, or improving a machine-learning model and seeing if your predictions improve. These all have various forms of validation, and in most cases you have to go through all of them before moving your feature to “done”. Before diving into leveraging your feedback loop to build faster, we will touch on some stages of the development cycle.
- Writing code – where you are putting code on the page in your preferred editor
- Compiling code – compiling code to executer (depending on language).
- Unit tests – running a unit test locally
- Committing code – committing and pushing code to your repo
- Pull request and CI/CD – the PR for your feature branch, where hopefully there are some CI/CD checks setup
- Integration tests – automated or manual integration tests of your feature (rarely automated in fast paced builds)
- End to end test – and end to end test of the system, incorporating your new changes
- Release and validate – a final release with your changes, now in the hands of the users
Why does it matter?
Great, now we know all about our feedback loop, and the development cycle. So the reason these are both important are, as a rule of thumb:
The earlier in the cycle, the faster the feedback
Imagine having an IDE that instantly catches a silly mistake, like a wrong argument name for a function versus having to deploy and run a 2 hour machine learning pipeline just to discover that same typo. The closer to step #1 you catch a mistake, the less time you waste.
All too often I see developers fall into the trap of relying on full-stack local environments or real data access. While useful, this approach plants you deep into Stage #6 —- a slow place to iterate. It’s nice and comfortable because you have access to everything you need in one spot, but if you’re waiting minutes or hours for every feedback cycle, you’re wasting time.
How to improve
Let’s talk about concrete actions that you can incorporate into how you work to shift your work earlier in the development cycle and leverage that sweet sweet speedy feedback we’ve been talking about. Some of these are big topics onto themselves, so we will only touch on them, but will flag where a future post could be on the cards.
When you write your code
Alright, so the first place to get feedback is when you are writing code in your IDE before you execute or commit anything. Getting as much feedback here about the correctness and structure of your code massively speeds up the process of needing to fix silly little mistakes, like a typo, or using an argument that doesn’t exist.
Setup linting in your IDE
Linters are fantastic tools! Set this up straight away at the start of any project. There are a bunch of these for different languages, test them out, find the ones you like, but just make sure you have it installed as part of your dependencies, and setup in your editor. My preferred python linter is pylint, I’ve found it checks for more errors compared to tools like flake8. I have been meaning to try ruff as a faster alternative, so watch this space for a comparison.
Here is a quick example:
You can see I’ve tried to call a function get_roles, but didn’t specify the required arguments. The linter in my IDE is the difference between:
waiting to finish writing the rest of my code, running the code, the error to pop up, reading and interpreting the error message, finding the broken code, going to fix it, and… fixing it write after I write the function I want to use because linter gives me some nice red squiggles telling me to pay attention because I’ve made a boo boo.
Future post: setting up with python in VS Code
Use typing where possible and integrate into your IDE
Use typed code, be as strict as you can (this is a balance between making sure you’re code is well structured and understood, and battling the type checker just to get something working). This means using types even in a dynamic language like python, or using typescript over javascript. Again, you should setup the type checker in your IDE to catch a whole other batch of errors, like an if statement over an enum and forgetting one of your cases, or not having an “invalid” case.
After a while you will also find yourself using less generic structures, like a plain old dictionary, and instead using a simple dataclass. It might seem a little superfluous at first, but you will soon see a range of benefits from this little change:
- I don’t have to worry about using the wrong key to access a value, the linter will tell me if I got it wrong. Your autocomplete will probably give you a list of all the valid attributes making life even easier.
- I can add types to my function and argument definitions, that way when I’m writing my function I know exactly what structures I’m dealing with instead of having to keep it all in my head
- I can validate that my data matches the structure I’m expecting. This is super helpful for loading configurations or validating API calls
Lastly it forces you to think a little bit harder about the structure of your code and the concepts and objects that are relevant, which leads us to our next improvement.
Design before you code
Design, design, design. Jumping straight into implementation can feel productive — until you realise you built a house of cards. It’s so easy to gloss over this, especially when you’re on a tight timeline. I know it will feel counter intuitive, but this will save you time and effort in the long run.
Good design -> less refactoring -> happier engineer
When code is well structured it will be easier to write, easier to understand, and more maintainable. There is a balance here between over engineering and adding in just enough flexibility to separate out your important concepts, and that will come with time and experience.
This doesn’t need to be a fully fledged, 4 tiered design. It can be as simple as writing a little bit of pseudo code to capture the important flows and concepts for what you are trying to achieve before writing any code. This forces you to create a little bit of structure and separate out important concepts so that you don’t fall into the trap of scripting out the entire feature in one go.
Future post: good code design and how to build intuition for it
Local testing
Leverage unit tests
Use unit tests! They feel like extra work, especially when you can just use your local environment, but there are several additional benefits of using unit tests to do a large chunk of your work before transitioning to your local/integrated environment.
- Better code structure – If your code is really hard to test, it probably needs a refactor. If you test early you will design your code to be more testable, and in most cases lead to better structure.
- Small area of focus – A unit test is meant to be small, and so it lets you focus on a small portion of the code at a time, reducing the mental capacity you need to develop that bit of code.
- Fast feedback! Unit tests run quickly, often less than a second compared to potentially several seconds of running in a full local environment. This means you can churn through iterations to get your function to do exactly what you want.
- Better collaboration – Unit tests provide great examples of what your code is supposed to do, and it means others can edit your code with confidence without needing to understand the whole system.
Future post: unit testing in python
Dependency injection and mocking infra
This approach requires a bit more setup, but for complex systems or applications, it offers greater control and simplifies development and debugging. To do it well, you’ll need a structured architecture — I’m a fan of Domain-Driven Design, but any layered design works—as well as a solid grasp of dependency injection.
This means abstracting interfaces and creating multiple implementations of key components. While it takes extra effort, the benefits are worth it:
- A fully functional local dev environment, even when your app depends on external infrastructure
- Faster feedback cycles, since everything runs in memory
- The ability to unit test code that would otherwise rely on real infrastructure
- Seamless transitions as infrastructure and environments evolve
That last point is especially valuable in consulting, where tight deadlines often mean building before infrastructure is even available. In some cases, you may not know what the final stack will be. This approach lets you move fast now while keeping things flexible enough to adapt when the real infrastructure comes online.
Future post: test mocks and stubs in python
Committing code
Alright, so now we’ve written a bunch of code, and that code should be pretty correct in a lot of ways if we have followed the tips above. Time to commit it to history!
Setup your pre-commit hooks
Use pre-commit hooks. They’re easy to set up and ensure every commit meets a baseline quality standard. More importantly, they keep code consistent across the team, making it easier for everyone to navigate unfamiliar parts of the codebase.
There are plenty of pre-commit hooks available, and you can use them to run nearly any development tool. My go-to hooks for any project include:
- Code formatting – Eliminates formatting debates and makes git diffs cleaner, so spotting actual code changes (instead of whitespace tweaks) is much easier.
- Linting – Catches basic mistakes early (see above for why this is a game-changer).
- Type checking – Ensures correctness before runtime errors do.
- Configuration file validation – Keeps json, yaml, and toml files properly structured.
- Security checks – Helps prevent accidental secrets or credentials from leaking into the repo.
These checks only run on the files you’re committing, making them faster than full-repo PR checks. That’s why running pre-commits before CI/CD is worth it—it saves time and prevents avoidable failures later.
And if you ever need to skip them (rare, but it happens), just use -n when committing—low effort, high reward.
The only real catch? Make sure everyone enables pre-commit hooks when setting up the repo. It’s an easy step to overlook, so add it to your setup guide and remind your team to check that it’s running.
Future post: pre-commit setup
Atomic commits
There’s plenty of material online about atomic commits and why they matter, so I won’t rehash it all. The TL;DR? An atomic commit is a self-contained change that can be reversed without breaking the codebase. Every commit should leave the project in a working state—meaning you can jump to any point in git history and still run the code.
Focusing on atomic commits keeps your git history cleaner and easier to follow. Two key scenarios where this really pays off:
-
Debugging mysterious bugs – In young codebases with limited testing and automation, bugs can slip in unnoticed. A well-structured commit history makes it much faster to pinpoint where an issue was introduced. You can check each commit one by one, running the code to verify when the bug first appeared.
-
Juggling multiple features at once – Let’s say you’re working on Feature A, but midway through, you realize it would be much easier if Feature B existed first. Instead of letting them become tangled, you:
Finish the isolated commits for Feature B. Create a new branch, cherry-pick those commits, and raise a PR for Feature B. Once merged, rebase your Feature A branch, make necessary updates, and only then raise a PR for Feature A. Now, you have two clean, independent PRs—easier to review, debug, and revert if needed—without disrupting your workflow. This avoids the dreaded “all-in-one” mega-commit and keeps your history structured and maintainable.
PR and CI/CD
Setup CI/CD
Your CI/CD pipeline doesn’t need to be fancy—just get something simple in place. Modern tooling makes this ridiculously easy. Grab a template, drop it into your repo, and boom—GitHub Actions (or your tool of choice) is now doing useful things for you.
The best time to set this up? Right at the start. Even a bare-bones script for linting and formatting will save you from painful, repo-wide cleanup later. I never start a project—even a personal one—without some basic CI/CD in place.
A minimal setup ensures consistency from day one and prevents a massive, retroactive cleanup effort when bad formatting or missing checks pile up.
Future post: quick github actions
Enforce checks in your PR process
If you’re working in a team, require PR checks. At minimum:
- One (preferably two) reviewers for every PR
- CI/CD checks—which should at least include pre-commit hooks and unit tests (if available)
This simple process catches issues early and keeps quality high without adding much friction.
Integration testing onwards
Be disciplined
By now, you’ve done everything possible early in the development cycle. Your code is written, linted, unit-tested, committed, pre-commit checks passed, PR raised, and CI/CD green-lit. All that’s left is final validation in an environment as close to production as possible.
This is where the feedback loop is slowest, so ideally, there’s little to fix here. If you’ve followed the earlier steps, this phase should be smooth sailing, and you can deploy with confidence.
But if a bug does slip through, don’t fall into the trap of debugging it at this late stage. Instead, reproduce it earlier—at the unit test level if possible. Debugging is much faster when you’re working in a controlled, iterative environment, and it gives you clear proof that the issue is resolved before it ever reaches production.
Future post: developer discipline
What to expect
By optimizing your feedback loop, you can:
- Ship faster without increasing failure rates.
- Reduce debugging time by catching errors early.
- Improve maintainability, making collaboration easier.
The goal isn’t just speed — it’s sustainable speed. A well-structured feedback loop ensures that velocity doesn’t come at the cost of stability. By implementing these practices, you’re not just coding faster; you’re coding smarter, making fewer mistakes, and ultimately delivering better software with less frustration.