Boredom is not a problem to be solved, it's the privilege of a free mind

Each day at work I put in headphones, code for a bit, read HN for a bit, then back to code. I don't know if I could describe it as boredom, maybe confused context switching.

It brings to mind how the protagonist of Neuromancer gets hooked on amphetamines after being surgically banned from the Internet. We get so used to everything happening quickly and efficiently that our brains don't have time to rest. If you're not doing something, then what's wrong with you, the modern world seems to say.

We were led to believe technology would eventually alleviate us of our ills. Instead I feel...tired.

so if it is the last privilege of a free mind this means what - that the other privilegs have been taken from the free mind, boredom is the last privilege that remains to a free mind. hmm. I think word choice was not adequately considered here.

This. I don't regret the time I spend just thinking. I do however regret the time lost to boredom. They're not the same thing. Boredom to me is a state of wanting to do something but either not being able to or not knowing what that something is.

I love playing with and working on projects that transform code into different code and I love that you're drawn to meta-programming, but I have a few issues with a few of the ideas:

> If it's boring, then something is done wrong.

I have a problem with the tone of this statement, because I've seen it taken to an extreme and it can be a dangerous idea.

A better way of looking at it is: If something is boring, take it as a sign there might be an opportunity to improve the process, but you have to be acutely aware the problems that automation can introduce.

There's a phenomenon I like to call premature automation. When you work on a problem the boring way long enough, your brain learns the patterns. Premature automation happens when you skip learning about or experiencing the process and you shoot straight to automation. Often what happens is the automation fails to anticipate important edge cases.

> You can always automate the boring parts, and thinking about automation is less boring.

Thinking about automation is less boring because it's not trivial. Automation can be trivial if you're doing simple things like code generation, but often these simple things come at a cost. For example, code generation typically becomes more complex as the need for customizations and exceptions popup.

Libraries can automate things at runtime, but writing good libraries based on timeless/minimally leaky ideas takes time. Leaky libraries built on a poor foundation tends to introduce bugs or complexity. There is value in boring, predictable code with minimal dependencies. It's easier to audit and review with static analysis tools, it's harder to introduce cascading bugs and it.

TLDR: I'm all for automation, but saying "If it's boring, something is done wrong" and "you can always automate the boring parts" sounds like a cocktail of developer shaming for not doing something that's "simple".

Someone told you being bored was bad, so you were never bored?! How does that work?