Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

161–170 of 269 posts

Re: Choose Boring Technology (2015)

#161

Post by dyauspitr »

insanitybit wrote: post #19

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…

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.

Re: Choose Boring Technology (2015)

#162

Post by atoav »

monk_grilla wrote: post #135
NickNaraghi wrote: post #3

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

Re: Choose Boring Technology (2015)

#163

Post by anon48293 »

samtheprogram wrote: post #143
sgarland wrote: post #137

Earlier quoted context omitted.

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.

That's an insane take. Anything?!?

Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?

Re: Choose Boring Technology (2015)

#164

Post by theptip »

Pannoniae wrote: post #109
theptip wrote: 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…

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

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.

Re: Choose Boring Technology (2015)

#165

Post by Maxion »

chrysoprace wrote: post #146
monk_grilla wrote: post #135

Earlier quoted context omitted.

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

Surprisingly I'd still consider this blog post relatively accurate on what it calls boring vs. non-boring.

Re: Choose Boring Technology (2015)

#166

Post by zahlman »

dylan604 wrote: post #117
jonahx wrote: post #108

Earlier quoted context omitted.

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

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

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

Re: Choose Boring Technology (2015)

#167

Post by zahlman »

eudamoniac wrote: post #133
cliche wrote: post #128

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

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.

Last I checked, Java was still more popular than C# (for reasons I can't comprehend).

Re: Choose Boring Technology (2015)

#168

Post by 59nadir »

theptip wrote: 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…

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

Re: Choose Boring Technology (2015)

#169

Post by Maxion »

eudamoniac wrote: post #133
cliche wrote: post #128

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

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.

Same with Python/Django/DRF

Re: Choose Boring Technology (2015)

#170

Post by groundzeros2015 »

krapht wrote: post #52
PyWoody wrote: post #12

Earlier quoted context omitted.

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

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.

Nah. It’s fine.
Post reply on HN