> 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.
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.
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.
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...
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.
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.
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).
Nah. It’s fine.
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...
This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
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.
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.
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.
You misspelled 'beers'. A boring technology.
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.
I think that in 2026 Node is a boring technology, but with the fast-moving ecosystem around it if you opt into npm (the registry, not the package manager) it makes it not boring.
The things you layer on top of Node via npm could count as "not-boring" in this instance, especially with the number of supply-chain attacks each month.
Yeah, compared to most other languages there's a lot of moving parts and activity in the space still - npm vs pnpm vs yarn, node vs bun vs deno, eslint / prettier vs biome vs oxlint, and that's before even writing a single line of code.
Boring in comparison would be Go where a lot of things are standardized. You still get some non-boring in choosing what libraries to use (if applicable) but generally it's a very dull language/ecosystem.
I think the main problem is just that we don't have a standard library across the browser and server. We have to reinvent everything across both domains because we don't have good building blocks unlike Go which, despite my issues with some the standard library, at least has one.
I'm disappointed that we've fragmented across Node/Deno/Bun, although I was briefly hopeful for Deno since they tried to standardise around ESM and provide a strong standard library. Of course this still had to be bundled for the browser, which has its own issues.
Surprisingly I'd still consider this blog post relatively accurate on what it calls boring vs. non-boring.
I would say depends what you're trying to do?
Is NodeJS the simple, solid and rugged way this has been done for a decade now? If not, then it is an innovation.
Second it depends on what your or your teams experience level is.
Have you ever built a serious thing with it and do you have multiple years of experience running and maintaining it? Yes? Then it is probably the boring choice.
Would you be okay with leaving the final product unmaintained for a few years and it would not be a major problem? That may be a factor as well. E.g. a static HTML website needs next to zero maintenance, while a wordpress blog may fall apart every once in a while.
How maintainable would it be if the person who built it leaves? Could someone else pick up the slack right away? Would they need some time to get up to speed? Would it be literally impossible to get up to speed?
How hard is it to get the build system setup if the devs laptop is crushed under a truck? Is it as simple as cloning the project or does it need ritual sacrifice and dark chants and incantations to even get near running?
The boring thing is one that scores all the easy points on these questions.
> Second it depends on what your or your teams experience level is.
+1.
I work in a Skunkworks department inside a larger/older company and we recently decided to stop using Python in the future, the company's language.
Node.js, Go, Rust, C#, etc, all of those are extremely boring for us. They're stable and we get things done in minutes. In Python it's like pulling teeth, with constant API changes and refactors from other teams we're struggling to keep up with. Which one is boring? For us, not Python.
The Python developers naturally disagree and say "there must be something wrong with your team if you can't use Python at the same speed and efficacy as us".
Python is fast for tiny programs. However if you have more than one team it isn't tiny. One developer can make something not tiny in a few weeks. For large programs a compiler that checks syntax, and ideally types before you run a comprehensive test suite ( which probably isn't comprehensive enough) is nearly mandatory to be maintainable. Otherwise you can never be sure you adjusted everything when you need to change an API.
I think a good metric for "boring" technology, at least for languages/frameworks, is how painful the process of updating an abandoned/unmaintained project after 9-12 months is. NodeJS itself qualifies as boring, but the entire ecosystem around it is still a mess.
Yes, Node is boring. Its capabilities and failure modes are well understood. And no, installing today's flavour of leftpad is entirely self inflicted. Bun or Deno are definitely a token or two I'd rather spend elsewhere or not at all.
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.
10 years since the original and it feels like one of the go-to de-facto standard technology choices in many organizations. So I suppose it doesn't cost an innovation token anymore, but that doesn't mean you should just use it - there are many factors to consider when picking a technology.
It is more about being a dynamic language where V8 can only help as much, thus C++ addons, rewrites into .NET, Java, Go, Rust, and the whole npm system made of packages with single functions written by folks that just did their first package out of a bootcamp.
If it was for me, JavaScript would stay in the browser.
> Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed?
Probably not in 2026, but it 2015 it was pretty new and shiny.
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.
10 years ago though
And here we are, almost all the complaints from a decade ago still have relevance
Some wounds never heal. Like Angular 1->2.
That's an insane take. Anything?!?
Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?
Express, Lodash, jQuery, require still works, the language itself.
Lots of CSS stuff are still virtually the same, as it only gets additions.
Vue.js API from 10 years ago still works fine in newer versions.
React class components still work. Even Hooks themselves are pushing 7-8 years now.
Express
Can you name a major Java framework or library (that's not abandonware)?
It’s pretty boring at this point.
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."
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.
"Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points
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.