The job of a developer isn’t to write code.
It’s to write code that works.
That might sound silly, but the implications are big. It's important to put processes in place to ensure the correctness of the code we write. For example, we use tests to verify the expected behavior of a piece of code. We also submit PRs to give other developers a chance to vet the changes we’re trying to make.
Developers rely on feedback loops to ensure code quality
These processes that we put in place are known as feedback loops.
Feedback loops provide insight into the development process. First, you write some code, and then you run through a series of checks to make sure the code is accurate. Usually, developers focus most of their attention on writing code. In this post, we’ll look at how optimizing feedback loops can improve the development process.
A proper feedback loop leads to a more efficient development cycle.
Types of feedback loops
Not all feedback loops are the same.
There are many types of feedback loops that serve different purposes. Some feedback loops are used locally by developers. Other feedback loops are set up later in the process and rely on input from multiple people.
Here are a few examples of feedback loops:
CI / CD Pipelines
Feedback from app users
The feedback loops at the top of the list are more developer-centric. As we go down the list, the feedback loops start to involve other people.
More frequent feedback loops are better
Feedback loops only provide value if they’re used.
Ideally, every feedback loop would run on every code change. But that's not practical and would be inefficient. Too much time would be wasted. That said, as a general rule, the more often a feedback loop runs the better.
It's important to strike a balance. Frequency shouldn't reduce the value of the feedback loop.
Frequent feedback loops are good, but long-running feedback loops should run less often. So optimizing your feedback loops can improve the development process.
So how should you go about optimizing your feedback loops?
Shift your optimization efforts left
As a developer, my biggest concern is with the optimization loops that directly affect me.
If we take a look at the list from above, that means focusing on optimizing the items toward the top of the list. The linting and testing steps are usually a good place to start.
Linting should be set up in your IDE. Nowadays, it’s rare for a linting issue to pass my local development and fail at the CI / CD pipeline stage. Most IDEs show you feedback directly in the code as you’re working.
Automated testing is another area for improvement
Unless your test suite is slow, it can be useful to run your tests whenever you commit code. If your tests are slow, then try setting up your environment to only run tests relevant to the code you’re changing.
It’s not a silver bullet, but the more often you validate your code, the less often you’ll be writing code that breaks your app.
Optimized Feedback Loops = Higher Quality Code in Less Time
One of the worst experiences as a developer is having a slow feedback loop.
Slow feedback loops take you out of a flow state. In my experience, it leads to distractions and a worse developer experience. If the feedback loop is too slow, then developers might even skip the loop completely.
At that point the feedback loop is worthless.
The closer the feedback loop is to the developer, the less tolerance there is for a slow feedback loop. Faster feedback is a recipe for success.
Not only does it improve your developer experience, but it’ll improve the experience of everyone on your team.
Improvements spread across a team leads to even more time saved!