Boring Technology Checklist
blog.begin.com
blog.begin.com
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 inside Clojure's own codebase.
It is very reliable.
It's limits and trade offs are well known.
Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).
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 because the language is not very popular. Also hiring.
It's not the end of the world or anything, and for a smaller project Clojure might be the perfect solution. But if it's something that you're trying to scale into a startup with dozens of engineers then you're probably going to pay a higher incompatibility cost for using Clojure.
The answer to that is to just use java interop.
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. For example Java Spring rewards people for following a certain application design -- you can break rules but then you are on your own and Stack[Exchange|Overflow] examples can no longer be copied/pasted directly into your codebase.
As much as I love Clojure, every single corporate Clojure project I have seen in the past was an utterly unmaintainable mess.
I have never actually participated in a Clojure project (I use Clojure mostly for rapid prototyping/PoC-ing), but what I figured is that Clojure requires minimum maturity from the developer and especially drive to be constantly simplifying things -- which is unfortunately very high bar. Most developers I work with / interviewed do not really understand what it means to refactor and simplify. Most people are only focused on the part of the work when they get something to produce expected values and everything else just isn't high priority in a corporate environment.
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.
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 that level of language-detail tend to be meticulous about many other useful things, like choosing the right tools and building simple and maintainable applications.
There's sometimes a slight tendency towards over-engineering which is understandable. People who dive deep into other programming languages and go through the pain of learning lisp sometimes tend to lose focus of the actual (business) problem to solve. But I wouldn't say this tendency is significantly higher than elsewhere. Still, sometimes, the pragmatism of a rails dev just churning out code is missed.
Also, because Clojure jobs are scarce and there's a high number of "secret Clojurists" (people who code Clojure at night and secretly dream of using it at their day job), you actually get a much higher number of applicants than you would have estimated based on the most recent Stackoverflow survey.
Also, you get a real shot at hiring rockstar devs. This is huge and cannot be overstated. If you're hiring for a standard JS / Python stack, you're suddenly competing with FAANG companies and their salaries. If you're hiring for Clojure, you're hardly competing with anyone. And you get a good pre-selection of senior devs. Like, those which were burned at a FAANG company, who finally came to their senses and now want to code Clojure. What's not to like?
I guess a drawback would be that you couldn't instantly hire a local team of 100+ devs, even if you take secret Clojurists into account. But who would want to work at a place which hires 100+ devs in a short amount of time?
(I interviewed around 200 people, many of them for Clojure roles, sometimes even comparing Python and Clojure applicants for the same role)
Relevant talk: https://youtu.be/kNiGu_VaoTg?t=1566
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.
https://medium.com/building-nubank/tech-perspectives-behind-...
- A nonzero number of excellent potential applicants aren't going to work for your company because they don't want to invest their own development into learning the Clojure ecosystem deeply. (This might be somewhat balanced out by folks who are stoked to learn Clojure.)
- Every non-Clojure person you hire will require significantly more ramp-up time. This can be a real problem for small companies where you lose quite a lot of expertise every time a senior developer leaves.
- These problems compound for every "innovative" technology you add.
Google were notoriously strict for limiting languages at the start and I think it was very frustrating for some of the developers they hired. If I had a boring technology checklist then "Language we already use" would be top of the list.
Valid point anyway
Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.
Poor students, at least Blue/J.
By the way, I already used Clojure in projects.
Usually I only critic stuff I actually know.
Even universities in India use IntelliJ or Eclipse these days.
https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice.
Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.
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.
- 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!
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 thousands of college students will learn it for free).
If you're a small company and you're picking between Java and Elixir (or whatever) your concern should be "how hard will it be to hire 3 developers at a given quality level?", not "are there 1 million developers available?"
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.
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.
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.
I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
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.
Another good extension to the topic would also be defining when Boring Technology becomes Ancient Technology. You need to hit that middle of the tech curve where it's understood and stable but also still being maintained and keeping up with modern needs.
For me, "boring" means avoiding things like Kubernetes because it's an ecosystem with which I am woefully unfamiliar and I can more or less achieve with other (possibly less efficient) means.
Ted Dziuba made a point a while back that the three tools for systems engineering are money, time, and code, and they should be used in that order. It's a sort of shorthand for "boring" to just buy a bigger server, or spend the time to leverage existing and know Unix tools, and then if all that fails, use some gimcrack new tech to solve your problems.
(Though, I'd say that the biggest impediment to leveraging "boring" technologies is correctly determining what your problem is. Sometimes we focus on the wrong metrics, or the right metrics at the wrong time, and that skews our decision making.)
Stability follows a predictable release and versioning scheme (note: NOT frequent is fine and in some ways more desirable. security patches are always welcome of course.) biases for non-breaking changes easing long term maintainability publishes a regular changelog open-source and/or open-source backed service ideally public governance: roadmap, issue tracking, and decision making all visible
Reliability can be trusted to work as expected; ideally does one thing well social proofs exist (careful!)
Well understood limits, and trade-offs accessible docs objective benchmarks and/or published service quotas friendly community (Code of Conduct, blogs, chats, podcasts, etc.)
The corollary that's missing, of course, is that they often should get fired—but popular (sorry, "boring") choices have a momentum of their own.
It’s just a container that you have to boot and it handles web requests, right?
They boot fast, so for a low traffic site you can worry less about cold start, is there any other difference with any other containerized web server?
It's less "Choose Boring Technologies" and more "Don't introduce something new just because it's new". Have a compelling reason. And both this article, and the original Choose Boring Technologies, kinda miss that.
I'd be much more interested in guidelines of when to choose something new; a prior job prior to my joining chose Erlang for a mid-sized project, despite no one on the team knowing it, and it was a success. So we chose it (after I joined) for a large project, and it was, to quote the executive of a business unit it was for "the biggest success to come out of (our department)".
Both of these projects -could- have been done in one of the existing house languages...they would not have been done as quickly, resulted in nearly as good an outcome (predominantly amongst resiliency, which is why we chose Erlang), nor have given the team as much enjoyment (itself being part of the reason for the results, as a knock on effect).
It's like BLM, whether I think Black Lives Matter or Bureau of Land Management, the reference is bound to be about the other one, sure as the the USB is always backwards.
Seriously though, probably the difference being a boring project and being a bored project.
Dunno where the staging server came from
https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
If your technology gets developers excited then it's not boring.
As per the original article that introduced the term, that doesn't mean that it's a priori a bad thing, but it does mean that the bar for the other things it brings to the table needs to be higher and that most startups only get a limited number of technologies to be excited about.
So, not ElasticSearch.
For example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)
That's what people said for Redwood.js. One year later and it's mostly forgotten.
Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
I recently started experimenting with Snowpack for JS build. I realized it doesn’t do sourcemaps very will so I grabbed Parcel. That worked great but doesn’t have a testing story and Vite has a couple options there. Vite has been good.
It was work to evaluate each of those and switch between them. But not that much work really since I hadn’t committed a huge codebase yet. But it was worth it because now I know why you might choose one over the other.
Granted the “boring” choice would be Webpack.
Maybe one has more responsive developers, or a more helpful community.
Sure, the stack you're using isn't everything and other parts of a project can be just as exciting. But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.
This is becoming my go-to filter for determining if I would want to hire someone in the first place. Hypothetically, if someone told me they left their prior job because they wanted to "use cool tech" on an interview, I would be providing a strong "No" input to the process.
The honest reality is that a lot of people are doing a job they probably should not be doing. If you want to be really good at writing software for other people, you should enjoy delivering experiences to your actual users. I find many developers can't even enumerate who their end users are these days.
In my experience companies, especially the small ones, struggle to hire engineers. So, they try to spice their positions up with some hot new tech.
"X works fine why are we using Y?" "See Y doesn't cover every X use case perfectly, we should have stuck with X!"
The arguments are predictable at this point. We'd still be using Jquery for developing frontends if this mindset was pervasive.
Tech can and does frequently get worse. All you have to do is keep adding features indescriminately or let code with external dependencies rot.