21–30 of 269 posts
The problem with this is that the list of tech that gets boring changes all time, faster than people's opinions. Kubernetes is very boring tech, but if you go through the old discussion threads on this (even from the last year or two), Kubernetes is still cited as some brand new wizbang thing you shouldn't spend tokens on.
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…
One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client. And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but the…
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…
So yes, pick boring tech, defined as the tech you know the sharp edges of.
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…
This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse. So yes, pick boring tech, defined as the tech you know the sharp edges of.
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 this because we understand the sharp edges"
I wouldn't care at all about (1) and I'd have a real conversation based on (2).
Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
now 11y later i wonder if 'node.js' still needs an innovation token or not
Do you mean alternatives, like Bun and Deno, or a future direction for itself? edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.
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…
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…
"boring" means familiar. It should have more known unknowns than unknown unknowns.
Earlier quoted context omitted.
One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client. And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but the…
The willingness to reshape society for the benefit of AI rather than shaping AI around humanity paints a very dire picture of the coming decade.
PHP (lets use this as an example) brings already many benefits over a common solution like a TypeScript monorepo mostly operational simplicity. That was already true before AI.
It's boring, very fast and easy to deploy, offers straightforward horizontal scaling, no need to orchestrate containers and/or multiple runtime processes, has excellent html rendering (nothing in JS-land really does), and has very solid framework solutions like Laravel where everything works out of the box.
Those merits existed before AI already.
The issue was that you had to buy into PHP as a language, which was a horrible experience.
But if AI writes most of the code? Suddenly PHP becomes an excellent candidate to choose for many use cases.
If anything, AI makes the choice of programming and languages and software about finding the right tool for the job. Somehow the industry instead keeps vomiting React/Tailwind slop which are the right tool for 1% of the jobs.
I hope to have cleared the concept.
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…
> What if you know NodeJS really well?
Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.
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…
> I'm a bit tired of "simple" and "boring" and other nonsense words in this field...
This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time.
People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"