Rendered at 20:37:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
NickNaraghi 1 days ago [-]
> 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.
Cthulhu_ 12 hours 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 1 days 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 1 days ago [-]
Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0]
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.
nine_k 17 hours 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.
nimih 18 hours 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).
groundzeros2015 14 hours ago [-]
Nah. It’s fine.
ChrisMarshallNY 24 hours ago [-]
Speaking of beans, here's a classic (totally different from the main topic. Welcome to Topic Creep):
This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
bch 22 hours 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 21 hours 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.
cwnyth 1 days 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 1 days ago [-]
You misspelled 'beers'. A boring technology.
monk_grilla 20 hours 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.
chrysoprace 19 hours ago [-]
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.
Cthulhu_ 12 hours ago [-]
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.
chrysoprace 9 hours ago [-]
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.
Maxion 15 hours ago [-]
Surprisingly I'd still consider this blog post relatively accurate on what it calls boring vs. non-boring.
gherkinnn 14 hours ago [-]
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.
selcuka 19 hours ago [-]
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.
igsomething 9 hours ago [-]
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.
pjmlp 11 hours ago [-]
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.
Cthulhu_ 12 hours ago [-]
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.
swiftcoder 11 hours ago [-]
> 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.
atoav 15 hours ago [-]
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.
whstl 13 hours ago [-]
> 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".
bluGill 10 hours ago [-]
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.
sgarland 20 hours 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 19 hours ago [-]
10 years ago though
mikestorrent 16 hours ago [-]
And here we are, almost all the complaints from a decade ago still have relevance
Cthulhu_ 11 hours ago [-]
Some wounds never heal. Like Angular 1->2.
samtheprogram 19 hours ago [-]
That's an insane take. Anything?!?
anon48293 15 hours ago [-]
Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?
whstl 13 hours ago [-]
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.
gherkinnn 14 hours ago [-]
Express
ahoka 13 hours ago [-]
Can you name a major Java framework or library (that's not abandonware)?
williamcotton 20 hours ago [-]
It’s pretty boring at this point.
tshaddox 21 hours 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 19 hours 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.
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.
thelastgallon 7 hours ago [-]
2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need. This will run with 99.99% uptime, 4-hour warranty from Dell/HPE (failover to the other server). Is also somewhat vertically scalable (upgrade RAM/SSD). Kids who finish high school can be taught to own and run this.
But .... if you run a multi cloud hybrid setup with kubernetes, service mesh, data [lake|pond|ocean] and millions of other fancy words in tech at each and every layer, you resume would look so awesome and you sound wicked smart. And the VP gets 600M budget for AWS and 600 developers, SREs, DevOps, PMO. It is not that things won't run, humans have perverse incentives.
I'm certain a lot of porn/adult industry run their setup like I mentioned with a Romanian dude running the entire infrastructure for $15K - $20K.
altern8 7 hours ago [-]
Yes, that's my preference too and nobody can convince me that an AWS setup is better unless you have millions of users.
I think that a lot of devs just think they _have_ to do it that way, or they over-optimize too early and build the ultimate system before they even know if anyone will use the app or site.
tpmoney 4 hours ago [-]
The biggest benefit to me as a developer at least in larger organizations that AWS gives is ownership of my stack and needs. I don’t need to file a purchase request for new servers to spin something up or deploy a new application. I don’t need to fight with other departments for the fixed CPU and memory capacities in our virtualization system.
But everything else would be so much simpler and better for most of the things I do if it could just be a normal box with normal software.
In theory I could build that experience with nothing but bare EC2 instances. But once you’re in AWS, they make using their managed things so tempting that convincing everyone else to not use them is an even bigger battle.
silvestrov 7 hours ago [-]
In the old days 25 years ago, x86 hardware was the main source of unreliability.
Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.
Breza 4 hours ago [-]
At work I use a tech stack written years and years ago in .Net that runs on a server we own in a colo. We use a CDN for some latency-sensitive serving, but almost everything is self-hosted. It's amazing how cheap it is for us to run a reasonably sizeable application.
Zak 6 hours ago [-]
Somebody I was talking to about a web app I wrote in Clojure asked me how I hosted it. He seemed surprised my answer was an $8/month VPS. That might be the wrong solution if it was going to have a million users, but it isn't.
This seems like the same phenomenon where desktop apps bundle a copy of Chromium.
robomartin 5 hours ago [-]
> 2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need.
I agree. Simple and effective.
I would add a third small machine to give HAProxy a third vote. The problem with only two machines is that, if communications between them fail, you don't want both believing the other died and doing the wrong thing. You could use that third machine for Postgres backups, which would be smart because Postgress replication is not the same as backup.
insanitybit 1 days ago [-]
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.
i_like_robots 1 days ago [-]
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't take off and was a dead end.
> 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.
insanitybit 1 days ago [-]
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 the tech industry used to be, people reference this post today.
> around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
jonahx 22 hours ago [-]
> 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.
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.
11 hours ago [-]
insanitybit 19 hours ago [-]
Replacing one bias with another feels silly, I can justify bad decisions just as well either way. Just have real discussions about the technical merits, not that crazy of an idea.
i_like_robots 1 days ago [-]
You seem to agree with the lecture/article but disagree with the title.
However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
insanitybit 1 days ago [-]
I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
i_like_robots 1 days ago [-]
Poor choices whether influenced by this article or engineers chasing CV points are no different. Boring technology is a tool or communication device like any other. I hope in your situation you were able to influence the engineers utilising it poorly to reconsider.
insanitybit 19 hours ago [-]
The point is exactly that - bad decisions happen when your reasoning is based on silly terms like "boring" or "hyped" or whatever. The solution is to discuss the merits of each solution as it pertains to the problem space, which "boring" does not help with (and obfuscates).
jagenabler2 18 hours ago [-]
While it shouldn't be the absolute guide for every technical decision, it helps to have abstractions to capture the intuition and years of experience that goes into choosing a solution. It can make the discussions smoother.
When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
There are scenarios where all that criteria is met but it's still a bad fit. Boring <> Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.
If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
insanitybit 6 hours ago [-]
> When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
jagenabler2 4 hours ago [-]
I'm sorry but it doesn't seem like you've actually read, or at least internalized, the article? These are direct quotes:
> 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.
Well understood software directly coincides with support, rollout, and patterns.
mr_toad 1 days ago [-]
My recollection is that MongoDB was based on CouchDB, except they dispensed with Erlang & JSON and went with more conventional technology.
mexicocitinluez 9 hours ago [-]
Not a fan of the phrase "CV driven development". It's a great example of a fundamental attribution error.
In my experience, people choose the wrong tech for a handful of reasons, last of which is to further their career.
Using that phrase also implies that the author's intentions are pure but others aren't. As if you have insight into what motivates them.
wink 7 hours ago [-]
"architecture by reading blog posts" is as an old boss of mine described it and I liked that better.
mexicocitinluez 7 hours ago [-]
That lines up with my experience.
What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.
I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.
bcrosby95 1 days ago [-]
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.
insanitybit 1 days ago [-]
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 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.
tp3358 1 days ago [-]
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 thing.
dwattttt 23 hours ago [-]
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.
tp3358 23 hours ago [-]
I guess context clues and the way the post was written had obvious implications - that was my point. I do understand it leaves a little open to interpretation, which is the angle he decided to comment on.
dnautics 7 hours ago [-]
It's not just thought terminating. It's hypocritical
why are you even doing in tech? your users should just use boring technology, pen and paper is great and boring, no need for a computer, much less a saas.
dzonga 22 hours ago [-]
I will say one of my career regrets was kinda being dogmatic about boring tech instead of being pragmatic e.g with new tech
there was a period around 2016-17s when people were building stuff with Node.js | Mongo. but it was risky tech though I had experience in it & turned some of those opportunities down cz I wanted to work with boring ruby/swift(iOS stuff) lol. rookie mistake.
fortunately the market made me wise up - you go where you're wanted.
bravura 1 days ago [-]
"boring" means familiar. It should have more known unknowns than unknown unknowns.
insanitybit 1 days ago [-]
So then say that.
Gormo 1 days ago [-]
The article does say that. Explicitly. It's even got a picture of Donald Rumsfeld to help drive the point home.
insanitybit 8 hours ago [-]
Then the word "boring" is pointless and the article is reductive.
geodel 1 days ago [-]
Well its understood. Maybe your definition of explicitness is only met by things written like Principia Mathematica.
insanitybit 1 days ago [-]
If it's understood then it's pointless. I also reject that it's understood.
I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
simonw 1 days ago [-]
> 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.
insanitybit 1 days ago [-]
Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).
simonw 1 days ago [-]
Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."
insanitybit 1 days ago [-]
I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.
simonw 1 days ago [-]
Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet.
Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
insanitybit 19 hours ago [-]
People also love coming up with any way to use Postgres or whatever thing they're already familiar with and they get to say "it's boring" like that means anything.
> Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
Or just encourage your team to have rational discussions about technical choices, how is this controversial?
simonw 19 hours ago [-]
The boring technology framing is meant to provide a hook to help people "have rational discussions about technical choices". It's a tool for inspiring conversation.
insanitybit 6 hours ago [-]
I don't get it. The inspiration is your product requirements, why would I need to say "it's boring" to get things started?
I feel like I've been pretty clear.
1. "Boring" is a bad term that obfuscates things that do not merit obfuscation. It's like saying "brb" in person instead of "I'll be back in 5 minutes" - "brb" means nothing to me, 30 seconds, 5 minutes, 30? And it saved you like 2 words? Silly, unserious, and fine for casual conversations but not for technical decisions like "what database do we use?".
2. It lets people lean into a bias. I see massive bias away from "hyped" tech. People on HN constantly condemn projects for being "hype" tech with no merit behind their criticism, or at least no expressed merit. It sounds very smart to say "oh that's just hyped" - this is a known bias that extends outside of tech. Calling something "boring" makes you sound smart but it doesn't convey information and it leads to the exact same decisions that "hype" would.
Having a conversation about technology is not hard. It's the job. It's one of the most important parts of the job. It is not worth papering over with some biased wording that is guilty of the same exact failure modes of the approach it attempts to deride.
simonw 3 hours ago [-]
I think this entire disagreement is about language, and in particular the implications of the term "boring".
The term we are looking for here is something that means:
"A piece of technology that has been around for long enough that all of the sharp edges have either been filed off or are well documented and understood. We would not be the first people to solve our particular problem using this stack - in fact we would be using it in a predictable way that many before us have already shown to work. It's widespread enough that many people already know it, both on our existing team and in the pool of people we might want to hire from. We won't get to show off about this - our usage of this technology will not become the thing of legends, or conference talks, or blog posts. Our problems require unique solutions in other areas, but for the bit that accepts incoming web requests and runs some queries against a database we can go with something that's low risk, well established and very unlikely to surprise us."
I think boring is a fantastic shortcut for that, especially if you can trust your collaborators to understand it to mean that.
If you can't trust your collaborators to understand that then sure, you need to find a different word.
A couple of decades ago I helped create Django. One of the achievements I'm most proud of is that Django has graduated over time to being one of the most clear examples of a "boring" technology - it's widely used, stable, reliable, and thoroughly understood.
zero_shift 5 hours ago [-]
I disagree with you, Simon. I almost always see "Use Boring Technology" to close down conversations, not open them up.
jason_oster 21 hours ago [-]
It does happen, but having the ability to pivot quickly is almost always more valuable than dealing with "the devil you know".
There is nothing wrong with evaluating something new and discovering it doesn't work out as expected. That's still a meaningful outcome. Try it, if it doesn't work, replace it. You've learned something in the process, and it's a mistake you won't make again.
At some point you have to trust in the scientific method. The hypothesis->test->evaluate->adjust hypothesis cycle hasn't been beaten for thousands of years.
moregrist 23 hours ago [-]
> 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.
23 hours ago [-]
insanitybit 4 hours ago [-]
> It’s a cute way of saying that you can only do 2-3 new things.
Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3?
> 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.
I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation.
> 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.
I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably.
The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one!
> Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve.
> 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 don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation.
> “Boring” and “simple” are ways to convey that it’s good to be risk averse.
They are very bad at this.
> It’s a bit of rhetorical flourish
I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits.
> 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.
New technology may not be orthogonal to it, it may be critical.
duckmysick 6 hours ago [-]
So what's your technology stack? Which criteria did you use when choosing it instead?
insanitybit 6 hours ago [-]
I don't have a technology stack. Do you just mean what am I using for current projects?
At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.
We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.
We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.
In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.
marcosdumay 1 days ago [-]
> 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.
insanitybit 1 days ago [-]
> That's quite hard to do for solutions that you don't know the details.
That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.
> You have an objection to something. It's clearly not to the article's point, though.
It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.
frrlpp 22 hours ago [-]
You are confusing software with technology. Choose boring technology, not choose old software.
insanitybit 7 hours ago [-]
I'm not, the post is what adds fog to what should be clear and direct conversations about technical solutions as per their ability to solve a product concern.
geodel 1 days ago [-]
Well your points are making sense in isolation whereas this article is making more sense in general.
> 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"
insanitybit 1 days ago [-]
I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements?
> 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"
Rule of thumb. And it's not a rule. It's a bias based on a vague term.
geodel 1 days ago [-]
Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.
insanitybit 1 days ago [-]
> Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.
Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.
dwattttt 23 hours ago [-]
It's the "don't eat processed food" of software engineering.
mexicocitinluez 9 hours ago [-]
Couldn't have said that last part better myself.
watwut 9 hours ago [-]
> What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc?
I mean, back in the real world of 2015, it does not have any of those things and we know it.
insanitybit 5 hours ago [-]
Back in 2015 neither did the "boring" ones cited in the article. The point is that you can at least talk about those things and evaluate them.
dyauspitr 16 hours ago [-]
At this point, any new programming language or framework adds nothing. Name one paradigm shifting programming language or framework over the last 10 years that has made anything previously not possible possible or even significantly easier.
insanitybit 7 hours ago [-]
That has nothing to do with anything.
cpursley 8 hours ago [-]
Phoenix LiveView
Animats 1 days ago [-]
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.
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.
torginus 8 hours ago [-]
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.
Animats 7 hours ago [-]
> there has been very little progress outside the field of AI during the past decade.
Rechargable batteries are much better. mRNA vaccines work. The Rust programming language works. Stacked ICs are working. Even mid-sized cities in Asia now have subways. Self-driving taxis are on the roads. There are multiple fusion power startups, and one or more might succeed. Satellite internet is available and cheap. Heat pumps have improved. Drones are really successful. Electric motor control technology has improved considerably. Humanoid robots are in pilot production.
torginus 5 hours ago [-]
Most of what you write about falls outside of software engineering or computing, with the exception of Rust - which is something that you could argue is a genuine improvement over SOTA.
theptip 1 days ago [-]
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.)
dwedge 1 days ago [-]
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
Animats 23 hours ago [-]
> Now it's a sure fire sign that the project was probably vibe coded.
Groan. That's sad.
jason_oster 22 hours ago [-]
Compare to what happened to Python. That will cheer you up!
jaggederest 20 hours ago [-]
Hey, at least python is now extremely consistent: it's an unpleasant tarpit regardless of whether it's human or AI generated. Ruby, too, rip my native programming language.
I remember in the pre-AI era I was doing a quick sample contract employment with a company that had >200 columns in their user table and was manually enumerating them in every query, multiple times. They were using SELECT $1,$2,...$184,$185 from tablename with an enormous list of columns referenced only by offset. That's not python's fault, but I've weirdly seen it more often in python codebases.
Animats 16 hours ago [-]
That's a different tarpit. That's the problem with object-relation mapping, which is trying to deal with the mismatch between structs in languages and rows in SQL. There are a huge number of such schemes, and they range from somewhat annoying to awful. They're bad across a broad range of programming languages.
This is an area where LLMs might actually help. Or make things worse. We'll have to see.
Pannoniae 22 hours ago [-]
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.
t-writescode 22 hours ago [-]
That’s definitely not true, and I’ll give two incredibly common examples:
1: arraylist. A library will probably do better than you. It’s already written and common.
2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.
Pannoniae 18 hours ago [-]
1. This isn't true whatsoever. You can easily do better than std::vector (trivial relocation support, non-inlined grow), better than C# List<T> (ref T accessor, batch add API, maybe even an add-uninitialised API or in-place constructing specific things), better than a Python list (this one is obvious), etc.
2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least, if your workload is simple, you can grab one off the top of the benchmarks, point AI at it to customise it a bit then you're good. But to be fair this one's a bigger structural investment so I do see your point. For smaller utilities the tradeoff is pretty clear.
t-writescode 17 hours ago [-]
Is it obvious? Those existing APIs have known performance characteristics and deep integration into several other libraries. The moment you custom-roll your own root library, you break integration with all existing other libraries that depend on the defaults. To add, your LLM has to think about your new custom version rather than looking at the billions of lines of examples using the one it already knows works from decades of historical data.
If you really, really need some ultra-micro-optimization, you’re obviously not the target of this; but unless you’re doing HFT or the most inner loop of a game engine, the standard library and all its deep integration and battle-testedness is worth the 1% perf hit.
inigyou 19 hours ago [-]
How many times has the stable and established X surprised you with some unexpected behavior?
Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return a custom error code 444.
t-writescode 17 hours ago [-]
How many times have existing APIs made by experts in their fields had bugs.
How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed?
You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?
inigyou 10 hours ago [-]
See now, we keep assuming without evidence that the old thing is actually better.
Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)
But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.
Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.
I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.
Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.
Remember Heartbleed? The old "battle tested" system turned out not to be.
firesteelrain 19 hours ago [-]
RFC 3986 treats %2F as a reserved character that behavior becomes app specific.
theptip 15 hours ago [-]
Agents can’t one-shot the problems that boring technology solves. So I think your first premise is mistaken. There is no trivial “just DIY” option for Postgres or Django or Kubernetes.
59nadir 15 hours ago [-]
> 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.
Cthulhu_ 11 hours ago [-]
That's where the human factor comes in though: boring tech makes for boring work makes for bored people, and bored people quit (or worse, introduce complexity for the sake of it).
LLMs are better at churning out boring stuff, and you can see a lot of bored people perk up in the age of AI - they can now fire up half a dozen agents so they can express their ideas and see them made reality, instead of leaving their ideas to be ideas because implementing them is boring.
hahahaa 23 hours ago [-]
I find agents default to popular which heavily overlaps with boring although you could steer them more boring for sure.
Cthulhu_ 10 hours ago [-]
I don't agree about the overlap, as popular is new and shiny and stimulating, whereas boring is old and proven and, well, boring.
I wouldn't leave technology choices up to LLMs anyway unless you give them all the context and requirements. And this is where experienced software developers come in, who know and / or have experienced the short and long-term effect of technology choices (whether they were boring or not). LLMs can mainly go by what they read on the internet, both hype and sales pitches and (more boring and less frequently posted) retrospectives if you don't give them enough context.
hahahaa 6 hours ago [-]
I mean popular as in by actual usage rather than emotion/hype. It is usually boring that is popular from what I see.
Agree about LLM not choosing tech. Although that could mean dictating upfront or let it choose then review/steer.
epolanski 1 days ago [-]
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.
infamia 1 days ago [-]
Great point! I'd also add that Django's another solid choice for boring tech that LLM agents will know very well and will very likely continue to do so. A fair bit of SWE Bench and other Python benchmarks are Django related tests, which the LLM vendors care very deeply about keeping their scores up. Also, Django's docs are excellent, so strategically pointing an LLM to them in a prompt can often produce great results.
ipsod 1 days ago [-]
Django is the only thing I've used where I've vibe-coded an app, then looked at the code and not been appalled.
michaelchisari 1 days ago [-]
PHP has had a lot of conventions so the training data is all over the place. Ruby is a nightmare in that regard. Can't speak to Elixir but I'm surprised to hear someone say LLMs producing good code in either language.
On the other hand, Go code from 2012 and Go code from 2026 looks virtually the same. Conventions are respected, go fmt is the one single formatter, "use the stdlib" is a popular mantra and the code is readable by design.
If I were to codegen a project I wouldn't use anything but Go at this point.
bluehatbrit 22 hours ago [-]
I've been using elixir professionally and for hobby work for the past 7 years now. Language models are damn good at it, and have been for some time.
The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.
I can't speak for Ruby or PHP.
epolanski 22 hours ago [-]
I also like Elixir, and I've used it for a handful of projects, the language may not be huge, but is conversely bloated by macros.
I dislike macros and languages allowing developers to get creative with their own DSLs.
10000truths 24 hours ago [-]
> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo
Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I've always disabled those and haven't yet run into issues. The JS-written bundlers can also be slow, but I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care. The main build bottleneck I can think of for a modern TypeScript project would be build plugins, since those are still written in JS/TS.
Cthulhu_ 10 hours ago [-]
It's pragmatism vs... the other bit. I think complex environments like TS can work if the problem, organization and context is complex. But it's likely overkill for a weekend project.
stickfigure 22 hours ago [-]
Alternatively, if AI is doing most of the work, why not pick a platform that performs? If the cost of the code (and preferences of the developers) are factored out of the equation, pick based on operational cost.
Serving traffic with Ruby and Python is significantly more expensive than serving traffic with Java or Go.
add-sub-mul-div 1 days ago [-]
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.
Gormo 1 days ago [-]
Is that what's happening in this example, though? Ditching TypeScript in favor of PHP seems to be a net positive in favor of having a reliable, performant tech stack. From certain perspectives, TypeScript is itself a form of technical debt: writing code in one language just to transpile it into another interpreted language just to add type safety to correct for human error seems like a heavy layer of complexity just to make development teams work faster.
If we get to the point where AI tools are able to consistently able to produce desired results within strict performance and security constraints, without having to make the same tradeoff between delivery velocity and final quality, why would we not have them target the lowest level feasible for implementation, and cut out all of the middleware cruft that makes everything slow and take up ten times the RAM it actually needs to?
Cthulhu_ 10 hours ago [-]
To a point I agree, but also, I think if code is easy to read, write and maintain by LLMs it's easy to read, write and maintain by humans.
To just yeet in a software engineering wisdom (replace debugging with maintaining, extending, reading, etc as you will):
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.
dwedge 1 days ago [-]
I disagree. We've been doing this for two decades already. A lot of monoliths were rewritten in a way that best fit the AWS pricing model of the time with the software itself seemingly being an after afterthought. (I'm not here to discuss whether monoliths or micro services are better, I'm just saying the choice of how they were rewritten was too often mostly for AWS pricing)
epolanski 1 days ago [-]
I think you're completely misreading what I wrote.
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.
Feels like some good points but the llm writing makes it feel less trustworthy
__MatrixMan__ 1 days ago [-]
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.
jonahx 23 hours ago [-]
> 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.
That is tragically sad.
dylan604 22 hours ago [-]
It's better than saying invisibility as that always leads to someone being creepy. Laser beam eyes is of limited use. Moving through walls seems kind of meh to me as that's not a really limiting factor in my day to day. Shooting webs from my writs maybe kind of cool, but if its main use is for moving around it is much more limited than just being able to fly. Lasso of truth isn't really a super power but an interesting artifact. Of all of the super powers, the ability to fly does feel the most utilitarian to me. Plus, think of how environmentally friendly that super power would be if everyone could do it
zahlman 15 hours ago [-]
> It's better than saying invisibility as that always leads to someone being creepy.
I'm sure plenty of people would choose invisibility simply out of extreme introversion.
0cf8612b2e1e 21 hours ago [-]
Telekinesis strikes me as the most practically useful. How often I have yearned for a third hand to hold something at a tricky angle. Depending on how fine of control you get, you can also heat/cool matter.
Flight -is it as hard as running? Can I fly faster than I run? Do I get a force field or will I be constantly eating bugs?
rienbdj 23 hours ago [-]
It’s easier to imagine a super power than the end of capitalism, apparently.
inigyou 19 hours ago [-]
It's famously easier to imagine the end of the world than the end of capitalism.
ForHackernews 22 hours ago [-]
Boring isn't bad. Ideas are cheap: often the execution is what counts. Doing a boring thing to near-perfection looks like the Japanese Shinkansen trains that average 1.6 minutes of delay annually and have operated with zero fatal accidents over decades of service.
__MatrixMan__ 12 minutes ago [-]
Sure, if the thing is worth doing in the first place. How many of us can say that about our jobs though?
davnicwil 6 hours ago [-]
I wonder how much of this universal lesson will be rehashed to fit the aftermath of what's currently going on with vibe coding etc.
I think it's pretty likely that in, let's just go for the round number and say 80% of cases, everyone will conclude that just existing well used frameworks / code generator templates where everything's understood and most of the hot paths are well tested is pretty fast to build with (and more importantly, maintain and operate) and was really all we needed for most useful business software.
k__ 6 hours ago [-]
I had the opposite impression.
LLMs can abstract pretty well. They write quality code for obscure frameworks no problem, as longs as you take the time to set up tight feedback loops.
davnicwil 4 hours ago [-]
[dead]
willejs 8 hours ago [-]
This is one of my favourite blogposts and then presentations https://boringtechnology.club/... Back when it first came out, everyone was rushing to build microservices and shun practiced technologies, systems and software architectures, in search of some shortcut to software and systems utopia.
It was fairly obvious it wasn't going to deliver, but usually newer and more inexperienced engineers were extremely enthusiastic and would build the ultimate mess. This was a refreshing blog and presentation that provided a way to communicate to people boring is better, and to ship product.
jmartrican 8 hours ago [-]
I think this blogpost changed the industry. Maybe it gave us all permission to go with what we know. A million devs sighed in relief. lol
dnautics 7 hours ago [-]
i dont know. ive seen and dealt with so many shit codebases that were justified because python/java/etc are "boring technologies" that had extreme gunning fog index for understanding the code because those boring technologies were not created for the task and were so cornered in to place because of needing backwards compatibility.
do you remember pythons miserable asyncio era (or how long it took to remove gil)? hell theres even something to the joke that "docker was created because python's pip is atrocious".
i dont think it changed the industry for better. it created a thought terminating slogan that was used to justify choices that were bad for developer ergonomics and curtail people trying for sonething better
willejs 4 hours ago [-]
I think you can apply this too strictly. this is really about having informed technical and business conversations and making tradeoffs. It encourages you to innovate, there are tokens, but to be careful.
Sometimes its fine to do something in the wrong language if everyone has the experience and tooling/setup and its productive enough, otherwise its time to spend the tokens...
cliche 21 hours ago [-]
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
eudamoniac 20 hours ago [-]
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.
cliche 3 hours ago [-]
That’s a good shout I miss ruby / rails
zahlman 15 hours ago [-]
Last I checked, Java was still more popular than C# (for reasons I can't comprehend).
eudamoniac 5 hours ago [-]
Most companies are boring and conservative in tech. Just not most "tech companies".
Maxion 14 hours ago [-]
Same with Python/Django/DRF
conrs 1 days ago [-]
Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.
andai 1 days ago [-]
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.
Cthulhu_ 10 hours ago [-]
Exactly; I've seen a number of instances now of people pushing the hip new technology, but jumping ship (i.e. getting promoted, a new job, or a different assignment) shortly before or after the shiny new thing was "done".
In one case, ten years later, the company is still struggling to maintain their Scala applications in an environment where there's barely any Scala developers (and who charge a premium because it's specialist work), while the main author(s) went on to work at the company behind Scala itself. I'm sure Scala is great for specific use cases (just like every other non-top-10 language out there) but please, think very carefully before trying to build your company on top of it.
abirch 1 days ago [-]
I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.
Cthulhu_ 10 hours ago [-]
Exactly. When I joined the company I'm at now (consumer energy industry), the energy crisis hit and the servers melted from all the people looking to fix their contracts etc. I wasn't directly involved, but loads of developers did a mammoth effort to rewrite old services to prevent this from ever happening again.
New energy crisis this year, the servers held, the company made a lot of money from new contracts via a combination of getting lucky with long-term buy-in contracts and the servers staying up unlike the competition. But there were no heroes, no praise to e.g. the developers putting in the extra hours, etc - it was business as usual, or business as it's supposed to be.
andai 23 hours ago [-]
I've been noticing this as a solo dev. I need to put lots of work into infra and security, and all I get for it is... the thing not blowing up (hopefully!).
The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
Cthulhu_ 10 hours ago [-]
And the worst part is, because it's invisible, a higher up manager will think "Ah, we don't need these people anymore, let's replace them with juniors, an external company, and/or AI". It's maddening.
It's why senior developers should end up in management or in positions of making decisions, but it's a completely different type of job to software development, where reason and objective truth and whatnot is barely relevant compared to social skills and connections. (this may be inaccurate, I'm not in that 'layer').
devin 1 days ago [-]
Try to explain that part of an imagined "Agentic AI Everything" product being built would be cheaper and more efficient as a simple function call. Good luck!
simonw 1 days ago [-]
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.
red_admiral 12 hours ago [-]
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.
Cthulhu_ 10 hours ago [-]
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.
jason_oster 22 hours ago [-]
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.
euthymiclabs 1 days ago [-]
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.
jay_kyburz 1 days ago [-]
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.
gwbas1c 7 hours ago [-]
Regarding "Optimize Globally"
At my current job we generally use LINQpad for scripting, and have a lot of tests that use LINQPad scripts.
When I joined, there was a test that relied on an "R" script. Now, "R" might be the best tool for the job, but no one running the test would ever have any "R" experience. In addition, the environment to run "R" has quite the learning curve.
I ported the script to LINQPad. The fact that no one needs to install "R" or figure out how to run "R" is a much more massive timesaver than the fact that "R" was technically better for that one task. (And the script itself is pretty straightforward.)
lilerjee 11 hours ago [-]
I have the similar opinions:
We need to remember that the purpose of using tools is to solve specific problems and achieve goals. Having no tools, too few tools, or too many tools can all hinder the achievement of those goals. We only need to select a few useful, universal, and widely applicable tools. Unless there are necessary and sufficient reasons, we shouldn't easily switch to new tools.
For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.
benrutter 12 hours ago [-]
This is a great article, I feel like I think of this a lot when I build something new.
The tricky bit I think though, is deciding what actually is boring, since really we should factor complexity in too.
I work a lot with data in python, for in memory data, the most popular choices are:
- pandas
- pyspark
- polars
Pandas is the most established, although has a lot of technical limitations, as well as complexities.
Pyspark is definitely an "industry standard" choice, but now you're dealing with distributed computing when you probably didn't need too.
Polars is the simplest in terms of API and not being distributed, but then is the newest.
I can easily imagine a discussion where three engineers all agree that they should choose the "most boring" tech, but all choose a different option.
Cthulhu_ 11 hours ago [-]
This is where 'boringness' is only one factor in the bigger equation, and you (as a team) should make a list of criteria - familiarity, features, cost, hiring, support/backing, etc.
wewewedxfgdf 1 days ago [-]
Counter-position: "choose most appropriate technology".
Cthulhu_ 10 hours ago [-]
It really depends, there are a lot of axes to consider. When the most appropriate technology is e.g. a programming language that less than 1% of developers on the market can write competently, would you risk the company on it?
interf4ce 10 hours ago [-]
Choosing the most appropriate tech is not mutually exclusive with choosing boring tech. In fact, "boring" (well-known, battle-tested) is very likely the most appropriate because it reduces unnecessary risk.
nawh. 50x node modules, typescript out the wazoo, all the state in the client (where you can't see it in prod), the most over-complicated UI, paired with async callback spaghetti is what you do these days.
We're "scalable" over here. It's a sexy problem to have.
gdiamos 13 hours ago [-]
In hindsight I disagree.
Instead I like “only work on impossible problems”
Most of them turn out to be impossible, but some of them turn out to be possible.
I’ve never met anyone who could pick 3 and be confident in getting even one right. Tokens are a terrible analogy for innovation or research.
In hindsight I’ve had to sift through hundreds or more to fine one that worked.
I thought this post was helpful when I first started thinking about startups.
After more time, I think boring tech isn’t worth thinking about.
red_admiral 12 hours ago [-]
Innovation or research, maybe. Keeping an enterprise system running and maintainable is the opposite problem.
gdiamos 11 hours ago [-]
There's certainly a place for enterprise and not breaking what's working.
Shouldn't that be 0 innovation tokens though?
tetrisgm 1 days ago [-]
The title reminds me of Gunpei Yokoi, the original genius designer at Nintendo, whose philosophy was: lateral thinking, with old technology
dexterlagan 13 hours ago [-]
Can confirm. Use boring, proven tech at work. Experiment at home, on your own time. Using 'exciting' and new tech is fun but brings risks that are often unacceptable. If the tech dies, you have just created a pile of debt for your business, and potentially years of difficult maintenance and possibly a rewrite ahead. Don't.
smolder 14 hours ago [-]
Boring technology is great for making things in certain niches. This argument gets used a lot to encourage Java for every purpose, which comes from a myopic view of the landscape of languages. Advocates of many languages use the "least effort with biggest result" claim, and it's out of ignorance.
waldarbeiter 9 hours ago [-]
Not to bring LLMs into everything but I think they make using boring stuff more likely. Since training data contains a lot of it and less of the shiny new stuff.
leecommamichael 9 hours ago [-]
I wish LLMs were more boring.
dwedge 1 days ago [-]
I read a similar blog post years ago about restricting the technologies you use, and making do with a slightly worse option if it means reusing the stack you already have.
The example they gave was something like they wanted to use rabbitmq for a new side project (I might be misremembering) but they were forced to make it work with redis instead. The author said that years later he found out that that side project had exploded in popularity and it had coped with it fine because the infra team were already handling the stack and it wasn't some snowflake deployment.
> A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.
> An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.
dwedge 1 days ago [-]
I can't believe I was asking about the same article. The flow of time made it feel different and I forgot this was one of my all time favourites that I've been trying to re-find for years. Thank you
1 days ago [-]
mr_toad 1 days ago [-]
Does nobody ever think of trying more than one technology? It’s like people buying a car based on what everyone else is driving rather than actually driving different cars.
voiper1 24 hours ago [-]
Only do one new thing at a time.
Don't drive a new car, using new a new type of engine, with a new type of steering wheel, with a new type of entertainment system, .... all at once.
WHEN something goes wrong it will be intense trying to figure it out.
interf4ce 10 hours ago [-]
I think you're conflating general "boringness" with tech-specific features. Test driving solutions is useful but it tells you nothing about reliability.
Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.
Cthulhu_ 10 hours ago [-]
Sure, that's what the POC stage of choosing technology is about if you can't make a decision on blurbs on websites or comparison tables.
grebc 24 hours ago [-]
Good question.
Highly likely to not get any other replies as it’s too much uncommon sense.
clueless 1 days ago [-]
I remember reading this back in 2015, but how is this not just the age old conservative (don't do more than needed) vs progressives (lets try some new risk things) debate? As much as I can relate to a more conservative choice when choosing tech that might power a giant consumer company, sometimes using riskier tech in a startup makes more sense to get the real innovation flowing...
and the idea of "Choose New Technology, Sometimes" just feels like a little cheat to get away from the bigger issue with the overall thesis. In this way, the idea in this blog just feels so out of touch.
t-writescode 1 days ago [-]
It’s not about conservative vs progressive but about “safe, battle-tested, stable” vs “could be amazing future-tech”; and the idea of having a small number of innovative technologies, in particular where they matter, is about allowing yourself to spend all those thought-tokens on areas that matter.
You don’t want to be innovating your logging tech or your database if the old will work because you might spend 90% of your time trying to get your new, creative logging solution working when you should be spending it on the creative part of your business.
22 hours ago [-]
clueless 24 hours ago [-]
I might be missing something but conceptually, “safe, battle-tested, stable” vs “could be amazing future-tech” IS about conservative vs progressive... am I missing something?
t-writescode 16 hours ago [-]
Good point, I suppose conservative is the right word there. Its broader meaning has been a bit louder lately, so I didn’t think of it the right way there.
nonameiguess 1 days ago [-]
I feel like there's a common theme in business advice like this, the bullshit jobs thesis, general alienation of workers, that individuals have a lot of tunnel vision and don't understand the place of a firm in capitalism. The reality is we don't know what strategies will and won't succeed. The system overall works to the extent it works because a hundred thousand monkeys throwing shit at the wall are bound to hit a few targets at least a few times, even if the vast majority of them miss. The larger economy and investment ecosystems are set up under the assumption that most products will never see a single user and most companies will fail. Most employees will spend much of their careers working on projects that get scrapped. It's not much different than life itself. Evolution has no master plan. Most organisms never reproduce. Most species barely make a blip in any ecosystem before going extinct. It sucks for the individuals, but the larger collective goes on and thrives. Life itself does fine. The economy at large does fine, in spite of the ebbs and flows of the business cycle with its bubbles and recessions. Everything still works out in the long run. It's not only okay to fail but it's crucial to the long run success of our collective endeavors.
The vast majority of business strategy is just the lucky survivors assuming in retrospect they were smarter than everyone else. I've been seeing it my entire life, not just in business but in the military, in politics, in sports, in entertainment. Some project leader has one success and coasts off of that forever, failing over and over again afterward because they keep getting rehired, reelected, or re-invested in by inherently conservative investors, hiring committees, team owners, voters, party leaders, who blindly assume winning a Super Bowl means you must have known what you were doing, no matter how many random bounces going your way you had no control over it took.
jcmontx 1 days ago [-]
Excellent post. Now, somewhat outdated, and in other ways, more relevant than ever. To whom it may concern: if you need a database, always choose postgresql.
pianopatrick 23 hours ago [-]
One theory these days might be that old, boring technology is better represented in the training data for AI models...
geophile 1 days ago [-]
Think inside the box!
Sadly, that is real out-of-the-box thinking.
Krei-se 23 hours ago [-]
PHP is boring - but it works.
wewewedxfgdf 21 hours ago [-]
This is a generalization.
And generalizations in software development are always wrong.
westoque 1 days ago [-]
i just did an AI hackathon and 90% of the submissions were written in TypeScript and Next.js which is mostly due to the training data. AI is skewed to use these tools by default vs the best for the job.
martythemaniak 1 days ago [-]
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.
leetrout 1 days ago [-]
Over 12 years of popular usage at this point. I still think it's inappropriate for ~90% of the companies using it.
asa400 21 hours ago [-]
Apologies in advance this turned in to a bit of a rant of violent agreement.
For most places k8s is a complete boat anchor. Ends up being a huge complication and sap on product momentum. Can’t tell you how many outages I’ve seen from k8s misconfiguration and misunderstanding.
In no world would I consider k8s to be boring, I can’t understand how all of these shops have convinced themselves that k8s specifically is the level of abstraction at which they want to be interacting with their infrastructure.
I think k8s happens because a large number of devs look at Heroku-like platforms and bristle at the notion that they could ever be expected to intentionally constrain their brilliant system designs into preexisting, Heroku-style shapes. It’s ego on some level.
That, and a ton engineers are still incredibly bad at trading off hardware cost and compensation/complexity/organizational cost. “Heroku will cost us $2000/month, running k8s on our own hardware will only cost $400/month.” Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal? This happens all the freaking time, it’s crazy how little devs value their own time.
rzerowan 23 hours ago [-]
Ideally a techthat is not core to the business goals should neither occupy dev/ops time managing it or be so complex that its failure modes are cryptic. It should get out of the devs way and be easy to grok in case of failures.
sleight42 22 hours ago [-]
This isn't new.
This should not be new.
Make your shit work. Make it work well. Don't fuck with a thing that's working as desired.
In this way, you'll make everyone's lives at least a little easier.
This should be a mandatory teaching to anyone who wants to use the moniker of "engineer".
tosh 1 days ago [-]
aged well
threethirtytwo 20 hours ago [-]
This is a stupid single minded philosophy. What if the new non-boring technology has an exclusive feature you need? What if it's genuinely better?
It's a case by case basis. I wonder why people try to encapsulate these things into "philosophies" that are simple minded and stereotypical.
Choose what's better. That's not always necessarily boring technology. Sometimes it is... sometimes it isn't.
rienbdj 23 hours ago [-]
This blog post annoys me a little. Not the post itself - it’s great - but how it has been used to prop up thousands of lazy arguments against innovations over the years.
lloydatkinson 12 hours ago [-]
The "content not viewable in your region" images really sets the tone.
gaigalas 1 days ago [-]
Go hard boring on 80% of what you do. Go hard exciting on the 20% else.
Don't let one affect the other.
jmartrican 8 hours ago [-]
Now boring tech is what is well known by the LLM (Python, typscript, etc.).
tosh 1 days ago [-]
now 11y later i wonder if 'node.js' still needs an innovation token or not
wmf 1 days ago [-]
Node.js has been boring for a while.
esafak 1 days ago [-]
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.
xboxnolifes 1 days ago [-]
They mean as the article describes. Does using node require using an innovation token.
everyone 12 hours ago [-]
imo only webdevs would ever need to say something like this.. It seemed to me that webdev was so trivial that webdevs became eccentrics and invented all sorts of wacky frameworks and languages just to make their work challenging and interesting.
dofm 1 days ago [-]
A problem shared is a problem halved.
positron26 1 days ago [-]
Lol. In 2015 boring technology is at the hands of your PM spinning up some agent spam. Bury this pile of outdated thinking. Go hard at the most difficult programming you can find or go home.
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.
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.
Maybe it wasn't beans? But, I've been looking for it for years.
[0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
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.
https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
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.
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.
> 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.
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.
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'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.
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.
If it was for me, JavaScript would stay in the browser.
Probably not in 2026, but it 2015 it was pretty new and shiny.
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.
+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".
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.
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."
“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.
But .... if you run a multi cloud hybrid setup with kubernetes, service mesh, data [lake|pond|ocean] and millions of other fancy words in tech at each and every layer, you resume would look so awesome and you sound wicked smart. And the VP gets 600M budget for AWS and 600 developers, SREs, DevOps, PMO. It is not that things won't run, humans have perverse incentives.
I'm certain a lot of porn/adult industry run their setup like I mentioned with a Romanian dude running the entire infrastructure for $15K - $20K.
I think that a lot of devs just think they _have_ to do it that way, or they over-optimize too early and build the ultimate system before they even know if anyone will use the app or site.
But everything else would be so much simpler and better for most of the things I do if it could just be a normal box with normal software.
In theory I could build that experience with nothing but bare EC2 instances. But once you’re in AWS, they make using their managed things so tempting that convincing everyone else to not use them is an even bigger battle.
Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.
This seems like the same phenomenon where desktop apps bundle a copy of Chromium.
I agree. Simple and effective.
I would add a third small machine to give HAProxy a third vote. The problem with only two machines is that, if communications between them fail, you don't want both believing the other died and doing the wrong thing. You could use that third machine for Postgres backups, which would be smart because Postgress replication is not the same as backup.
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.
> 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.
> 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 the tech industry used to be, people reference this post today.
> around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
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.
However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
There are scenarios where all that criteria is met but it's still a bad fit. Boring <> Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.
If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
> 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.
Well understood software directly coincides with support, rollout, and patterns.
In my experience, people choose the wrong tech for a handful of reasons, last of which is to further their career.
Using that phrase also implies that the author's intentions are pure but others aren't. As if you have insight into what motivates them.
What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.
I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.
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.
TLDR; #1 and #2 are essentially implying the same thing.
why are you even doing in tech? your users should just use boring technology, pen and paper is great and boring, no need for a computer, much less a saas.
there was a period around 2016-17s when people were building stuff with Node.js | Mongo. but it was risky tech though I had experience in it & turned some of those opportunities down cz I wanted to work with boring ruby/swift(iOS stuff) lol. rookie mistake.
fortunately the market made me wise up - you go where you're wanted.
I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.
Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
> Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
Or just encourage your team to have rational discussions about technical choices, how is this controversial?
I feel like I've been pretty clear.
1. "Boring" is a bad term that obfuscates things that do not merit obfuscation. It's like saying "brb" in person instead of "I'll be back in 5 minutes" - "brb" means nothing to me, 30 seconds, 5 minutes, 30? And it saved you like 2 words? Silly, unserious, and fine for casual conversations but not for technical decisions like "what database do we use?".
2. It lets people lean into a bias. I see massive bias away from "hyped" tech. People on HN constantly condemn projects for being "hype" tech with no merit behind their criticism, or at least no expressed merit. It sounds very smart to say "oh that's just hyped" - this is a known bias that extends outside of tech. Calling something "boring" makes you sound smart but it doesn't convey information and it leads to the exact same decisions that "hype" would.
Having a conversation about technology is not hard. It's the job. It's one of the most important parts of the job. It is not worth papering over with some biased wording that is guilty of the same exact failure modes of the approach it attempts to deride.
The term we are looking for here is something that means:
"A piece of technology that has been around for long enough that all of the sharp edges have either been filed off or are well documented and understood. We would not be the first people to solve our particular problem using this stack - in fact we would be using it in a predictable way that many before us have already shown to work. It's widespread enough that many people already know it, both on our existing team and in the pool of people we might want to hire from. We won't get to show off about this - our usage of this technology will not become the thing of legends, or conference talks, or blog posts. Our problems require unique solutions in other areas, but for the bit that accepts incoming web requests and runs some queries against a database we can go with something that's low risk, well established and very unlikely to surprise us."
I think boring is a fantastic shortcut for that, especially if you can trust your collaborators to understand it to mean that.
If you can't trust your collaborators to understand that then sure, you need to find a different word.
A couple of decades ago I helped create Django. One of the achievements I'm most proud of is that Django has graduated over time to being one of the most clear examples of a "boring" technology - it's widely used, stable, reliable, and thoroughly understood.
There is nothing wrong with evaluating something new and discovering it doesn't work out as expected. That's still a meaningful outcome. Try it, if it doesn't work, replace it. You've learned something in the process, and it's a mistake you won't make again.
At some point you have to trust in the scientific method. The hypothesis->test->evaluate->adjust hypothesis cycle hasn't been beaten for thousands of years.
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.
Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3?
> 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.
I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation.
> 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.
I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably.
The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one!
> Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve.
> 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 don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation.
> “Boring” and “simple” are ways to convey that it’s good to be risk averse.
They are very bad at this.
> It’s a bit of rhetorical flourish
I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits.
> 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.
New technology may not be orthogonal to it, it may be critical.
At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.
We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.
We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.
In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.
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.
That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.
> You have an objection to something. It's clearly not to the article's point, though.
It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.
> 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"
> 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"
Rule of thumb. And it's not a rule. It's a bias based on a vague term.
Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.
I mean, back in the real world of 2015, it does not have any of those things and we know it.
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%...
[4] https://www.youtube.com/watch?v=k8EURBL53_k
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.
Rechargable batteries are much better. mRNA vaccines work. The Rust programming language works. Stacked ICs are working. Even mid-sized cities in Asia now have subways. Self-driving taxis are on the roads. There are multiple fusion power startups, and one or more might succeed. Satellite internet is available and cheap. Heat pumps have improved. Drones are really successful. Electric motor control technology has improved considerably. Humanoid robots are in pilot production.
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.)
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
Groan. That's sad.
I remember in the pre-AI era I was doing a quick sample contract employment with a company that had >200 columns in their user table and was manually enumerating them in every query, multiple times. They were using SELECT $1,$2,...$184,$185 from tablename with an enormous list of columns referenced only by offset. That's not python's fault, but I've weirdly seen it more often in python codebases.
This is an area where LLMs might actually help. Or make things worse. We'll have to see.
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.
1: arraylist. A library will probably do better than you. It’s already written and common.
2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.
2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least, if your workload is simple, you can grab one off the top of the benchmarks, point AI at it to customise it a bit then you're good. But to be fair this one's a bigger structural investment so I do see your point. For smaller utilities the tradeoff is pretty clear.
If you really, really need some ultra-micro-optimization, you’re obviously not the target of this; but unless you’re doing HFT or the most inner loop of a game engine, the standard library and all its deep integration and battle-testedness is worth the 1% perf hit.
Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return a custom error code 444.
How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed?
You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?
Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)
But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.
Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.
I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.
Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.
Remember Heartbleed? The old "battle tested" system turned out not to be.
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.
LLMs are better at churning out boring stuff, and you can see a lot of bored people perk up in the age of AI - they can now fire up half a dozen agents so they can express their ideas and see them made reality, instead of leaving their ideas to be ideas because implementing them is boring.
I wouldn't leave technology choices up to LLMs anyway unless you give them all the context and requirements. And this is where experienced software developers come in, who know and / or have experienced the short and long-term effect of technology choices (whether they were boring or not). LLMs can mainly go by what they read on the internet, both hype and sales pitches and (more boring and less frequently posted) retrospectives if you don't give them enough context.
Agree about LLM not choosing tech. Although that could mean dictating upfront or let it choose then review/steer.
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.
On the other hand, Go code from 2012 and Go code from 2026 looks virtually the same. Conventions are respected, go fmt is the one single formatter, "use the stdlib" is a popular mantra and the code is readable by design.
If I were to codegen a project I wouldn't use anything but Go at this point.
The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.
I can't speak for Ruby or PHP.
I dislike macros and languages allowing developers to get creative with their own DSLs.
Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I've always disabled those and haven't yet run into issues. The JS-written bundlers can also be slow, but I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care. The main build bottleneck I can think of for a modern TypeScript project would be build plugins, since those are still written in JS/TS.
Serving traffic with Ruby and Python is significantly more expensive than serving traffic with Java or Go.
If we get to the point where AI tools are able to consistently able to produce desired results within strict performance and security constraints, without having to make the same tradeoff between delivery velocity and final quality, why would we not have them target the lowest level feasible for implementation, and cut out all of the middleware cruft that makes everything slow and take up ten times the RAM it actually needs to?
To just yeet in a software engineering wisdom (replace debugging with maintaining, extending, reading, etc as you will):
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
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.
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'm sure plenty of people would choose invisibility simply out of extreme introversion.
Flight -is it as hard as running? Can I fly faster than I run? Do I get a force field or will I be constantly eating bugs?
I think it's pretty likely that in, let's just go for the round number and say 80% of cases, everyone will conclude that just existing well used frameworks / code generator templates where everything's understood and most of the hot paths are well tested is pretty fast to build with (and more importantly, maintain and operate) and was really all we needed for most useful business software.
LLMs can abstract pretty well. They write quality code for obscure frameworks no problem, as longs as you take the time to set up tight feedback loops.
It was fairly obvious it wasn't going to deliver, but usually newer and more inexperienced engineers were extremely enthusiastic and would build the ultimate mess. This was a refreshing blog and presentation that provided a way to communicate to people boring is better, and to ship product.
do you remember pythons miserable asyncio era (or how long it took to remove gil)? hell theres even something to the joke that "docker was created because python's pip is atrocious".
i dont think it changed the industry for better. it created a thought terminating slogan that was used to justify choices that were bad for developer ergonomics and curtail people trying for sonething better
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
In one case, ten years later, the company is still struggling to maintain their Scala applications in an environment where there's barely any Scala developers (and who charge a premium because it's specialist work), while the main author(s) went on to work at the company behind Scala itself. I'm sure Scala is great for specific use cases (just like every other non-top-10 language out there) but please, think very carefully before trying to build your company on top of it.
New energy crisis this year, the servers held, the company made a lot of money from new contracts via a combination of getting lucky with long-term buy-in contracts and the servers staying up unlike the competition. But there were no heroes, no praise to e.g. the developers putting in the extra hours, etc - it was business as usual, or business as it's supposed to be.
The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
It's why senior developers should end up in management or in positions of making decisions, but it's a completely different type of job to software development, where reason and objective truth and whatnot is barely relevant compared to social skills and connections. (this may be inaccurate, I'm not in that 'layer').
I've found it extremely useful over the years, personally.
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.
I'm glad I finally did, I've been enjoying it.
At my current job we generally use LINQpad for scripting, and have a lot of tests that use LINQPad scripts.
When I joined, there was a test that relied on an "R" script. Now, "R" might be the best tool for the job, but no one running the test would ever have any "R" experience. In addition, the environment to run "R" has quite the learning curve.
I ported the script to LINQPad. The fact that no one needs to install "R" or figure out how to run "R" is a much more massive timesaver than the fact that "R" was technically better for that one task. (And the script itself is pretty straightforward.)
We need to remember that the purpose of using tools is to solve specific problems and achieve goals. Having no tools, too few tools, or too many tools can all hinder the achievement of those goals. We only need to select a few useful, universal, and widely applicable tools. Unless there are necessary and sufficient reasons, we shouldn't easily switch to new tools.
For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.
The tricky bit I think though, is deciding what actually is boring, since really we should factor complexity in too.
I work a lot with data in python, for in memory data, the most popular choices are:
- pandas - pyspark - polars
Pandas is the most established, although has a lot of technical limitations, as well as complexities.
Pyspark is definitely an "industry standard" choice, but now you're dealing with distributed computing when you probably didn't need too.
Polars is the simplest in terms of API and not being distributed, but then is the newest.
I can easily imagine a discussion where three engineers all agree that they should choose the "most boring" tech, but all choose a different option.
We're "scalable" over here. It's a sexy problem to have.
Instead I like “only work on impossible problems”
Most of them turn out to be impossible, but some of them turn out to be possible.
I’ve never met anyone who could pick 3 and be confident in getting even one right. Tokens are a terrible analogy for innovation or research.
In hindsight I’ve had to sift through hundreds or more to fine one that worked.
I thought this post was helpful when I first started thinking about startups.
After more time, I think boring tech isn’t worth thinking about.
Shouldn't that be 0 innovation tokens though?
The example they gave was something like they wanted to use rabbitmq for a new side project (I might be misremembering) but they were forced to make it work with redis instead. The author said that years later he found out that that side project had exploded in popularity and it had coped with it fine because the infra team were already handling the stack and it wasn't some snowflake deployment.
Does anyone remember the post I'm talking about?
> A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.
> An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.
Don't drive a new car, using new a new type of engine, with a new type of steering wheel, with a new type of entertainment system, .... all at once.
WHEN something goes wrong it will be intense trying to figure it out.
Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.
Highly likely to not get any other replies as it’s too much uncommon sense.
You don’t want to be innovating your logging tech or your database if the old will work because you might spend 90% of your time trying to get your new, creative logging solution working when you should be spending it on the creative part of your business.
The vast majority of business strategy is just the lucky survivors assuming in retrospect they were smarter than everyone else. I've been seeing it my entire life, not just in business but in the military, in politics, in sports, in entertainment. Some project leader has one success and coasts off of that forever, failing over and over again afterward because they keep getting rehired, reelected, or re-invested in by inherently conservative investors, hiring committees, team owners, voters, party leaders, who blindly assume winning a Super Bowl means you must have known what you were doing, no matter how many random bounces going your way you had no control over it took.
Sadly, that is real out-of-the-box thinking.
And generalizations in software development are always wrong.
For most places k8s is a complete boat anchor. Ends up being a huge complication and sap on product momentum. Can’t tell you how many outages I’ve seen from k8s misconfiguration and misunderstanding.
In no world would I consider k8s to be boring, I can’t understand how all of these shops have convinced themselves that k8s specifically is the level of abstraction at which they want to be interacting with their infrastructure.
I think k8s happens because a large number of devs look at Heroku-like platforms and bristle at the notion that they could ever be expected to intentionally constrain their brilliant system designs into preexisting, Heroku-style shapes. It’s ego on some level.
That, and a ton engineers are still incredibly bad at trading off hardware cost and compensation/complexity/organizational cost. “Heroku will cost us $2000/month, running k8s on our own hardware will only cost $400/month.” Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal? This happens all the freaking time, it’s crazy how little devs value their own time.
This should not be new.
Make your shit work. Make it work well. Don't fuck with a thing that's working as desired.
In this way, you'll make everyone's lives at least a little easier.
This should be a mandatory teaching to anyone who wants to use the moniker of "engineer".
It's a case by case basis. I wonder why people try to encapsulate these things into "philosophies" that are simple minded and stereotypical.
Choose what's better. That's not always necessarily boring technology. Sometimes it is... sometimes it isn't.
Don't let one affect the other.
edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.