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

51–60 of 137 posts

Re: Choose Boring Technology (2018)

#51

Post by jpgvm »

joshuahutt wrote: post #44
LAC-Tech wrote: post #19

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…

Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.

This is almost never a bad thing. It means you have fewer people to compete with when advertising a position and the people that use a niche technology generally have more passion for their craft.

Re: Choose Boring Technology (2018)

#52

Post by photonbeam »

joshuahutt wrote: post #44
LAC-Tech wrote: post #19

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…

Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.

You might get less volume, but you can use this as an advantage

Re: Choose Boring Technology (2018)

#53

Post by threeseed »

simonw wrote: post #43
threeseed wrote: post #38

Earlier quoted context omitted.

There are many aspects of PostgreSQL which are not solved problems e.g. clustering, replication, high-availability. And will remain unsolved whilst they are not part of the core products. Because everyone comes up with different solutions which change over time. Citus Data which people often recommended didn't exist prior to 2010 and may not exist next year now they've been acquired by Microsoft and conflict with the…

Clustering, replication and high availability may not be easy, but there are thousands of production PostgreSQL instances out there have solved them. That's what makes it boring. Compare solving those problems to solving them with a brand new database engine where you might be one of the first organizations to run at that scale.

> but there are thousands of production PostgreSQL instances out there have solved them

Great. Can you provide the details on exactly how they did that. Ensuring of course that it doesn't rely on anything proprietary e.g. Citus.

Because with every other database I can just go to the officially supported and maintained documentation.

Re: Choose Boring Technology (2018)

#54

Post by dang »

ksec wrote: post #2

Previous Discussions. 367 Comments: https://news.ycombinator.com/item?id=26211721 84 Comments: https://news.ycombinator.com/item?id=31558887

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 2020 (204 comments)

Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments)

Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments)

Choose boring technology - https://news.ycombinator.com/item?id=16677583 - March 2018 (1 comment)

Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)

Re: Choose Boring Technology (2018)

#55

Post by jpgvm »

claytonjy wrote: post #3

Is boring technology even an option in high-velocity fields like ML/AI? I can pick boring databases and boring servers but when it comes to model architectures, model weights, GPUs, serving frameworks, etc. there's been such massive improvements lately that it doesn't feel like anything has settled enough to be "boring". If I need a language model, or an image classifier, or an ASR model, there are older options whic…

The point is to constrain innovation to the areas that you vitally need it.

Say you are building some sort of visual AI startup, say something that does generative AI things with videos.

You would a) use a boring AF web stack b) use ffmpeg and c) don't go and try do a bunch of silly serverless things, d) try use one of the relatively settled model serving platforms if it's viable for you.

Then you can use all of your innovation budget on your model itself, your training infrastructure etc, things that will provide you with a competitive advantage over people trying to do the same thing as you.

Re: Choose Boring Technology (2018)

#56

Post by hiAndrewQuinn »

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 get pretty far in most business lines with Python, JavaScript and SQLite.

You may not get all the way with them, but by the time you have to worry about that you can hire someone else to do so.

That's what I always tell myself.

Re: Choose Boring Technology (2018)

#57

Post by hgomersall »

kyawzazaw wrote: post #24
fnfjfk wrote: post #17

This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly s…

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to b…

Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.

Re: Choose Boring Technology (2018)

#59

Post by jpgvm »

Pannoniae wrote: post #8

While I see how this makes sense, I don't like this. If most people follow this strategy, we will end up with utter stagnation, or even devolution. "Boring" technology also has many hidden costs - most importantly, opportunity costs of not having several times higher productivity due to the warts and quirks of the boring tools. Sure, with enough practice one can work around them but every backwards issue takes a good…

That isn't how any of this works.

We don't get new innovative databases because of small startups deciding they want to roll their own database as part of building their new fangdangled AI thing.

We get new innovative database either by new innovative database companies that rightfully spend their time and effort trying a new idea in the space or out of huge companies with R&D budgets to build such things, like Spanner.

Startups choosing boring tech for everything that isn't their core/critical innovative area should actually accelerate innovation by focussing effort more efficiently.

I do agree that the whole hiring aspect of it is hot garbage though. If Haskell is the best fit for what you are making and is considering boring in your field (say you are doing verification) then it makes perfect sense to use it even if the pool is smaller because a) people that stick to Haskell despite its difficulties probably have more passion for the craft and b) it's way more likely someone that knows Haskell has some exposure to your field, verification in this case.

Same can apply to lots of "niche" languages/tools/etc. Boring is relative to what you are working on.

I build distributed systems primarily. For me boring is Java. I imagine C++ is boring for game devs/GPU folks. etc.

Post reply on HN