Boring Technology Checklist(blog.begin.com)
blog.begin.com
Boring Technology Checklist
https://blog.begin.com/posts/2022-01-27-the-boring-technology-checklist
118 comments
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 because the language is not very popular. Also hiring.
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.
What is this 'Clojure compatibility' of which you speak? Seriously though, Clojure runs on the JVM so the entire Java ecosystem is available. There are ways to run an external process too of course. I can't really think of an example where 'Clojure compatibility' is something we would require people to have thought about.
A simple example is, let's say you're making a small web service. Are you going to use a Clojure framework or a Java framework via JVM compatibility? If you pick a Clojure framework, then all the subsequent choices you have to make, you'll run into the "non boring tech" issues. Has someone already built a GraphQL plugin, a plugin that integrates with the Twitter preview API, etc etc it depends on your project but you'll run into things. If you pick a Java framework, you'll end up running into a bunch of cases where you can't use the "normal solution" for that framework because you're running Clojure.
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.
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.
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.
The answer to that is to just use java interop.
Or even to have some clojure services and some Java ones. And then work toward more clojure over time if there’s good reason to do it.
And the rebuttal is just use Java as it requires less integration.
[deleted]
[deleted]
[deleted]
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. 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.
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.
[deleted]
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 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 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
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
"because Clojure jobs are scarce . . . you actually get a much higher number of applicants <and> 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.
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.
All the points you're saying here are the usual arguments for choosing non-boring technology (I think I've seen this argument essentially verbatim for CL, Haskell, Clojure, Elixir, etc.), which is fine in isolation, but doesn't really fit in a thread about Clojure as boring technology.
From what I heard, Nubank hired a good deal of Elixir developers when they aqui-hired Plataformatec. I suspect having functional programming experience matters more than having concrete Clojure knowledge. It definitely didn't seem to be a problem in this case anyway.
https://medium.com/building-nubank/tech-perspectives-behind-...
https://medium.com/building-nubank/tech-perspectives-behind-...
On the other hand you attract a certain kind of developer with those roles than generic languages.
If you're using your tech stack as a hiring filter, it doesn't count as "Boring Technology".
No I appreciate that - my point is you can get better engineers that you might deserve at your startup by using a language like Clojure to entice them. I know people who work for a good discount if it’s on a tech stack they enjoy and is fairly rare to find.
[deleted]
It almost sounds like you don't believe that developers can learn new languages.
Of course people can learn new languages, but:
- 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.
- 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.
Learning a language is a piece of cake, learning the ecosystem is another matter.
Of course they can learn new languages. But it takes some time to become really proficient in a language. The question is how many languages do you want to support in your company? Because it's not realistic to think that developers will not need to move from project to project. And in fact when things get busy they may need to swap from one project to another and back on the same day. It's not ideal but that's life. The inefficiency of swapping between languages will often outweigh the efficiency of the new language.
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.
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.
If it’s a language I’m not familiar with, I won’t consider applying, so that’s where the story ends in my case. I could be an outlier though…?
The majority of companies want you to be productive on day one.
That's pretty hyperbolic and also seemingly irrelevant. There are enough companies that don't have this expectation and give new engineers the time and space to become familiar with the company before setting any concrete performance goals.
Hiring wasn't in the articles' checklist though ;)
Valid point anyway
Valid point anyway
Hiring more developers is overrated.
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.
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.
It surely does, calls go both ways, and Closure doesn't understand everything introduced on the JVM since Java 8.
Poor students, at least Blue/J.
By the way, I already used Clojure in projects.
Usually I only critic stuff I actually know.
Poor students, at least Blue/J.
By the way, I already used Clojure in projects.
Usually I only critic stuff I actually know.
> 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.
Even universities in India use IntelliJ or Eclipse these days.
I'd agree that clojure fits the boring tag, and that's a good thing. Unfortunately it's also dying. While many old libraries and tools are stable and functional, nothing new is really being created with it. The same couldn't be said for boring technologies like Java or Python.
Being acquired by a bank isn't exactly a bad thing for the language from a longevity perspective.
https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
What about clojurescript?
My rule of thumb when someone says "Language X is dying" is to move on. I don't even use Clojure, and I can immediately come up with https://github.com/logseq/logseq and https://github.com/athensresearch/athens as funded companies making popular new products with Clojure.
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 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.
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.
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.
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.
[deleted]
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!
- 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 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?"
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?"
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.
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.
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.
What is everyone gyrating around at the moment? I haven’t touched front end for about a decade. It was jquery back then.
I started a project with react!
Stripped everything and went back to server side generated pages with sprinkles of jquery!
Funny, there is plenty of Angular money around here for 2022 and later.
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.
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.
> 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.
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.
I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
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.
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.
This article would be enhanced with concrete examples. The "Boring Technology" argument is hard to attack because it's an opinion, an ideal. It's a good ideal, mind you, but it has the problem of being different for each person, even if they're all on the same team looking at the same use case.
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.
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.
I think the flexibility of the ideal is part of what makes it so attractive. "Boring" may mean some pretty cutting-edge technology because your team is so thoroughly steeped in it that they know it back to front.
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.)
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.)
[deleted]
Familiarity
supports popular language runtimes, tools, and idiomatic APIs
experience deploying this technology to production today
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.)
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.)
I was surprised to find this published on begin.com, which offers an app deployment platform based on AWS Lambda. So are Lambda, API Gateway, and friends considered boring now?
Nobody gets fired for choosing IBM, and nobody gets fired for choosing AWS.
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.
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.
Is lambda really that different from any other server technology?
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 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?
Yes. In theory it would be the same but practically there are lots of gotchas. For a simple example, having a calculated cache on startup that five seconds would be fine on a traditional server but not on lambda.
They may not be, but cgi-bin, webservers, and monitoring via grep /var/log/www/*.log are.
You say that, but setting up a LAMP stack from scratch is more involved than just yeeting something onto GCP these days.
On Debian, a LAMP stack should not take more than an hour to set up from scratch.
hello author here! personally find AWS extremely boring, very mature and stable. well known limits, and tradeoffs.
This is fine insofar as it provides a checklist to evaluate if technology is boring, but it rests entirely on "Choose Boring Technologies", which I've never found particularly compelling.
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 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).
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!
The discussion around "boring" technology is an important one. Where to draw the line will be pretty context-dependent. An aerospace firm will put the line here, and a tech startup focusing on a low-risk use case will draw the line somewhere else. And the developers and other stakeholders will be relevant as well. In this context, the checklist at the bottom is interesting food for thought. But I would be wary of relying on it for choices around what technology to adopt, because such decisions will always need to be considered in context. In that sense, the checklist feels well-meaning and even insightful, but a little too concrete.
In aerospace engineering you would usually select technologies based on a concept of technology readiness level, which provides a framework for evaluating new technology and make sure you are in control of their maturity.
https://en.wikipedia.org/wiki/Technology_readiness_level
https://en.wikipedia.org/wiki/Technology_readiness_level
Interesting to see a few posts on HN recently advocating for 'dumb' or 'boring' tech as I'd been writing an article on 'dumb technology' along the same lines. Comments welcome. https://www.researchgate.net/publication/358248465_Dumb_Tech...
I feel like I've spent the last 10 years seeing "boring" in headlines and thinking mundane, when actually it was referring to tunneling. Now I'm finally conditioned to think tunneling first, and this.
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.
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.
I think F# meets all of the checklist items for me. I'm still not going to consider it boring as it's too esoteric.
Hey OP or mods, could you please update this link
Dunno where the staging server came from
https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
Dunno where the staging server came from
https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
Ok, changed from https://blog.staging.begin.com/posts/2022-01-27-the-boring-t.... Thanks!
I'm years out of date on this stuff, but I note the staging URL has found its way into Google as well, you might be able to fix that up by adjusting the <link rel="canonical" href="https://blog.staging.begin.com/..." /> to point to the authoritative URL even when the page is on the staging server.
Whelp, I'm an idiot for copying the wrong url. I don't seem to be able to edit the url, only the title.
I think commentators are missing that a big part of boring technology is, well, that it's boring. If developers are excited to use that technology, instead of just thinking "meh just another one of those companies using X" then it's probably not boring.
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.
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.
A boring technology is one with which a large number of developers have previous production experience with. Or probably even "of the developers you can realistically expect to hire".
Better yet, hire developers who enjoy and excel at selecting and utilizing emerging technologies that will be a better long-term fit for the problem at hand. This is of course more difficult, but makes for a better team and product. I want my competitors to be afraid of technology and to de-prioritize hiring generalists.
If the ability to keep the site up is any indication, it looks like boring tech does not work as well in practice as the theory would have you believe.
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.
Hate to agree, but yes. A C++ application using the APIs provided by Windows is pretty much unbreakable by time.
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.
What about between 2 boring technologies?
For example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)
For example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)
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. I'm unaffiliated w the project, but I've been doing web-related things for a living since 1998, and for me Remix is a breath of fresh air and the successor to NextJS as my framework of choice.
> 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.
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.
The fact you worry about what language they're written in - while you shouldn't need to ever edit any of their code - already implies they're not boring and you're overthinking the decision already.
Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
In principle you’re absolutely right, but Hugo actually comes with lots of strings attached due to their choice of Go, like having to use Go templates for example - which can be weird if you don’t have a Go background. The more elaborate constructs you’re trying to build, the more you need to research how the Hugo Go runtime works to sort out quirks.
Flip a coin, try the first one out, and if anything pops up in a few days that makes you think the other might be more suitable, evaluate the other one.
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.
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.
I do this. But 1d20 / options. Crit fail means ignore for a week otherwise divide up the space evenly and extra slots mean re-roll. Having the option to punt is useful.
This a good advice for dealing with 'decision paralysis' which can make you waste more time than just trying out the options.
Good advice thanks
Compare them in your particular scenario. Only you know what is important to you. If choosing for a company, ask the people who will have to work with it.
Maybe one has more responsive developers, or a more helpful community.
Maybe one has more responsive developers, or a more helpful community.
Boring is on a scale, and you need a reference to assess the level of boringness. Eleventy, Hugo and Jekyll are all a little to non-boring compared to ssg6 or just throwing txt files in www-root.
The truly boring choice for your blog is PHP and/or Perl. Wordpress, Movable Type, or possibly Textpattern if you are feeling a little edgy.
I wonder, how many engineers will switch their jobs because they have to work with boring tech?
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.
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.
> 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.
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.
Sure, that's the best case scenario.
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.
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.
I've worked at companies where many of the devs were not remotely excited about any new technologies and just wanted to do their 9-5 and get home to the wife and kids, which is a totally valid career choice. These guys just wanted to stick with what worked and what they knew. They LOVED boring.
A lot of this boring technology talk just seems like an excuse not to learn something new.
"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.
"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.
One day, if we wait long enough, The Boring Company technology will be boring technology.
"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.
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".
I don't consider it my job to do the same thing in the same way to accomplish the same thing.
[deleted]
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).