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

231–240 of 269 posts

Re: Choose Boring Technology (2015)

#231

Post by insanitybit »

dyauspitr wrote: post #161
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.

That has nothing to do with anything.

Re: Choose Boring Technology (2015)

#232

Post by silvestrov »

thelastgallon wrote: post #225

2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need. This will run with 99.99% uptime, 4-hour warranty from Dell/HPE (failover to the other server). Is also somewhat vertically scalable (upgrade RAM/SSD). Kids who finish high school can be taught to own and run this. But .... if you run a multi cloud hybrid setup with kubernetes, service mesh…

In the old days 25 years ago, x86 hardware was the main source of unreliability.

Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.

Re: Choose Boring Technology (2015)

#233

Post by insanitybit »

frrlpp wrote: post #118
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.

I'm not, the post is what adds fog to what should be clear and direct conversations about technical solutions as per their ability to solve a product concern.

Re: Choose Boring Technology (2015)

#234

Post by gwbas1c »

Regarding "Optimize Globally"

At my current job we generally use LINQpad for scripting, and have a lot of tests that use LINQPad scripts.

When I joined, there was a test that relied on an "R" script. Now, "R" might be the best tool for the job, but no one running the test would ever have any "R" experience. In addition, the environment to run "R" has quite the learning curve.

I ported the script to LINQPad. The fact that no one needs to install "R" or figure out how to run "R" is a much more massive timesaver than the fact that "R" was technically better for that one task. (And the script itself is pretty straightforward.)

Re: Choose Boring Technology (2015)

#235

Post by mexicocitinluez »

wink wrote: post #230
mexicocitinluez wrote: post #216

Earlier quoted context omitted.

Not a fan of the phrase "CV driven development". It's a great example of a fundamental attribution error. In my experience, people choose the wrong tech for a handful of reasons, last of which is to further their career. Using that phrase also implies that the author's intentions are pure but others aren't. As if you have insight into what motivates them.

"architecture by reading blog posts" is as an old boss of mine described it and I liked that better.

That lines up with my experience.

What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.

I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.

Re: Choose Boring Technology (2015)

#236

Post by davnicwil »

I wonder how much of this universal lesson will be rehashed to fit the aftermath of what's currently going on with vibe coding etc.

I think it's pretty likely that in, let's just go for the round number and say 80% of cases, everyone will conclude that just existing well used frameworks / code generator templates where everything's understood and most of the hot paths are well tested is pretty fast to build with (and more importantly, maintain and operate) and was really all we needed for most useful business software.

Re: Choose Boring Technology (2015)

#237

Post by duckmysick »

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…

So what's your technology stack? Which criteria did you use when choosing it instead?

Re: Choose Boring Technology (2015)

#238

Post by insanitybit »

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

So what's your technology stack? Which criteria did you use when choosing it instead?

I don't have a technology stack. Do you just mean what am I using for current projects?

At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.

We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.

We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.

In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.

Re: Choose Boring Technology (2015)

#239

Post by insanitybit »

jagenabler2 wrote: post #152
insanitybit wrote: post #147

Earlier quoted context omitted.

The point is exactly that - bad decisions happen when your reasoning is based on silly terms like "boring" or "hyped" or whatever. The solution is to discuss the merits of each solution as it pertains to the problem space, which "boring" does not help with (and obfuscates).

While it shouldn't be the absolute guide for every technical decision, it helps to have abstractions to capture the intuition and years of experience that goes into choosing a solution. It can make the discussions smoother. When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean bet…

> When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.

I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.

> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.

It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.

Re: Choose Boring Technology (2015)

#240

Post by hahahaa »

Cthulhu_ wrote: post #198
hahahaa wrote: post #106

Earlier quoted context omitted.

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

I mean popular as in by actual usage rather than emotion/hype. It is usually boring that is popular from what I see.

Agree about LLM not choosing tech. Although that could mean dictating upfront or let it choose then review/steer.

Post reply on HN