Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2018)

boringtechnology.club

Post reply on HN
Print view View original

121–130 of 137 posts

Re: Choose Boring Technology (2018)

#121

Post by eddmakesio »

appplication wrote: post #116
eddmakesio wrote: post #104

Earlier quoted context omitted.

> todays tech landscape is far less edgy Writing an app in a microservice architecture with services in Rust, Go, and Nim. Database is a serverless DB like Planetscale. Front end in HTMX. Etc… I think any tech your team is not already familiar with, and isn’t the standard pick, is an innovation token.

So I agree 100% with this, but postgres is so easy and scales infinitely (for the meaning of infinite in 99% of business use cases), I suppose I don’t understand why I would choose MySQL. Do folks just use it as a user cache? Most systems I’ve designed of worked on have required a central database so MySQL never seemed the right fit.

I'm not sure tbh! I also agree with PostgreSQL. The last time I used MySQL was MariaDB in 2015/6 or something.

Re: Choose Boring Technology (2018)

#122

Post by dang »

ChrisArchitect wrote: post #71
dang wrote: post #54

Earlier quoted context omitted.

Thanks! Macroexpanded: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=31558887 - May 2022 (83 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 - Dec 20…

(2015) up top

The linked page seemed to be a talk from 2018, not the essay from 2015, so I used that year.

If that's wrong, we can correct.

Re: Choose Boring Technology (2018)

#123

Post by MichaelMoser123 »

em-bee wrote: post #73
MichaelMoser123 wrote: post #39

and who defines what is boring?

boring is what you already know and don't need to spend a lot of time learning, or, if you don't know any, then it's what is widely known and well documented.

Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases.

Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter)

Also look at all the changes and action in the JDK (ever since JDK11). Is that also boring?

Re: Choose Boring Technology (2018)

#124

Post by em-bee »

MichaelMoser123 wrote: post #123
em-bee wrote: post #73

Earlier quoted context omitted.

boring is what you already know and don't need to spend a lot of time learning, or, if you don't know any, then it's what is widely known and well documented.

Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter) Also look…

I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases.

yes, that is true but i think that supports the point: use boring tech to solve interesting problems.

Re: Choose Boring Technology (2018)

#125

Post by crabbone »

JambalayaJim wrote: post #119
crabbone wrote: post #105

Earlier quoted context omitted.

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws. Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtuall…

NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place. NPE issues are also very very difficult to chase down.

I'm talking about QA, not end-users.

"very very difficult" on what scale? How many "verys" before it gets really hard?

Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable.

Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit.

And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.

Re: Choose Boring Technology (2018)

#126

Post by chucke »

strken wrote: post #66
mikece wrote: post #11

The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (o…

You can make bad technology choices today. For example, if you were using Typescript to build a mobile app, you might be tempted to use TypeORM (32k stars on GitHub, been around since 2016, widely used). If you wanted to also use transactions and concurrency then this would be a mistake, because you would quickly find that TypeORM's SQLite adapter doesn't have a connection pool or locking for transactions, and will h…

And I never heard of TypeORM until now, which means that it's not boring tech in my eyes. I find it hard to classify anything in the node world as boring, considering the infamous churn rate. Popular yes, boring no.

Re: Choose Boring Technology (2018)

#127

Post by gfodor »

Pannoniae wrote: post #32
gfodor wrote: post #14

Earlier quoted context omitted.

The talk doesn’t say to always choose boring technology. But you might think it does if you read three words and wrote a comment in response to them.

This was the second time I've read that talk. Please don't accuse me of not reading it. As all of us, it might be that I completely overlook, or interpret something entirely differently or outright wrongly, but I think this is entirely uncalled for. Edit: I kind of see what you mean now. My paragraph about hiring was somewhat tangential. I am sorry.

No worries!

Re: Choose Boring Technology (2018)

#128

Post by gfodor »

avindroth wrote: post #45
gfodor wrote: post #13

Earlier quoted context omitted.

It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.

Well, this is just clickbait. Choose boring technology means sth pretty concrete for someone without context. It’s not that you can’t reasonably title it. It’s that you can’t reasonably title it to generate views. I understand the sentiment, but then one should expect criticism of the schism between title and content.

"Clickbait" has been apparently watered down to the point of meaninglessness then. You title things to get people to want to read them if you're sharing information you think is important. The term "clickbait" is typically used to refer to false and misleading titles to generate ad revenue for garbage content.

Re: Choose Boring Technology (2018)

#129

Post by ed_blackburn »

klabb3 wrote: post #112
ed_blackburn wrote: post #72

I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to in…

> It's a Python monolith > flaky third parties Seems contradictory. What are the third parties used for?

I’m not referring to third party libraries. Rather third-party data providers.

Re: Choose Boring Technology (2018)

#130

Post by eternityforest »

mikece wrote: post #11

The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (o…

Blockchains, making your own JS framework/language/static site generator/MQTT alternative/etc, building a desktop GUI toolkit, making your own VCS, retro hipster type stuff like handwriting HTML with no templates or JS, or using Linux without some kind of configuration management system...
Post reply on HN