Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
- Over 12 years of popular usage at this point. I still think it's inappropriate for ~90% of the companies using it.by leetrout
- Golang was supposed to be boring by design (https://go.dev/talks/2012/splash.article) and you can use it in a boring way. Even learning golang is relatively boring.by red_admiral
- Go the language and Go the ecosystem seem to be the antithesis of languages like Scala that seems to be a form of self-gratification when used to solve boring problems like HTTP APIs, or ecosystems like Javascript's where all the tools are rewritten into something faster and better in recent years.by Cthulhu_
- Software that works year-after-year has never been a commodity. It's boring on the surface. It doesn't get the flashy posts. But I'll choose reliable over new in almost all cases.by euthymiclabs
- This is why it took me so long before giving Go a try, even though on paper it sounds exactly what I want from a language.
I'm glad I finally did, I've been enjoying it.
by jay_kyburz - Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.by conrs
- Yeah, it's pretty unpopular among people who like to try out new technology on every given project.
I've found it extremely useful over the years, personally.
by simonw - It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.by andai
- I wish there was a jobs board for companies that are somehow vetted for this type of engineering culture.
So many jobs are sold as “we’re pragmatist's” and when you show up there’s 5 devs, 50 repos and most of the work is discussing if x requirement should be a new micro service. The product is usually an web app with 10 entities and and an API.
Suppose it’s keeping people in jobs
by cliche - There is, it's java/ruby shops. No one wants to use that stuff in current year, so if they're using it anyway, they're pretty likely to be boring tech users.by eudamoniac
- 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...by iand675
- 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.
- Feels like some good points but the llm writing makes it feel less trustworthy
- This advice holds up, but there are caveats to keep in mind. Two off the top of my head:
1. I once worked for a company that had a large Cassandra cluster that was primarily serving the role of a distributed append-only log. This role is as perfect a fit for Cassandra as I can imagine. When we needed a distributed database for authentication, we decided to use Cassandra for it since we had in-house expertise (it was "boring technology") and a cluster we could piggy-back on for a while. When we needed a distributed database for a key-value service, we used the same reasoning and chose Cassandra again. There were many problems with Cassandra that I won't go into, but I will say that straying too far from Cassandra's comfort zone stretched it to a breaking point. And we had some downtime and rough nights because of it. Sometimes boring technology isn't enough, you also need boring workloads for it.
2. I was an early adopter for Rust. Before 1.0, it wasn't clear to most people whether the language would mount to anything. To me, I saw a formal proof assistant being put into programmer's hands and could tell right away it had a bright future. Rust was not a boring technology back then. You might say it is now (for some use cases). Adopting shiny new technologies that measurably improve confidence is not a risk. What's foolish is getting comfortable and complacent with familiar, aka boring, technologies that are difficult to use correctly.
by jason_oster - 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 “better”. The amount that Zig is better is going to get swamped by the amount that in-distribution agents are better.
(This is not a claim that Rust actually is better, just a hypothetical fact pattern for discussion.)
by theptip - I find agents default to popular which heavily overlaps with boring although you could steer them more boring for sure.by hahahaa
- > I’d say “push all your innovation tokens into agents” is probably a good move
Or better yet, just don't use agents, deliver something better with all the stability and boringness that you have. There's never been a better time than now to produce software that actually seems to work and march along steadily; your competitors are all flailing wildly like morons.
by 59nadir - I admit I have a hard time following this logic. If an agent has a baseline intelligence, you can... instead of using boring technology, just DIY/NIH the simplest custom solution which fulfills your requirements. And you'll usually do a better job than a general-purpose software library.
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.
by Pannoniae - 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 they are extremely solid choices to move fast, well, and get excellent performance and tooling out of the box.
by epolanski - It's a total tangent but AI being so good at developing rust means that my first impression of seeing a rust project has totally changed.
4 or 5 years ago if I had to weigh up two options and one was written in rust it was almost a sure thing that the program was snappy, fast, reliable and that the author was competant.
Now it's a sure fire sign that the project was probably vibe coded. Not saying it can't still be good, I just have a different first impression now
by dwedge - Some of this may have been a reaction to the era of Javascript framework churn. There were way too many different technologies for doing roughly the same job. They all more or less worked.
On the other hand, IBM was late getting into integrated circuits. They had Solid Logic Technology, automated machinery for putting transistors into ceramic substrates to make tiny but discrete circuits. That's what powered the IBM System/360. Worked, but kept mainframe prices high and made IBM late to minicomputers.
Innovation when the problem is hard is more interesting. Look at the history of US long range bombers. The B-29 was effective, but underpowered, and had a lot of trouble getting off the ground fully loaded. So, after WWII, the next development was the B-36, which answered the question "what if we scaled up the B-29?"[1] Six propellers, and four jet engines (added late in the design cycle). Was a sky barge, but it worked, as long as no one was trying hard to shoot it down. No flyable aircraft remain. That was the boring technology approach.
After that came the B-47, which answered the question "what if we scaled up a jet fighter to bomber size?"[2] The B-47 was all jets, no props. It needed solid-fuel rocket boosters (!) to help it get off the ground, and a drag chute to slow it down on landing. It was terrible to fly; its operating speed and altitude were too near the "coffin corner" where stall and Mach buffet meet.[3] No flyable aircraft remain.
Then came the B-52. New engines. New airframe. New design. [4] That's the high-risk approach. It worked. Hundreds are still in active service. Outlasted most of its successors, the B-58 Hustler (a supersonic intercontinental bomber), the B-70, the F-111, etc.
On the commercial side, we have Boeing, whose most successful airliner is a variant of the B-737, which first flew in 1967. But that's another story.
[1] https://www.youtube.com/watch?v=vKQYG_fA2uM
[2] https://www.youtube.com/watch?v=l1-urTRxeEM
[3] https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%...
by Animats - I think there's the problem of pretending to be something that one is not - when people have always tried to associate themselves and the things they did with the cool 'in-group' of genuinely inspiring people, to the point where the fakery was in your face - think of companies meaninglessly cramming 'AI' or 'crypto' into their products.
The example I used is incredibly clear-cut, and is the subject of ridicule, but when the boundaries blurrier, people have managed to get away with this sleight of hand.
The point I want to make: the technologist who designs next-gen semiconductor processes or planes that fly faster and further, is categorically, qualitatively different from the one who writes code for ecommerce websites.
No points for guessing which group has lobbied successfully for erasing this distinction.
This is a civilizational issue. Despite allegedly a group of technocrats being charge of society, who do everything in the name of progress, there has been very little progress outside the field of AI during the past decade.
And this was true even a decade ago - this article argues against progress in software engineering - saying all new stuff is useless, and for the record they turned out to be mostly right, all new stuff did turn out to be meh. Curiously, it names node as one of the hot new things of his era - though it's exactly the opposite, node succeeded, because it managed to transplant the validated engineering and mindshare of js devs to the backend and other domains, so even when new, it chose the niche of 'boring' tech.
by torginus - IBM briefly pulled ahead with the PC though, mainly by routing around their own bureaucracy. That was a hard innovation problem, especially without a crystal ball.by red_admiral
- 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 think "New" means untested, but is that true? What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I should just say "Choose well tested" instead of "Choose old" - lots of old software is very poorly tested.
Maybe I think that "Old" implies better documentation, but does it? Lots of older projects have insane cruft and weird edge cases that are undocumented and accumulated over years.
Why do we need a metaphor? Why is "innovation token" helpful?
If you're incapable of evaluating a technology in terms of these properties, you aren't a serious developer and "boring" will not save you.
Sit down, write our your requirements, determine candidate solutions, and choose them based on their fit. "Boring" means nothing, it's a vague proxy term. "Well tsted", "performant for our use case", "developers know it", etc mean something.
> MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
Literally every one of these has caused hilarious and disastrous failures for me in my career. But yep, boring.
> If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens.
What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?
I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.
by insanitybit - You are confusing software with technology. Choose boring technology, not choose old software.by frrlpp
- > For example, I may think "New" means untested, but is that true?
The article answers this, and the answer is "no". New technology is one you don't know the details of.
> determine candidate solutions, and choose them based on their fit
That's quite hard to do for solutions that you don't know the details.
You have an objection to something. It's clearly not to the article's point, though.
by marcosdumay - > I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens"
It’s a cute way of saying that you can only do 2-3 new things.
The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool.
If you’ve ever had to estimate your stories/tickets/etc in “story points” or “T-shirt sizes” then “innovation tokens” is roughly the same.
If you haven’t had to do that, you’ve lived a charmed life.
> Engineers should understand requirements, risks, tradeoffs, and potential gains.
Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk.
Hell, I’ve been that engineer in my misspent youth. The post resonates with many of us because it describes hard-won wisdom of our mistakes.
> New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak.
Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
> What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?
In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework.
> I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.
“Boring” and “simple” are ways to convey that it’s good to be risk averse. It’s a bit of rhetorical flourish that helps drive the point home: choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.
by moregrist - > What if you know NodeJS really well? Or MongoDb?
Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.
by simonw - "boring" means familiar. It should have more known unknowns than unknown unknowns.by bravura