Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

61–70 of 269 posts

Re: Choose Boring Technology (2015)

#61
post #10
post #8

Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.

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.

I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.

Re: Choose Boring Technology (2015)

#63

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…

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.

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?

Re: Choose Boring Technology (2015)

#64

Earlier quoted context omitted.

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.

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…

[deleted]

Re: Choose Boring Technology (2015)

#65
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…

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.

Re: Choose Boring Technology (2015)

#66

Earlier quoted context omitted.

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.

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.

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.

Re: Choose Boring Technology (2015)

#68

Earlier quoted context omitted.

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.

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…

[dead]

Re: Choose Boring Technology (2015)

#69

Earlier quoted context omitted.

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.

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

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.

Post reply on HN