Process as a Proxy for Motivation | Hacker News Reader

Process as a Proxy for Motivation

bengodfrey.dev

68 pointssudo-bendg25 comments

This is a really well-written short article, and I agree with it completely.

I just wanted to add as well that, as someone who has read quite a lot of books on self-help and productivity, there is one that makes a lot of similar points: "Triggers: Creating Behavior That Lasts--Becoming the Person You Want to Be"

https://www.goodreads.com/en/book/show/22544758-triggers

I recommend it to anyone who agrees with this article and feels like a book-length treatment of similar ideas would be helpful to them.

> I was burdened with the mental labour of making this decision

But why, I always enjoyed having a choice. I also drove for a long time with several roads to choose, and I liked that each time I could like "naah, the sunset must be better on that road tonight, let's check it out" or "hopefully there's some fog going down the slopes today on another road". It's not labour, it was fun to play, kept out of boredom. Sometimes I even took roads that took longer just to have something new.

I believe you dread choices only when you try to min-max your life, overoptimizing every single choice. Just relax and let the life go its way.

Wow, thanks, I'm cured.

Before giving out asinine advice like "just relax and let the life go its way", you may want to consider if doing that was an option, the person would have done it already. It's the equivalent of telling a depressed person to "cheer up".

If you don't struggle with executive dysfunction, that's fantastic. But you're also not the intended audience for this article. Avoiding losing hours of one's day to decision paralysis isn't the same as trying to min-max or overoptimise.

I think the strongest version of this idea is that process is basically a way of spending willpower once instead of repeatedly

This is a good one. Sometimes it doesn’t even matter if the made decision is suboptimal. It’s better than no decision.

Opinionated linters is an example.

Sometimes you just gotta turn your brain off and move forward.

Agree. My team standardized on black in our Python CI/CD pipeline and precommit hooks and it was surprising how much time we reclaimed from not having to review coding style and discuss patterns. The compromise was to apply black and not think about it. And it worked out really well. This was back in the days when humans still wrote code XD

> ... I would just have a rule which I had to follow.

I don't mean to be a downer, but to prevent anxiety I try not to be so strict with myself.

A process can be freeing at first, but eventually the idea can seep in that I'm missing out, wasting precious time on earth, or that I'm "trapped". Nothing triggers a panic attack quite like depersonalization/derealization.

I try to question whether my motivations are covering up fear. I don't want to be so afraid of decision fatigue that it locks me into even more misery.

Anyway it's for that reason that I treat processes as recommendations instead of rules. At the crossroads, I'd prefer visualizing a blue star or green checkmark projected onto the turn. Like a GPS, I'm totally free to ignore it and force it to recalculate the route. Now it's a fun adventure when I deviate instead of "breaking the rules".

e.g. "You broke the rule! Now something bad will happen!" vs "I wonder what's new since the last time I came this way"

Huge difference.

I think I would avocate actually against processes. Processes are nice, handy, and sage, but that assumes you have unlimited time. A baby crying and death approaching really make you rethinking useless 1-1s and meetings.

Your counter is that death is a better motivator as well as being a desperate parent?

Well, main generational challenge is procrastination with too many unlroductive time sinks available.

I feel like the way you're using 'process' and the way TFA is using it are not the same, which makes this comment orthogonal to the point TFA is trying to make.

> The ‘optimal’ approach would be to check traffic, analyze the data, and shave off five minutes from my journey.

Why not letting Google Maps decide?

Then you are spending a bit of attention on an ongoing basis following the instructions given by the nav. If you're basically driving the same route every time regardless, you'll completely detach from having to pay any attention to it at all, it becomes muscle memory. AKA highway hypnosis.

> Both of these examples demonstrate a process, or a decision made in advance

A decision made in advance is not a process. Unlike all the other real-world examples of committed processes in the article, premade decisions don't require discipline - the actual substitute for motivation - to execute in a meaningful way that ensures actual progress.

it takes discipline for me to stick to decisions I made earlier.

I can make a decision to go to gym tomorrow.

My process/playbook for determining if I go to the gym is I go if I didn’t go the day before.

This is both a premade decision and a process that requires discipline to execute on.

So why isn’t a decision made in advance an example of a simple process?

The useful part of deciding in advance isn't that discipline disappears, it's that you remove one place where you can negotiate with yourself

I think I would use "habit" rather than "process" to describe this. Process perhaps implies a bit more intent and structure, whereas a habit is doing the same thing repeatedly because that's what you do.

I am thinking of AI credit resets, it forced me to finish my project because I already spent subscription so better not waste it!

The cycle was a "process".

It hurts my soul to read of "Agile" as a fixed process consisting of arbitrary decisions like two-week sprints and 9:30 stand-ups.

Agile is "responding to change over following a plan". https://agilemanifesto.org

There's surely something to be said for bundling behaviors and triggers, but I do wish the world of software development hadn't missed the whole damn point of agile.

Still reading but I like how Cat Hicks in Psychology of Software Teams (2027) confronts this dilemma on page 9: "Agile Manifesto said, 'Individuals and interactions over processes and tools.' DevOps made the argument that cohesive processes in software development needed to be invested in... Agile, DevOps, Platform Engineering, or DevEx, every engineering organization I've ever met with is struggling with implementing these ideals in the real world."

Good point, and I do agree with it. I suppose I was specifically talking about the processes that a team uses - I guess"Agile" just rolls off the tongue easier.

I think there's a lot to be said about why this didn't work out like that, using the cognitive load metaphor from the article. People like habits. If you're doing things differently every week you have to justify that among the team, and possibly outside it as well. Whereas (see checklist manifesto), if you turn "Agile" into a series of checkboxes that goes away. Standup? Tick. Done. Discussion of why we're having the standup? God no that's even more tedious.

"Don't think, just do" has been my go-to quote.

A good process deletes decisions (the Glasgow northbound rule) by focusing you on exactly the steps you need to take. A bad one might remove a few but spawn fifty more (suddenly you're debating story points/t-shirt sizes, velocity arguments, Definition of Done, but hey, at least you know it's all scheduled to start at 09:30)

Reply on news.ycombinator.com