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

111–120 of 269 posts

Re: Choose Boring Technology (2015)

#111

Post by bluehatbrit »

michaelchisari wrote: post #65
epolanski wrote: post #13

Earlier quoted context omitted.

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…

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

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.

Re: Choose Boring Technology (2015)

#112

Post by sleight42 »

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

Re: Choose Boring Technology (2015)

#113

Post by ForHackernews »

__MatrixMan__ wrote: post #73
iand675 wrote: post #67

Well, I've not tried to publish this on HN so far, but I guess given such a counterpoint, I should at least attempt to share: https://www.iankduncan.com/engineering/2026-08-07-getting-fr...

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.

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.

Re: Choose Boring Technology (2015)

#114

Post by [deleted] »

t-writescode wrote: post #81
clueless wrote: post #75

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…

[deleted]

Re: Choose Boring Technology (2015)

#115

Post by dzonga »

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…

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.

Re: Choose Boring Technology (2015)

#116

Post by stickfigure »

epolanski wrote: post #13
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…

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…

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.

Re: Choose Boring Technology (2015)

#117

Post by dylan604 »

jonahx wrote: post #108
__MatrixMan__ wrote: post #73

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

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

Re: Choose Boring Technology (2015)

#118

Post by frrlpp »

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…

You are confusing software with technology. Choose boring technology, not choose old software.

Re: Choose Boring Technology (2015)

#119

Post by epolanski »

bluehatbrit wrote: post #111
michaelchisari wrote: post #65

Earlier quoted context omitted.

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

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

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.

Re: Choose Boring Technology (2015)

#120

Post by bch »

nomel wrote: post #7
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…

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.

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.
Post reply on HN