> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while.

This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining those tradeoffs to colleague of all levels. Highly recommend.

▲

monk_grilla an hour ago | parent | next [-]

I also broadly agree with the post.

> If you choose to write your website in NodeJS, you just spent one of your innovation tokens.

Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.

▲

selcuka 12 minutes ago | parent | next [-]

NodeJS is just an example that must have seemed reasonable to the author at the time this blog post was written (11 years ago). Obviously it may no longer apply.

Also the definitions of "unknown" and "boring" are always up to you. If you have a bunch of experienced `bun` developers in your company you may consider it as the boring tech.

▲

sgarland 28 minutes ago | parent | prev | next [-]

I think calling anything in the JavaScript ecosystem “mature” is a bit of a stretch. This is the same community that brought us left-pad.

	▲	lkirkwood 20 minutes ago \| parent \| next [-]
		10 years ago though
	▲	samtheprogram 12 minutes ago \| parent \| prev [-]
		That's an insane take. Anything?!?

▲

williamcotton 31 minutes ago | parent | prev [-]

It’s pretty boring at this point.

▲

nomel 7 hours ago | parent | prev | next [-]

There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them.

Maybe it wasn't beans? But, I've been looking for it for years.

▲

bch 3 hours ago | parent | next [-]

I’m vaguely recalling something - and I think the beans might’ve also represented vetos, so one had a limited number of objections to other people’s ideas… quick search revealing nothing so far, though.

	▲	nomel 2 hours ago \| parent [-]
		Sounds familiar! I believe it was a simple html page hosted on some university user page. I've tried over the years, but can never find it. All the search engines moving to vector search makes finding something like this near impossible.

▲

PyWoody 7 hours ago | parent | prev | next [-]

Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0]

[0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...

	▲	krapht 6 hours ago \| parent \| next [-]
		His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.
	▲	ChrisMarshallNY 5 hours ago \| parent \| prev [-]
		Speaking of beans, here's a classic (totally different from the main topic. Welcome to Topic Creep): https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...

▲

cwnyth 7 hours ago | parent | prev | next [-]

This is where efficiency can be applied in two distinct ways. On the one hand, if using more beans means you can solve the problem more quickly, then it is more efficient to the problem solver to do so.

But if beans are scarce, and that's where you can try to find ways to use less beans per function, then the goal is to make the function more efficient by using less beans.

▲

contingencies 5 hours ago | parent | prev [-]

You misspelled 'beers'. A boring technology.

▲

tshaddox 2 hours ago | parent | prev | next [-]

I like the general concept, but I think framing it as a small number of discrete tokens isn't quite right. I'd treat the whole thing in terms of debt and risk. Using "non-boring" technology [0] is really just subtracting some amount from your balance. You don't want your balance to go too negative, but carrying some debt is sometimes fine. And some risky bets might turn out to have a huge ROI!

The amounts clearly aren't discrete. Writing your entire app on a new language runtime might be very risky (and also might have large potential ROI!), but choosing a new email provider might not be (random example, but presuming that you can swap out providers fairly easily).

[0] My bigger complaint is really about the vagueness of even deciding what is "boring." How does a new technology transition from being "non-boring" to being "boring"? Apparently that requires a lot of people to ignore this article's advice for a long time, until we collectively decide that those people have had good enough results to consider that technology "boring."

	▲	sgarland 16 minutes ago \| parent [-]
		From TFA: “The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.” Boring technology is that where you have an extremely small amount of “I didn’t think that was possible” events occurring. As it states, there’s always some; SQLite’s recent WAL-Reset bug that Tailscale discovered is a perfect example of that. Actually, on the subject of databases, I think they all break that rule. I’m a DBRE, and can readily state there are an insane number of footguns with all of them. It’s just that, relative to other options, they’re as good as you’re going to get. Also in their defense, nearly every footgun I’ve ever encountered was documented, it’s just that the docs are incredibly dense, and sometimes a bit vague.

▲

eudamoniac an hour ago | parent | prev | next [-]

I think the same way about any personal project. You can either make something unfamiliar, or make it with unfamiliar technology stack, but you shouldn't do both.

▲

thewakalix 4 hours ago | parent | prev [-]

"Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points