Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

181–190 of 269 posts

Re: Choose Boring Technology (2015)

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

Pyspark is definitely an "industry standard" choice, but now you're dealing with distributed computing when you probably didn't need too.

Polars is the simplest in terms of API and not being distributed, but then is the newest.

I can easily imagine a discussion where three engineers all agree that they should choose the "most boring" tech, but all choose a different option.

Re: Choose Boring Technology (2015)

#182
imo only webdevs would ever need to say something like this.. It seemed to me that webdev was so trivial that webdevs became eccentrics and invented all sorts of wacky frameworks and languages just to make their work challenging and interesting.

Re: Choose Boring Technology (2015)

#185

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.

Re: Choose Boring Technology (2015)

#186
post #55

Some of this may have been a reaction to the era of Javascript framework churn. There were way too many different technologies for doing roughly the same job. They all more or less worked. On the other hand, IBM was late getting into integrated circuits. They had Solid Logic Technology, automated machinery for putting transistors into ceramic substrates to make tiny but discrete circuits. That's what powered the IBM…

IBM briefly pulled ahead with the PC though, mainly by routing around their own bureaucracy. That was a hard innovation problem, especially without a crystal ball.

Re: Choose Boring Technology (2015)

#187

> 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 think a core problem is that people read online and spend a weekend looking into something cool and get a pretty decent POC up and running. But that's a single person in a weekend, nowadays accellerated by LLMs - what they cannot see (or, something that comes with experience) is how expensive or invasive it would be to apply that in your team or company-wide.

But innovation tokens is a neat idea, it's not personal - no big bad grumpy old senior being a square about CoolTech2026 - and it's an incentive to have someone that wants to do something cool think about it. The other one in that regard are ADRs, which I think is a very low barrier to entry path into architecture that most developers can do. It too forces the person to consider CoolTech2026 in a wider context - what does it solve, what is used right now to solve it, what other solutions are out there, etc - plus making it a team decision if executed right.

Re: Choose Boring Technology (2015)

#188

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

10 years since the original and it feels like one of the go-to de-facto standard technology choices in many organizations. So I suppose it doesn't cost an innovation token anymore, but that doesn't mean you should just use it - there are many factors to consider when picking a technology.

Re: Choose Boring Technology (2015)

#189

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.

Yeah, compared to most other languages there's a lot of moving parts and activity in the space still - npm vs pnpm vs yarn, node vs bun vs deno, eslint / prettier vs biome vs oxlint, and that's before even writing a single line of code.

Boring in comparison would be Go where a lot of things are standardized. You still get some non-boring in choosing what libraries to use (if applicable) but generally it's a very dull language/ecosystem.

Re: Choose Boring Technology (2015)

#190

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.

10 years ago though

Some wounds never heal. Like Angular 1->2.
Post reply on HN