The author of "Choose boring technology" regretted the choice of the word "boring" [1].

Anyway, boring is bad. Boring is what spends your attention on irrelevant things. Cobol's syntax is boring in a bad way. Go's error handling is boring in a bad way. Manually clicking through screens again and again because you failed to write UI tests is boring in a bad way.

What could be "boring in a good way" is something that gets things done and gets out of your way. Things like HTTPS, or S3, or your keyboard once you have leaned touch typing, are "boring in a good way". They have no concealed surprises, are well-tested in practice, and do what they say on the tin, every time.

New and shiny things can be "boring in the good way", e.g. uv [2]. Old and established things can be full of (nasty) surprises, and, in this regard, the opposite of boring, e.g. C++.

[1]: https://boringtechnology.club/#30

[2]: https://github.com/astral-sh/uv

What you describe is the difference between tedious and simple.

Boring is good. I don't want to be excited by technology, i want to be bored in the sense that it's simple and out of my way.

Same for KISS. I tend to tell people to not only keep things simple, but boring even. Some new code i need to read and fix or extend? I want to be bored. Bored means it's obvious and simple.

The difference? There are many complex libraries. By definition they are not simple technology.

For example a crypto library. Probably one of the most complex tasks. I would consider it a good library if it's boring to use/extend/read.

> The author of "Choose boring technology" regretted the choice of the word "boring"

Well, yes, but only in the sense that people kept giving him beef about how boring is a bad word in their mind, not because it was a bad word for this context per se. Which is somewhat ironic given your comment!

I suppose what you're getting at is the difference between boring, and "boooooriiiiiing".

Why conflate boring with old? "Boring" in this context means: proven and stable. Yes, that would take some time to become apparent, but the converse is not necessarily the case: a tech does not become "boring" in a good way simply because it is old.

All this was my understanding before, so not sure why you think "boring" was meant to be equivalent to "old"

What you just described fits my definition of boring, which is some function of (time passed, individual at keyboard)

Cobol was (and for some, still is) exciting at first, but _becomes_ boring once you master it, and the ecosystem evolves to fix or work around its shortcomings. Believe it or not, even UX/UI testers can deal with and find happiness in clicking through UIs for the tenth thousand time (sure, last time I saw such Tester, was at around 2010).

This doesn't mean the technology itself becomes bad or stays good. It just means the understanding (and usage patterns) solidifies, so it becomes less exciting, hence: "boring".

But you can't sell a book with the title "Choose well-established technology". Because people would be like, no sht, Sherlock, I don't need a book to know that.

> Go's error handling is boring in a bad way. Manually clicking through screens again and again because you failed to write UI tests is boring in a bad way.

Go's error handling is useful if your system needs to be correct more than it needs to be available, and you should be manually clicking through screens even if you wrote UI tests.

Looking at why something is boring and who it's boring for can be helpful, especially in a team setting. It's entirely possible to automate away a bottleneck that exists for a good reason while sitting across from someone who'd love to handle the issue correctly.

between HTTP/1.1 to HTTP/2+ interoperability issues, HTTP/2+ configuration, TLS configuration, HTTPS is hardly boring and does what it says on the tin every time.