The DOIT philosophy: How I'm avoiding Decision Fatigue and the Paralysis of Choice this year

My mantra for this year is DOIT and it stands for

• DO

• Overcome

• Iterate

• Triumph

I have a lot of projects that are in various states of completion, and I want to get them over the finish line. I just need to DOIT. In service of this, another goal of mine in 2024 is simplicity. By focusing on simplicity I will be able to more effectively achieve my project goals. Einstein's famous quote is applicable here

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience

Amusingly, the more familiar version of this quote is actually a simplified version of the former. It illustrates the point well...

Everything should be made as simple as possible, but no simpler

The key is the 2nd part of the quote "but no simpler". Complexity is the bane of Programmers, and I've been making my life more complicated than it needs to be recently. Sure, there are things that are complex just by their very nature, and just like how I wouldn't fear 1 duck, but 100,000 would give me pause, a 100,000 line code base would still be challenging to work with no matter what the language. But at least languages that value simplicity leave more space in your brain for the actual code part, so you don't end up looking like this

Or as Andrew Kelly puts it with Zig

Focus on debugging your application rather than debugging your programming language knowledge.

Ultimately what we are trying to do as Programmers is create things, and complexity gets in the way of that. But the complexity which has inhibited my ability to complete projects doesn't just stop at what programming languages I am using, there are other things that cause this complexity, and they result in two things. Decision fatigue and the Paralysis of Choice. Since these are so similar, let's get a baseline for how they are defined

• Decision Fatigue: The deteriorating quality of decisions made by an individual after a long session of decision making. Essentially, the more decisions you make, the more your ability to make further decisions diminishes. This is because making decisions is cognitively taxing, and over time, the mental resources needed to weigh choices, foresee outcomes, and make judgments become depleted. As a result, an individual might resort to simpler decision-making strategies, exhibit reduced self control, or even avoid making decisions altogether as they become fatigued.

• Paralysis of Choice: When an individual is faced with too many options and finds it difficult to make a decision. Instead of making a choice, the person becomes overwhelmed by the options available and may feel anxious or unable to choose at all. The paralysis of choice suggests that having too many options can lead to less satisfaction with the eventual choice made, due to the stress of the selection process and the potential for regret over the alternatives not chosen.

How it affects people

The important thing to note about the two definitions above is that it doesn't say anything about a specific scenario where this happens. From the time you get up to the time you go to bed, the act of decision making, and the number of choices presented cause the problems. It doesn't matter whether the decisions you are making are about lunch, or what Steam game to play, they all negatively affect your downstream decision making abilities. This is why successful people employ the trick of wearing the same close to reduce the amount of choices they have to make. But while this is definitely not a live like a "billionaire" grindset sort of article, the principles are sound. CEOs simplify their lives so they can make big decisions that steer the direction of companies and billions of dollars in capital. But I can do the same thing to be more successful in achieving more modest goals.

How it affects me

To this end I've been simplifying many aspects of my life. One way I've done this is cutting down to one large monitor. This might seem controversial as the productivity gain from two is almost double a single monitor. But a second monitor also invites temptation. It's easy to put things on that 2nd screen that are just for entertainment and don't serve the current task at hand. Furthermore, I find the little snags that come with a 2nd monitor interrupt my flow while working. For example

1. Windows opening on the wrong screen

2. Windows opening between two screens

3. Resolution issues when both monitors are not the same size

4. Deciding which monitor a window should be on

The point is not that these things can't be fixed, it's that they require three things of mine that are in limited supply. My concentration, my decision making energy, and my will power to not watch YouTube videos. I would rather alt tab to another window when I really need it, or split my window in two if I need to read documentation. Plus with one monitor I don't have to worry about one screen being in a suboptimal position. And as eye strain becomes more of an issue, this is important for me. I'm not the only one who feels this way too, and while my back would never let me program from a couch, I agree with a lot of the things Theo says in this video.

Another way I am simplifying my life is to stick to one operating system. I would switch distributions multiple times a year, as the sheen of the new one faded. This required me to spend the better part of the day just setting up everything again, and then another month running into little things I had forgotten to. This year I'm forcing myself to stick with Pop!_OS as my main desktop's operating system. Pop!_OS is good, so this isn't the hardest decision, but speaking it into existence as opposed to privately muttering it to my self provides some accountability.

I'm also cutting down on the number of programming languages I will start new projects in. I've been hopping programming languages like I hop distributions, and while I've appreciated the breadth of experience this has given me, I find that it has caused me to have very shallow experience in a lot of languages that aren't Python. Furthermore, a lot of projects start with me just digging into what programming language I'm going to use, what libraries are available for the task, and how to make my code more idiomatic. I end up trying to Goldilocks myself into the right programming language for the project, and that never works. This paralysis of choice also has a subtle but deadly side effect that I have been feeling more frequently too. Let's revisit part of the definition

leading to less satisfaction with the eventual choice made, due to the stress of the selection process and the potential for regret over the alternatives not chosen.

Less satisfaction and regret, two things I don't need more of in my life. Along these same lines I will reduce the number of categories these projects fall under. From GUI to Games, Programming Language Theory to Machine Learning, and Art to Level Design, I've doing a lot of things that cover a lot of different topics. They are all interesting, and I wish I could spend every waking moment hopping between them, but I will never reach the level of proficiency I desire if I spread myself so thin.

Finally as programmers there are tons of decisions we have to make related to...

1. Programming languages

2. Frameworks

3. Windows vs Mac vs Linux

4. Mechanical Keyboard Switches

5. frameworks

6. Wall Paper Color

7. Text Editor Font

8. Text Editor

9. ECS, Functional, OOP

10. Web, Mobile Desktop

Before we've even written a single line of code. It's no wonder so many of us want to start a farm instead. But I'm saying let's not throw the baby out with the bath water. Maybe I can pare things down a bit and focus on actually putting code to text editor. This was a lot easier back in the 80s when the options were Basic, Assembly, or Pascal (and let's be real, just Assembly when you were writing something serious). But in the context of today, if I don't pick the perfect stack for my project, who cares, just deal with it. My programming ancestors did more with less. Now I'm not saying to scale your product to millions of users using just Google Sheets, but it's hard to go wrong with a mainstream language today.

Of course, I will still learn new things for my job, and I will still write about the interesting things I do here. But I will cut back in places where I can. As it currently stands I have over a years worth of drafts saved up, so even if I just draw inspiration from my drafts it will cover me well into 2025. But, as the year is not even close to over, I suspect I'll come across more little nuggets that will spark ideas for new articles regardless.

Maybe some of you also struggle with this problem, and there are ways you can simplify your lives to make shipping easier too. I hope we all simplify our stacks this year, so that we can DOIT and be proud of what we created.

Call To Action 📣

Hi 👋 my name is Diego Crespo and I like to talk about technology, niche programming languages, and AI. I have a Twitter and a Mastodon, if you’d like to follow me on other social media platforms. If you liked the article, consider liking and subscribing. And if you haven’t why not check out another article of mine listed below! Thank you for reading and giving me a little of your valuable time. A.M.D.G