Live data from Hacker News

Boring Technology Checklist

blog.begin.com

111–119 of 119 posts

Re: Boring Technology Checklist

#111
post #35

Earlier quoted context omitted.

I like Clojure, but it's really the exact opposite of the sort of "boring technology" that this post advocates. If MongoDB costs you 2 innovation tokens, Clojure costs at least 2, perhaps all 3. The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just becau…

you will want to integrate with more and more things that have not put effort into Clojure compatibility The answer to that is to just use java interop.

And the rebuttal is just use Java as it requires less integration.

Re: Boring Technology Checklist

#113

"All technology will change and improve with time" Tech can and does frequently get worse. All you have to do is keep adding features indescriminately or let code with external dependencies rot.

Which is to say that I have experienced boring tech in our stack get worse and cost an unexpected "innovation token".

Re: Boring Technology Checklist

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

Funny, there is plenty of Angular money around here for 2022 and later.

Re: Boring Technology Checklist

#115
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!

The metric I use is "StackOverflowability".

It's 2am and I am desperate to fix a customers problem. What's the chance of me finding the answer on SO? Good documentation is obviously helpful, but SO expresses knowledge in a Q&A format much better.

Re: Boring Technology Checklist

#116
post #63

Earlier quoted context omitted.

Nope, boring technology is using the platform system language, Java. Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.

Clojure doesn't need FFI, neither does it need anything to run but the JVM, you package your application in a jar and run it the same as always, and you only write Java using your system editor and the JDK in introductory compsci courses.

> you only write Java using your system editor and the JDK in introductory compsci courses.

Even universities in India use IntelliJ or Eclipse these days.

Re: Boring Technology Checklist

#117
post #81
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.

Yeah, boring technology requires boring owners to ensure that stuff like Python 3 wont happen.

So one (albeit large) backward compatibility break every few decades is too much?

I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.

Re: Boring Technology Checklist

#119

Earlier quoted context omitted.

How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect? When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.

When hiring / recruiting Clojure devs, there are quite a few second-order effects which are quite unintuitive. Clojure devs are much more senior - they've typically been burnt by at least one tech stack, often more (Java, JS + React, Fortran, Cobol, punching tape, etc.). Clojure devs also tend to be really passionate about, you guessed it, Clojure, which commonly turns out to be a good thing. People passionate about…

"because Clojure jobs are scarce . . . you actually get a much higher number of applicants you get a real shot at hiring rockstar devs"

I have felt this to be true for many years. I was an early Clojure adopter, deployed Clojure apps into production shortly after attending the very first Clojure/conj, and did quite a bit of hackerrank and similar competitive programming exercises with Clojure for fun and learning.

I didn't have much luck getting job offers for Clojure positions but was mostly successful in getting job offers for other tech stacks during that same time. It was kind of funny to me - I really wanted to move to a Clojure-only shop but kept getting offers for SQL and Java/C# positions despite not really being an enterprise dev type.

Post reply on HN