> 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.
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.
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"
> 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.
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 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.
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.
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.
> ... 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"
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.
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.
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."
> 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.
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 think the strongest version of this idea is that process is basically a way of spending willpower once instead of repeatedly
> 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.
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 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?
it takes discipline for me to stick to decisions I made earlier.
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 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.
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.
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.
"Don't think, just do" has been my go-to quote.
> 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.
> ... 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.
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.
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.
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."