The curse of knowing how, or; fixing everything

> But programming lures us into believing we can control the outside events. That is where the suffering begins.

Isn't it the opposite? We're not surprised if someone who grew up amidst criminals also does crime. I'm not sure that I can choose whether to feel attracted to men instead of women. I can't control my mind, but I can choose what people to stay with and what media to be exposed to. I can adjust everything except for my mind: my hands write code, my feet take me elsewhere, I can tune into different media, I can choose to not speak agitatedly when a service rep. is following corporate policy, etc., whereas my mind moulds or reacts in response to those inputs (I'll still feel irritated by that corporate policy and be influenced by advertising)

If anything, I could see an argument for that you control neither, because obviously your control of your hands is coming from a combination of your mind's outputs and the physical laws of our environment

As someone who is very much on the optimizer side of things, and experiences the struggles described in this article, the lesson I take to heart is that while satisficers tend to be happier, optimizers get more done.

Your optimizer tendencies make you into an expert, they open up new opportunities for learning and growth, they have the potential to have real consequence in the world. Be thankful for them, even as you guide them to their appropriate application.

I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not.

You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what you want.

Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.

However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.

I've watched users use software that temporarily disables input like this and what you see is that they either get trained to learn the input delay and time their tap as tightly as possible, or they just get annoying and hammer inputs until it gets processed.

And, in practice, it turns out these latter times where a user is interacting with a familiar UI are 100x more common than when they misclick on an unfamiliar UI. So while the latter case is super annoying, it's a better experience in aggregate if the app is as responsive as it can be, as quickly as it can be.

Perhaps there is a third way where an app makes a distinction between flows to static context versus dynamically generated content and only puts an input block in for the latter, but I expect the line between "static" and "dynamic" is too fuzzy. People certainly learn to rely on familiar auto-complete suggestions.

UI is hard. A box of silicon to a great ape is not an easy connection to engineer.