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

Boring Technology Checklist

blog.begin.com

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Boring Technology Checklist

#101

Post by [deleted] »

lmilcin wrote: post #70
TacticalCoder wrote: post #8

Weirdly enough I do believe Clojure ticks the boxes from that checklist. It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time. It's incredibly stable: so stable some libraries commonly used haven't been updated in years . There's also very little code churn ins…

The problem with Clojure is that it is too good. It gives you, the programmer, too much freedom. Most people do not have problems that require so much freedom. Most people do not know what to do with that freedom -- they don't have enough experience actually organising their applications. Most people benefit from using a language/framework that requires them or at least rewards them to put things in a certain way. Fo…

[deleted]

Re: Boring Technology Checklist

#102

Post by [deleted] »

heipei wrote: post #67

Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks. Example: React is great for starting with smaller and/or progressively…

[deleted]

Re: Boring Technology Checklist

#103

Post by antod »

hughrr wrote: post #55

Please also add ”doesn’t auto close three million ignored GitHub tickets” every week, the true quality metric these days.

Well, they were boring tickets in the CADT sense.

Seriously though, probably the difference being a boring project and being a bored project.

Re: Boring Technology Checklist

#104

Post by ape4 »

mixmastamyk wrote: post #48
ape4 wrote: post #29

I hate to say it, but in many ways Windows checks many boxes - its backwards compatible for decades. Programs from 30 years ago still work fine.

The core is fine, it’s being at the whim of MS’s hostile marketing and sales departments that are decidedly not boring.

The ads in the start menu were a low but it's very cool how everything keeps working And I love Linux.

Re: Boring Technology Checklist

#105

Post by abernard1 »

wyager wrote: post #57

> friendly community (Code of Conduct, blogs, chats, podcasts, etc.) In my experience, most of these things negatively correlate with stuff I actually want (like software quality or stability). It indicates a software ecosystem that exists mostly as an ersatz social outlet for a certain kind of person. The best softwares I use tend to have none of this stuff - maybe just a mailing list and a bug tracker.

Amen. An abundance of these things signal (to me) developers concerned with themselves, not the technology.

People in this scene are going to be the first to switch languages/frameworks or introduce drama into what should otherwise be pedestrian problem solving exercises.

And on a more concrete note, when it's 3AM and your pagerduty is lit up like a Christmas tree, are blogs, chats, podcasts what you're interested in? No way! You want cold hard documentation and crusty "tell-it-like-it-is" engineers or consultants. They're seldom bubbly, but they command respect and get it done.

Re: Boring Technology Checklist

#106

Post by tptacek »

This seems mostly like a rhetorical way to launder non-boring technology into boring shops. There's nothing on this checklist than an "exciting" new database couldn't have right out of the gate. Like, put something like "doesn't use Raft" in the checklist!

Re: Boring Technology Checklist

#107

Post by chrisweekly »

Zababa wrote: post #40
chrisweekly wrote: post #25

Earlier quoted context omitted.

Before you spend much time on a pure (thus limited) SSG, I recommend taking a close look at https://Remix.run . Remix supports a superset of Eleventy or Hugo (or Jekyll or even NextJS export). It's too new to be considered "boring", but it leverages OG web standards and defaults to web platform-native foundations. Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul.…

> Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. That's what people said for Redwood.js. One year later and it's mostly forgotten.

So? "People" may have said all kinds of things about Redwood or the price of rice in China. I never promoted Redwood, and (to engage with your off-base "rejoinder") objectively speaking, it didn't offer any advantages over NextJS. Remix, on the other hand, is fundamentally different from any other framework.

Re: Boring Technology Checklist

#108

Post by mchusma »

miiiiiike wrote: post #44
lmeyerov wrote: post #7

Missing two of the biggest: - hireability: large community of developers to hire from today + years from now - low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts Not easy for startups and new frameworks to achieve 'boring' status!

This is where Angular dies. Great framework. There's almost no amount of money that you can pay someone to learn Angular in 2022.

Ah, the old Angular bashing. I don't get it. Meanwhile, it keeps steadily improving and working well for many teams. We really enjoy working with it.

Re: Boring Technology Checklist

#109

Post by lmeyerov »

wyager wrote: post #58
lmeyerov wrote: post #7

Missing two of the biggest: - hireability: large community of developers to hire from today + years from now - low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts Not easy for startups and new frameworks to achieve 'boring' status!

> large community of developers to hire from today + years from now I think this is a red herring. The thing that actually matters for most companies is marginal hireability. By the time you're big enough to worry about absolute hireability (because your hiring demands exceed the liquidity at the margins) you can create a hiring pool out of thin air (e.g. if google invents a new language and shills it a bit, tens of…

No, it is, how hard is it to hire 3 elixer devs at given quality and do an elastic sprint as 6.. 3 years from now. And what is the chance the dependency chain hasn't rotted.

The million means you arent scrambling . Hiring in niche stuff even for 1 person stinks. Replacing/maintaining dead frameworks is 10x+ worse than writing the original.

When you can find and just drop someone in the same/next week and it's not all cruft... And you're sure that'll be true next year too... That's boring code. Super destressor for everyone as folks can easily scale up / down, take paternal leave, onboard junior /senior folks same-day, etc, and not worry about ecosystem churn.

Ex: It's a world of diff when we hire folks to write our django pieces vs GLSL engine, and both of those ecosystems are big. Just django is the way bigger and thus more stress free. When you go down to niche langs with niche frameworks.. unless there is a good reason, I don't want to be in that company nor bet on it 2-4yr from now. For us, we do GPU everything, so careful parts of our stack are weird and constant careful effort, and we try to limit it to just those.

Re: Boring Technology Checklist

#110

Post by perrygeo »

heipei wrote: post #67

Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks. Example: React is great for starting with smaller and/or progressively…

Exactly. Choose boring technology, but more importantly choose technology that works within your org and keep it consistent.

Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk.

If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.

Post reply on HN