Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

81–90 of 269 posts

Re: Choose Boring Technology (2015)

#81

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 Technol…

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.

Re: Choose Boring Technology (2015)

#82

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 Technol…

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.

Re: Choose Boring Technology (2015)

#84
post #80

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.

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.

Re: Choose Boring Technology (2015)

#85
post #80

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.

Good question.

Highly likely to not get any other replies as it’s too much uncommon sense.

Re: Choose Boring Technology (2015)

#86
post #12
post #7

Earlier quoted context omitted.

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.

Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...

Speaking of beans, here's a classic (totally different from the main topic. Welcome to Topic Creep):

https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...

Re: Choose Boring Technology (2015)

#87
post #9

I love this post. It’s also interesting to revisit in the age of agents. Using the language of the article, I’d say “push all your innovation tokens into agents” is probably a good move. This means the tech your agents work with should all be boring tech. Another way of saying this is “use in-distribution technology”. If agents are substantially better at Rust than Zig, probably you should use Rust, even if Zig is “b…

One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client. And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but the…

> 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.

Re: Choose Boring Technology (2015)

#88

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 Technol…

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 y…

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?

Re: Choose Boring Technology (2015)

#89

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…

> I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens"

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.

Post reply on HN