Fast Feedback Loop and Delayed Gratification

For the past few months I have been working on some side-projects that took way longer than I expected, or initially planned.

This was partly due to my mistake of keep expanding their scope, but also because I underestimated the time investment needed. Shocking! Planning estimates gone wrong…

These delays sometimes demotivate me, or even trigger second-thoughts if I should even be doing these projects in the first place. Should I spend my time somewhere else instead?

My projects being delayed is not the purpose of this article though.

Delayed Gratification

I was always the kind of person that delays instant short-term gratification for a better outcome in the long-term.

In my younger days, I was studying hard to learn things well, get good grades to get into a good university years after, and building the skills to get a nice job.

In sports (volleyball), I trained for weeks, months, or years, in order to feel the excitement, satisfaction, and that amazing dopamine rush when we won matches or tournaments.

In other words, I am used to working hard now, for a better outcome later.

This is what delayed gratification means, and is explained nicely in James’ Clear article “40 Years of Stanford Research Found That People With This One Quality Are More Likely to Succeed”.

A fast feedback loop is most often mentioned as part of Agile methodologies for project management/execution, modern developer tooling and platforms that promise faster iterations, and more. In general, it’s a popular pitch line for “something” increasing your productivity and output.

To me, fast feedback loop means that whenever I do something, anything, I am able to observe some kind of response back soon thereafter. Some feedback that indicates if what I did was good, bad, or if it had any effect at all.

When I am writing software code, I want to have a very fast feedback loop between the time I write the actual code to the moment when I know it’s functionally correct. Having good tooling that allows me to run unit tests as fast as possible (or a live-updating UI) the moment I save my code changes is absolutely crucial to my daily workflow.

I also want a tight feedback loop from when I merge my changes to the time I get feedback from customers actually using them. I want to have a continuous, fast, reliable way of shipping changes to production, and then also a way to get feedback on how it’s doing. That comes through metrics we define, complaints reported from customers, or even social media.

The Realization of the conflict

Let’s get back to the realization I had. 😅

Having a fast feedback loop seems to be in conflict with delayed gratification.

How can you build something that requires months or years, when you need a little amount feedback, a little gratification, all the time?
What can keep you going through hard times, when there is nothing to show for it yet?
How can you justify spending so much time on something, without getting something in return?

Even though I have embraced delayed gratification for most of my life, I now seem to need a fast feedback loop for most things I do. I can confidently argue that this is a side-effect of my day job as a software engineer, and it’s now influencing my attitude towards life too.

I realized though, that these two powerful behaviors are actually not in conflict with each other.

I have always been getting fast feedback, even when working towards very long-term big goals.

With midterm and final exams at school, you get feedback every few weeks. At sports, I play local tournaments every few weeks/months, and my teams always played in league competitions spanning months with matches at least once a month. In my day job, I get feedback during local development with good tooling. I get customer feedback through fast iteration on features and observability of the system behavior through metrics every time we release something.

The rookie mistake I did with my side-projects is that I had set these humongous goals at the beginning, without any small iterative milestones that would be completed every few weeks.

I was missing that dopamine boost.

I call this a “rookie” mistake because I already knew about this principle. Splitting big chunks of work into smaller pieces is essential for my day job. I read about agile and lean development from myriad books. And I still did the mistake…

One of my main projects is to create an advanced online course for Continuous Integration and Continuous Deployment (CI/CD) (elementsofcicd.com). Building the content for several months now, felt like writing a book, where you cannot get customer feedback until the whole book is finished, printed, then sold, and then getting your gratification.

I made a mistake. I should have taken small sections of the course and publishing them as articles. Maybe making a few smaller courses out of the sections that stand on their own, and releasing them even if the main course is not yet ready.

This would give me feedback, satisfaction, and the gratification that would keep me going to build the bigger, more complete, course I initially planned.

Life rule

This is now a rule for me, at work, and at life.

If I want to get things done, I need to adjust my environment, and my tasks, such that I maintain a fast feedback loop whilst at the same time delaying my gratification for the ultimate goal.

Finding a way to get continuous little-gratifications, in order to be able to get that delayed huge-gratification, is crucial.

“Most people optimize for the day ahead. A few people optimize for 1-2 years ahead. Almost nobody optimizes for 3-4 years ahead (or longer).

The person who is willing to delay gratification longer than most reduces competition and gains a decisive advantage.

Patience is power.”

— By James Clear in “3-2-1: The value of nature, controlling your attention, and designing your environment”