8 ms·

> 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

> 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.

nomel 1mo ago
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.
- PyWoody 1mo ago
  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-programming.html https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
  - krapht 1mo ago
    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.
    - nimih 1mo ago
      Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
    - nine_k 1mo ago
      Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run. The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web. The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.
    - groundzeros2015 1mo ago
      Nah. It’s fine.
  - ChrisMarshallNY 1mo ago
    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-noses/ https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
    - asalahli 1mo ago
      This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
- cwnyth 1mo ago
  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 1mo ago
  You misspelled 'beers'. A boring technology.
- bch 1mo ago
  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 1mo ago
    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.
thewakalix 1mo ago
"Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points https://www.lesswrong.com/w/weirdness-points
tshaddox 1mo ago
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 1mo ago
  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 1mo ago
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.
monk_grilla 1mo ago
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.
- williamcotton 1mo ago
  It’s pretty boring at this point.
- sgarland 1mo ago
  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 1mo ago
    10 years ago though
    - mikestorrent 1mo ago
      And here we are, almost all the complaints from a decade ago still have relevance
    - Cthulhu_ 1mo ago
      Some wounds never heal. Like Angular 1->2.
  - samtheprogram 1mo ago
    That's an insane take. Anything?!?
    - anon48293 1mo ago
      Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?
Cthulhu_ 1mo ago
I think a core problem is that people read online and spend a weekend looking into something cool and get a pretty decent POC up and running. But that's a single person in a weekend, nowadays accellerated by LLMs - what they cannot see (or, something that comes with experience) is how expensive or invasive it would be to apply that in your team or company-wide. But innovation tokens is a neat idea, it's not personal - no big bad grumpy old senior being a square about CoolTech2026 - and it's an incentive to have someone that wants to do something cool think about it. The other one in that regard are ADRs, which I think is a very low barrier to entry path into architecture that most developers can do. It too forces the person to consider CoolTech2026 in a wider context - what does it solve, what is used right now to solve it, what other solutions are out there, etc - plus making it a team decision if executed right.

nomel 1mo ago

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.

PyWoody 1mo ago
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-programming.html https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
- krapht 1mo ago
  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.
  - nimih 1mo ago
    Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
  - nine_k 1mo ago
    Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run. The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web. The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.
  - groundzeros2015 1mo ago
    Nah. It’s fine.
- ChrisMarshallNY 1mo ago
  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-noses/ https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
  - asalahli 1mo ago
    This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
cwnyth 1mo ago
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 1mo ago
You misspelled 'beers'. A boring technology.
bch 1mo ago
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 1mo ago
  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.

thewakalix 1mo ago

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

tshaddox 1mo ago

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 1mo ago
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 1mo ago

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.

monk_grilla 1mo ago

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.

williamcotton 1mo ago
It’s pretty boring at this point.
sgarland 1mo ago
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 1mo ago
  10 years ago though
  - mikestorrent 1mo ago
    And here we are, almost all the complaints from a decade ago still have relevance
  - Cthulhu_ 1mo ago
    Some wounds never heal. Like Angular 1->2.
- samtheprogram 1mo ago
  That's an insane take. Anything?!?
  - anon48293 1mo ago
    Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?

Cthulhu_ 1mo ago

I think a core problem is that people read online and spend a weekend looking into something cool and get a pretty decent POC up and running. But that's a single person in a weekend, nowadays accellerated by LLMs - what they cannot see (or, something that comes with experience) is how expensive or invasive it would be to apply that in your team or company-wide. But innovation tokens is a neat idea, it's not personal - no big bad grumpy old senior being a square about CoolTech2026 - and it's an incentive to have someone that wants to do something cool think about it. The other one in that regard are ADRs, which I think is a very low barrier to entry path into architecture that most developers can do. It too forces the person to consider CoolTech2026 in a wider context - what does it solve, what is used right now to solve it, what other solutions are out there, etc - plus making it a team decision if executed right.