How to Leverage Your Daily Feedback Loops to Achieve to Your Goals Faster

A feedback loop is an essential part of all but the most straightforward control systems. And, if you care about achieving any goal, such as:

• learning,

• building a working application, or

• making money.

  
  

Then, you’re dealing with a non-trivial control system. Let’s take a look at the key features of an effective feedback loop and how you can use it in your IT career.

The faster, the better

The sooner you know whether things are going well or poorly, the better. There is no advantage in moving forward in the dark. If you’re already on a good path, the feedback will reinforce your commitment to what you do now. If you’re doing something wrong, you can just correct your course when you get feedback.

Imagine how complex driving or riding your bike would become if your vision were delayed by even a fraction of a second. It would be enough to produce effects similar to drunk driving.

Depending on the system's complexity, acting on that knowledge can still require time. If you learn that your current career is not for you, you’ll still need a few years to get a new one. But you would much rather find this during your first semester at the university instead of after graduating.

Your daily feedback loops

Let’s think for a while about all the feedback loops you are part of every day as a developer.

Code changes

As you work on the code, you have to check the impact of your changes on the code's behavior. Automated tests are a quick and solid way of getting feedback. Writing tests takes time upfront, but it allows you to be more productive in the long run. That’s even without considering the long-term quality impact of keeping them around.

With complex logic, I often prefer to start with tests. Just wrapping my head around all the internal details is difficult, and I would much rather do it once while writing tests and not every time I change something in the code.

Day-to-day work on a ticket

If you’re working on a well-organized team, some other team members will review your work. Having your work reviewed is a great way to learn the team’s way of doing things, as well as to learn more about programming craft. But it can be frustrating if you spend a day or two working on a ticket and then get more than 40 comments on the merge request.

You can speed up the feedback you receive by breaking your work into small steps and reaching out for feedback after each of them:

1. After you read a ticket, paraphrase it to someone who understands what it’s about well. If your understanding is wrong, they will be able to correct you.
2. Write down how you plan to approach the solution—and get another developer to review it before you spend time implementing it. Maybe they will point out something you didn’t know about.
3. The most important, though, is the feedback on program logic. Ask for a review while you’re still updating the tests.

Application version

As the sprint progresses, there is a growing pile of unreleased changes waiting to be published. It would make sense to wait only if you have some elaborate testing protocol and if this time is well spent. If no meaningful testing is happening, you’re only delaying the feedback from the users. When possible, try deploying as often as you can.

In this way, instead of a big release with all the changes (and bugs) your team made within a few weeks of sprint, you release a small part of it every few days.

The market fit of the product

Even on a bigger scale, this still applies. With methodologies like agile or lean startup, the goal is to put out your product as soon as possible and get feedback from the market.

What about the quality of the feedback?

Not all feedback is created equal. It’s always somewhere on a spectrum—from accurate test results to a person's subjective opinion giving the feedback.

In the case of objective input, such as:

• tests failing or feature not working as expected,
• applications being measurably slow, or
• other performance indicators being outside of expected values

It’s often a good idea to immediately start addressing it.

In case of subjective opinion:

• coding approach
• the naming of variables or methods
• any other thing those different developers could fix in a different way

Here, things are more subtle. You could be going against a well-established convention in the project, or your naming could be indeed confusing—things that it’s best to fix soon. On the other hand, sometimes people share how they would do things, but more so having a conversation about how things should be done in the project.

How about you?

Have you ever gotten feedback that shaped your career? Please share your story; I would love to hear it!