[flagged]
Choose Boring Technology (2015)
211–220 of 269 posts
Re: Choose Boring Technology (2015)
#212Not 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.
Re: Choose Boring Technology (2015)
#213Earlier quoted context omitted.
I think that in 2026 Node is a boring technology, but with the fast-moving ecosystem around it if you opt into npm (the registry, not the package manager) it makes it not boring. The things you layer on top of Node via npm could count as "not-boring" in this instance, especially with the number of supply-chain attacks each month.
Yeah, compared to most other languages there's a lot of moving parts and activity in the space still - npm vs pnpm vs yarn, node vs bun vs deno, eslint / prettier vs biome vs oxlint, and that's before even writing a single line of code. Boring in comparison would be Go where a lot of things are standardized. You still get some non-boring in choosing what libraries to use (if applicable) but generally it's a very dull…
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.
Re: Choose Boring Technology (2015)
#214Not 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.
I wish LLMs were more boring.
Re: Choose Boring Technology (2015)
#215I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…
> What if 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.
Re: Choose Boring Technology (2015)
#216I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…
I 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'…
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.
Re: Choose Boring Technology (2015)
#217> 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…
I also broadly agree with the post. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
I think 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.
Re: Choose Boring Technology (2015)
#218I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…
Couldn't have said that last part better myself.
Re: Choose Boring Technology (2015)
#219Re: Choose Boring Technology (2015)
#220This 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.