101–110 of 269 posts
> 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…
Well, I've not tried to publish this on HN so far, but I guess given such a counterpoint, I should at least attempt to share: https://www.iankduncan.com/engineering/2026-08-07-getting-fr...
I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…
Earlier quoted context omitted.
I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in. That is, if someone said two sentences, I would only care about the second one: 1. "We should use this because it is boring" 2. "We should use th…
Isn't this somewhat semantical? Boring implies a lot of the things you said, especially if it means your team's experience is largely pooled in a particular dev environment. Assuming most boring tech is ubiquitous, it's probably rare that your team, statistically, is deeply literate in some obscure tech - they most likely are experts in some definition of "boring". TLDR; #1 and #2 are essentially implying the same th…
I love this post. It’s also interesting to revisit in the age of agents. Using the language of the article, I’d say “push all your innovation tokens into agents” is probably a good move. This means the tech your agents work with should all be boring tech. Another way of saying this is “use in-distribution technology”. If agents are substantially better at Rust than Zig, probably you should use Rust, even if Zig is “b…
Earlier quoted context omitted.
Isn't this somewhat semantical? Boring implies a lot of the things you said, especially if it means your team's experience is largely pooled in a particular dev environment. Assuming most boring tech is ubiquitous, it's probably rare that your team, statistically, is deeply literate in some obscure tech - they most likely are experts in some definition of "boring". TLDR; #1 and #2 are essentially implying the same th…
insanitybit's point is that "boring" can imply those things, but it can imply other things too. If you have to bring the correct context to make the word make sense, and there's other contexts that could apply that don't make sense, the word isn't helping. You bringing the correct context is doing the heavy lifting.
Well, I've not tried to publish this on HN so far, but I guess given such a counterpoint, I should at least attempt to share: https://www.iankduncan.com/engineering/2026-08-07-getting-fr...
I'm reminded of my father in law, who when asked what superpower he'd want, it was flight, so he could get to work without waiting in traffic. If all of your employees are AI's, clarity of vision trumps choosing boring. And if you're having boring visions... well the world is already full of competition for you, so good luck I guess.
That is tragically sad.
I love this post. It’s also interesting to revisit in the age of agents. Using the language of the article, I’d say “push all your innovation tokens into agents” is probably a good move. This means the tech your agents work with should all be boring tech. Another way of saying this is “use in-distribution technology”. If agents are substantially better at Rust than Zig, probably you should use Rust, even if Zig is “b…
Even if in the other approach, the LLM knows the stack better, you're just going to push the complexity into your client code, so it's not like it's a huge gain to use boring tech stack.
Earlier quoted context omitted.
I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn'…
CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how…
It doesn't though. It's very easy to manufacture reasons why "shiny new thing" is the objectively right fit for something, even when it's not.
The word "boring" is well-chosen because it's addressing a bias most engineers have towards the interesting and new. It's a reminder: that fun new tech you really want to try here may not be, probably isn't, the cold-hearted best choice, if you're being practical and business-minded.