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

191–200 of 269 posts

Re: Choose Boring Technology (2015)

#191

Post by Cthulhu_ »

benrutter wrote: post #181

This is a great article, I feel like I think of this a lot when I build something new. The tricky bit I think though, is deciding what actually is boring, since really we should factor complexity in too. I work a lot with data in python, for in memory data, the most popular choices are: - pandas - pyspark - polars Pandas is the most established, although has a lot of technical limitations, as well as complexities. Py…

This is where 'boringness' is only one factor in the bigger equation, and you (as a team) should make a list of criteria - familiarity, features, cost, hiring, support/backing, etc.

Re: Choose Boring Technology (2015)

#192

Post by Cthulhu_ »

59nadir wrote: post #168
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.

That's where the human factor comes in though: boring tech makes for boring work makes for bored people, and bored people quit (or worse, introduce complexity for the sake of it).

LLMs are better at churning out boring stuff, and you can see a lot of bored people perk up in the age of AI - they can now fire up half a dozen agents so they can express their ideas and see them made reality, instead of leaving their ideas to be ideas because implementing them is boring.

Re: Choose Boring Technology (2015)

#193

Post by pjmlp »

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.

It is more about being a dynamic language where V8 can only help as much, thus C++ addons, rewrites into .NET, Java, Go, Rust, and the whole npm system made of packages with single functions written by folks that just did their first package out of a bootcamp.

If it was for me, JavaScript would stay in the browser.

Re: Choose Boring Technology (2015)

#194

Post by lilerjee »

I have the similar opinions:

We need to remember that the purpose of using tools is to solve specific problems and achieve goals. Having no tools, too few tools, or too many tools can all hinder the achievement of those goals. We only need to select a few useful, universal, and widely applicable tools. Unless there are necessary and sufficient reasons, we shouldn't easily switch to new tools.

For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.

Re: Choose Boring Technology (2015)

#195

Post by swiftcoder »

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.

> Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed?

Probably not in 2026, but it 2015 it was pretty new and shiny.

Re: Choose Boring Technology (2015)

#196

Post by [deleted] »

jonahx wrote: post #110
insanitybit wrote: post #33

Earlier quoted context omitted.

CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how…

> CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. It doesn't though. It's very easy to manufacture reasons why "shiny new thing" is the objectively right fit for something, even when it's not. The word "boring" is well-chosen because it's addressing a bias m…

[deleted]

Re: Choose Boring Technology (2015)

#197

Post by gdiamos »

red_admiral wrote: post #185
gdiamos wrote: post #180

In hindsight I disagree. Instead I like “only work on impossible problems” Most of them turn out to be impossible, but some of them turn out to be possible. I’ve never met anyone who could pick 3 and be confident in getting even one right. Tokens are a terrible analogy for innovation or research. In hindsight I’ve had to sift through hundreds or more to fine one that worked. I thought this post was helpful when I fir…

Innovation or research, maybe. Keeping an enterprise system running and maintainable is the opposite problem.

There's certainly a place for enterprise and not breaking what's working.

Shouldn't that be 0 innovation tokens though?

Re: Choose Boring Technology (2015)

#198

Post by Cthulhu_ »

hahahaa wrote: post #106
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 find agents default to popular which heavily overlaps with boring although you could steer them more boring for sure.

I don't agree about the overlap, as popular is new and shiny and stimulating, whereas boring is old and proven and, well, boring.

I wouldn't leave technology choices up to LLMs anyway unless you give them all the context and requirements. And this is where experienced software developers come in, who know and / or have experienced the short and long-term effect of technology choices (whether they were boring or not). LLMs can mainly go by what they read on the internet, both hype and sales pitches and (more boring and less frequently posted) retrospectives if you don't give them enough context.

Re: Choose Boring Technology (2015)

#199

Post by Cthulhu_ »

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…

It's pragmatism vs... the other bit. I think complex environments like TS can work if the problem, organization and context is complex. But it's likely overkill for a weekend project.

Re: Choose Boring Technology (2015)

#200

Post by Cthulhu_ »

add-sub-mul-div wrote: post #15
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…

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.

To a point I agree, but also, I think if code is easy to read, write and maintain by LLMs it's easy to read, write and maintain by humans.

To just yeet in a software engineering wisdom (replace debugging with maintaining, extending, reading, etc as you will):

> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

        — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.
Post reply on HN