Choose Exciting Technology
lucjan.medium.com
lucjan.medium.com
Choosing exciting can be a tech-debt, or it can remove tech debt. Boring can be stable, but can be soul-crushing.
Exciting & Boring is not mutually exclusive. They can co-exist. Engineer excitement and Business continuation must be kept in balance.
Generalization is not helpful. As an engineer or business, or in general a sensible person, you must always do pros and cons without bias.
Thanks for comimng to my TED Talk.
Yeah the confusion is caused by people meaning stable & tested when they say boring, as they find most of the stuff that excites people not suitable for production use. There's still a lot remaining though, when you filter out the unstable and untested stuff.
I strongly agree with this.
A formula 1 car is certainly reliable, and certainly exciting to drive.
Are programmers children that we need to entertain in order for them to do their job?
Not it is not. Knowing you can get a better job elsewhere and therefore going elsewhere is not entitlement. Thinking that workers who are unhappy and can get a better job elsewhere shouldn't leave is entitlement.
Why is entitled to act like you owe nothing to your employer when they would fire you on the drop of a hat if it made them more money?
The alternative to this is offering more money, which isn’t even guaranteed to work.
So the point is, you will brain drain your company if you don't make developers happy.
I was initially gonna say "Good" in place of "confident/ well informed", but I'm sure some developers who are good simply don't know there are better places out for them.
Are you my old manager?
They need to be pampered because they have high mobility.
That's what made me react so strongly to this comment. I think we should have more gratitude for our privilege.
The company hired you because you make them money. As soon as the company feels you are a bad deal they will fire you. Why shouldn't you do the same to them? Feeling gratitude about a shitty job will just make shitty jobs more common, that isn't good for anyone.
Of course we should be respectful and strive to do our best and provide value commensurate with our compensation. But if the market is such that people can take a pick and go to companies that let them have more fun while doing so, I think that’s great. It’s a pretty calvinistic mindset to see it otherwise.
The decision to "coddle" and "engage" engineers is made by companies. It's their choice, and their strategy. I would even argue that this is not even close to what engineers prefer: most would definitely choose a raise, or decreased number of hours over the "happiness" thing.
This is true, but I feel misses the mark a little.
The absolute best development job I've had in my 15 odd years of experience was my first job. It wasn't about the technology. What I was using there was completely new to me, down to the text editor and keyboard (vim + Microsoft Natural ergonomic, you should have seen me struggling to do anything learning both at once). It wasn't about the pay. The company was paying an embarrassingly low rate because they were one of two companies in town hiring developers. It wasn't because we had a fancy office or a stocked pantry or beer on tap. We had none of that.
No. It was entirely because of the people I worked with. We would all play World of Warcraft after hours. We would joke around at work during the day and eat lunch together.
That's it. That's the entire secret to a happy job. And you can't bottle that magic sauce up and sell it at trade shows and conferences. You can't write a book on it. Because it's situational. If you've ever worked at a place like that, then you know what I'm talking about. It has little to do with the company. In fact, the CEO was a bit of a narcissistic slimey toad.
Businesses spend a fortune trying to force such an environment through cargo cult. "If we provide X, then developers will show up and work all night." So every company is a "campus" that resembles a college dorm environment. And it all falls flat and infantile. Because we are adults and see it as the pandering it is.
It's not like physical work where you can just keep doing it and it'll resolve itself eventually; it is entirely possible to keep hitting your head against an engineering problem forever without making any progress if your brain just refuses to make the correct connections, and it's really difficult to tell if you're making progress or not.
In general, all people deserve to be kept happy, so removing barriers to happiness is nearly always a good thing.
Multiple factors can satisfy you. Pay is one of them. Some engineers can also take less pay in exchange for use of shiny tech because boring tech can be very demaning. But that's not always the case.
In either case, one need to be happy with job to continue right? Or else one can find another job if they are not happy with pay, organization, food, location, ethics, abuse etc. It's not 1-dimensional.
Are you honestly asking why people who happen to have a profession need to be happy?
And what's this idea that happiness is something that is only desirable in children? Do you honestly believe everyone should be cursed to die inside once they enter adulthood?
A healthy society is a society where happiness is not an abnormality, but the norm.
"Engineers need to be kept happy."
This is a statement rooted in fear - that if you don't entertain programmers with things that they enjoy, they will leave. Does that not sound like how you'd approach a child who you fear will have a tantrum if you don't give them a lollipop?
I'm saying, programmers also need to take pride and satisfaction in the contribution they make to a business. Focusing on the business outcomes that you contribute to is more satisfying than getting to use React at work, or whatever it is you think will keep you "happy."
I'm talking specifically about the idea that programmers conflate tech stacks with happiness, not happiness in general. I would hope that was clear.
Does that mean that the business should allow developers to indulge in whatever resume-driven development decisions they feel like lest they burst into tears? No. There are various comments in the thread about people who get bored after a few months because they have to do code maintenance.
There is nothing wrong with getting bored by maintenance work. If you have that kind of work then hire boring engineers who will do whatever as long as you give them money, but don't say that all engineers needs to be happy with that kind of work.
This is not a matter of "entertaining" engineers. This is a problem of providing good or even decent working conditions. High stress and high churn work environments have high attrition, because when given a choice adults prefer not to be miserable.
You're pretending that this issue is all about pampering when at it's core there are poor work environments that needlessly cause mental problems, some of them permanent.
Are we supposed to pretend that there was at least one FANG, supposedly a group of companies known for being generous to it's employees, which a few years ago was known for having employees crying at their desks?
Turnover is expensive, employee retention is a generally important goal for successful companies.
Happiness and entertainment are not the same thing. Most of us spend a huge portion of our life working, we might as well try to make it at least a little bit fulfilling instead of just a way to fund the two days of the week when you can do something else.
And more cynically happy people will almost certainly work better. Have you never taken much more time than necessary to complete a task just because it was so incredibly dull, tedious and uninteresting? Bugtrackers are filled with issues that would require two lines of code to fix but nobody can be bothered to write them.
For me, a job has to be reciprocal. I take my salary very seriously, and I reflect on what I've done in the past pay period. I want to make sure that I've provided that amount of value in that amount of time. Of course my feelings are important, I'm not going to contribute to an environment that doesn't reciprocate the value that I provide with some combination of compensation and gratitude.
My point is, I hear a lot of programmers talk about the feelings of the business with disdain, and frankly complete entitlement. I've seen plenty of engineers not contribute their fair share value to the business side - they think they earn their living by showing up and completing a couple of tickets a week, when in reality the business needs are much more demanding. The ideal working relationship is reciprocal - both parties get some satisfying bit of value out of it.
That was just your interpretation. The parent commenter said that some engineers are motivated by money and some by new tech. Either way you need to keep workers happy or they will leave, that is just common sense. So if you choose boring technology you will get people motivated by money and not the "infant" engineers who "need toys" as you say. But really they don't "need" the toys, they just prefer it and will therefore leave if someone else gives them that when you don't.
If programmers can act with “complete entitlement” sometimes it’s only because they are some of the few workers who can demand something from their jobs, even without a union backing them. Most workers do not have that privilege/leverage.
Also, happy people just produce better results. Especially if the way for them to achieve happiness is the route to better results. If you just want your coal mined, happiness of your workers may not matter much. As soon as you want quality output from any intellectual worker it will start to matter. (Though I'm pretty sure that it's true for any job with any level of autonomy and creativity needed, even if it's manual labour.)
As long as there is a way to quantify that value, it could be incentivized, boring systems should be the most profitable.
Software Development is that strange split between clear defined engineering aspects and creativity aspects which are often as important.
I have seen major problems in projects due to developers being dissatisfied and annoyed with the tools they can use.
The problem was twofold
- first it was not that they couldn't use the newest exiting tools, but that the tools they had to use had horrible UX making them unnecessary hard to use. Like if you tell someone they have to now turn pages of an book with a fork instead of their hands.
- The other problem was that one person involved had a fixed view about what is good and in their view must be done and nothing else is good and doing something else is always stupid and as such in their view their work is stupid and worthless and as such they don't want to do that at all as it's just a pointless wast of time which will be discarded in the future anyway... Which is quite a bad approach to your job, tbh. And caused some massive problems later on.
All the world's a stage, And all the men and women merely players;
Players stay in the game as long as it is fun.
Simply put, if the job is not enjoyable I'd rather look for an enjoyable job or ask more money until it's worth it.
The market still favours developers and finding a job is pretty easy, so developers have all the incentive to look for a fulfilling position, while it lasts.
Sometimes things break, but in a "good" system, some breakage is expected, and the risk of breakage is not minimized by being fearful of change, but by having monitoring, redundancy and checks in place to keep the change controlled and the impact of faults within agreed boundaries.
>>> npm’s first Rust program hasn't caused any alerts in its year and a half in production. "My biggest compliment to Rust is that it's boring," offered Dickinson, "and this is an amazing compliment." The process of deploying the new Rust service was straightforward, and soon they were able to forget about the Rust service because it caused so few operational issues. At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts
What you and the patent poster said applies to both.
Doing more exciting stuff with older tools is also somewhat more satisfying, at least for me.
After almost a decade, I still find lots of interesting ways to write plain vanilla JS code that makes developer's jobs easier in lots of interesting ways. Before that, I spent a full decade writing C++ using nothing but a restricted set of in-house libraries. I don't recall ever being bored because I always felt like a carpenter: have a problem? You have the tools to build more tools to make your life easier. I experimented with event driven models vs. streams vs. queues, doing complex calculations by spreading them across the nodes of a tree, developing unit and API test tools (C++ had none, many years ago).
Today, architecture feels more like technology shopping than tinkering.
(Note on the side I've made weekend projects in Rust, tested Cassandra, Kafka)
I think one should have a toolbox with proven tools that should be default tools, while keeping an hygiene of testing new tools so that when the day arise that either the "new tool" survive the test of time, or you encounter a problematic that is really solvable only with that new tech, you can make an exception.
Java is boring because invariably I spend all that time trying to figure out the one way to make things work, given that the thing I need to do involves a library that abstracts everything multiple levels deep and all I have are API Javadocs that describe how various abstractions get created via constructors and factories that take -other- abstractions, that have no meaning whatsoever to me and my problem domain. Which means I spend hours to figure out how to do the simplest things, and I'm mentally unstimulated the entire time.
"May you live an interesting life" is a curse, as interesting lives are usually full of hardships.
He's saying that C++ is non boring, I assume because it's full of footguns.
"Today, architecture feels more like technology shopping than tinkering."
That's because most web development jobs are maintaining glorified CRUD applications. Real actual software engineering jobs are hard to find, and don't pay as well as web development (or it's open source software that doesn't pay).
The point about using more new tech being good for the adoption of these might be a fair one, but it's completely orthogonal and doesn't need to happen in startups and definitely not at the core of their service/product. Once you do know what you are doing (or what you re doing is not that important) then it's OK to pick exciting technology.
I'm guessing that in addition to Elixir, they also used plenty of boring technology. Like using `cron` or `at` rather than writing your own scheduling subsystem. Or building on top of a standard OSS database rather than rolling their own.
The point isn't to _never_ to use new technology, but rather to use enough boring tech that you still have mental bandwidth to pour into the new tech, innovation, or product that will be your competitive edge.
A technological aside that's neither here nor there with regards to the broader 'boring' debate: one of the advantages of Erlang/Elixir is that it's more of a self-contained ecosystem than, say, Rails, where you can run a bunch of different "applications" inside the same process, and it's easy for them to talk to one another. There are a number of 'cron' type things that you can easily run within your BEAM system. For some kinds of applications and deployments, this is pretty convenient. It's easier to create jobs programmatically, to introspect them, and to keep track of them all within the same system, without an external dependency.
Choose the right tech for the job. Let's move on.
That’s why we have these kind of titles.
In contrast, your comment offers no arguments, you merely dismiss the debate as uninteresting, while simultaneously misunderstanding what these authors are talking about: you claim one should simply "choose the right tech for the job", as if there is always an obvious right choice. But it seems pretty clear to me that both authors agree that this is in fact often a hard choice.
And both articles are about such situations: what to do if the choice between multiple technologies is hard. In reality, you can almost never really evaluate all the alternatives, so you need some sort of "reasoned bias", a heuristic that helps you decide between candidates. "Choose boring technology" and "choose exciting technology" are both suggestions for such heuristics.
1) I am brought in to work on some interesting project that has a mix of exciting and boring technologies. I mostly work on exciting stuff. This honey moon phase lasts from several weeks to several months.
2) As the project starts to mature, management start to demand more and more unrelated maintenance work from the team members.
At this point my time is roughly spent 50/50 on developing new features, and things like fixing spaghetti that somebody wrote years ago. I call this type of work firefighting, since management talk about it like a codebase has caught fire.
3) Management find out that projects that were on fire are seriously damaged despite not being on fire anymore. As more and more defects are found, my job gets dangerously close to being 90% boring.
4) At this point the team members that once worked on an exciting project are considered experts in random legacy codebases, and their job is extremely boring since it mostly involves maintaining them.
Personally, I find myself reading code on Github, reading HN, etc. basically trying to keep up with what's happening out there. I'm ready to move on to a project where I can learn something.
So what they do is lure engineers with greenfield projects or projects that are relatively healthy and have a good architecture, and are currently growing. Once these projects have been developed or expanded to a point where the engineers in charge (new hires among them) can also work on other stuff, the shift to "firefighting tasks" and legacy maintenance can be quite fast.
To be fair, for a backend engineer it's not that brutal, our stuff is relatively homogenous (our legacy stuff also sucks, but not that much). When it comes to frontend development though, I have seen coworkers transition from clean Vue codebases to massive jQuery spaghetti balls in just a few days.
I'm not interested in any framework with a philosophy, any language with a fan club, or any library with an opinion of how I should be doing my job.
I want to use "technology" that works and stays out of the way so I can build useful things. That's where the excitement is -- in the stuff I'm building.
Most frameworks are infuriatingly self-interested. They’re so intent on telling me that their imposed architecture is superior, despite knowing nothing about how I’m using it.
And then there’s the social pressure to use tech that specifically aims to make devs interchangeable.
Everyone has an interest in a degree of interchangeability. How mobile do you think developers would be in a world where it took them a year to get up to speed on a new set of tooling, languages, frameworks, etc. every time they switched jobs?
I have problems with the idea that devs really should spend most of their time coloring by number rather than amassing domain knowledge and expertise in the craft of development.
It gave an example of clothes dryers. The way most clothes dryers worked at the time is that you told them how long to run and how hot to get. The "how long to run" part was handled by a simple mechanical clock mechanism. You turned a dial to indicate how long you wanted it to run. Thus directly set the clock. You started the dryer, the clock ticked down, the dial moved back toward the original position, and when it got there the dryer stopped.
Those clock mechanism designs were several decades old. They were mass produced, very reliable, very cheap, and when one did broke the repairperson could easily replace it with one from a different manufacturer. Different models might have different mounting brackets, but it was easy for a repairman to improvise something if they didn't happen to have one on hand with the right bracket.
They were also extremely easy for consumers to use.
But they are also boring for the dryer designers. So there were dryer designers out there, the author said, who were starting to design their new dryers with digital timers.
Digital was exciting. The engineer got to play with microprocessors which were new at the time. They got to design printed circuit boards, a power supply for the digital electronics [1], a display, a keypad for input. They got to play around with programming the microprocessor.
But to the consumer that digital dryer control wasn't better. It didn't offer any functionality that the mechanical clock interface did not. It had a much worse interface usually. It was less reliable. It cost more, so when it did break the consumer was looking at a more expensive repair, and a slower repair since the repairperson had to get that specific control unit.
The point was that the engineer should not let their desire to play around with new and fun things take priority over delivering the best solution to the customer. There are places where digital is better than the old way--if you want to play with digital you should work on those projects, not shove digital into places where it is worse.
[1] The mechanical timers were either powered by a spring that was wound up when you turned the dial, or a simple electric motor that just needed a transformer to power it from the AC and maybe a rectifier.
The author was talking about dryers that had no functionality beyond what the ones with the mechanical timers had. They were digital just because that was more interesting to the dryer engineer.
Thats what I imply here.
If other people have to use and maintain this thing we find exciting, it stands to reason that perhaps they might not find it so exciting. If social media has taught us anything, is that interactions with UXs that give us dopamine hits may not be in our own or others' best interest over the long run.
I like "make cool stuff". The focus is on the goal, not the step-by-step interaction. It directs us to the outside, where our code interacts with people, be it users or future code maintainers. It's also vague enough that all sorts of people can define it as they like.
I love exciting new tech and having fun developing. I just don't define that love by how it makes me feel. Instead, I balance how it makes me feel and how it makes others feel too. That leads to a lot of even more interesting and fun places than simply "choose exciting technology"
ADD: Put differently, you always want your goal to "pull" the required complexity out of a system. It's a forcing function. It never works well when you start with a bunch of complexity and try to push it all towards a goal. That's backwards. I think we've sold a lot of developers on the idea that with a cool enough X, they're bound to make cool things for others. After all, look how cool X is!
Doesn't work like that.
Kubernetes can be pretty boring for somebody who worked with it for years, but an exciting, eye-opening experience for a team who has no experience with it. MySQL can also be exciting if you have only worked with Excel in the past. NoSQL can be exciting, but it can also be a safe bet if you need a multi master db, because your app needs to work offline.
I think it's easy to say a technology is safe or risky to easily promote or dismiss it. But in fact it makes sense to study and experiment with both boring and exciting technology to know if it might make your work easier and your results better.
But it is worth mentioning that in any non-trivial project there isn't a single "Choose Boring" or "Choose Exciting" technology decision that is made. Rather there is an entire collection of these types of decisions. And since "Choose Exciting" typically means that the tech is unfamiliar and/or novel, project risk dramatically increases the more "Choose Exciting" choices that are made.
As a tech person, and as a manager of engineers who I want to keep engaged and motivated, I have an affinity towards the "exciting" choices. But as the person responsible for on-schedule, on-budget delivery, I get pulled back towards "boring". It is a careful balancing act.
I think a lot of engineers, are, by nature, curious to learn, try new things and experiment.
If you're doing the same thing over and over, it's not making that part of your brain happy.
You can do new and interesting things with "boring technology".
Sometimes, the new thing is worthwhile. I remember when Rails was new. I'm glad I picked it up, and still think it's a very, very solid way of getting things done in a way that's both rapid, and yet generally well organized and with a propensity for testing and a culture of writing good code. At the time, there was a lot of PHP, which was quick... but often a mess. There were Java frameworks, but they were big and heavy and clunky. At this point, both those languages have benefited from some of the ideas in Rails.
It's important to try and figure out what the "sweet spot" is for the new tech if you want to use it. As someone who has used Erlang for a long time, including professionally, I've been curious about doing some work with Elixir, but there are definitely places out there who employed it because "new", it seems, without solid reasons why. I'm still not 100% sure what the sweet spot is for Elixir, although I was very happy with Erlang for the "semi-embedded" systems where I used it.
I think going for one or two new things, while keeping the rest mostly the same is a decent way of containing the risk. I've been using Postgres for 20+ years, quite happily. I enjoy the challenge of writing solid, performant queries with it, but it's the same DB system.
- most "exiting" tech is not a innovation. It's just rehashing long known and previously failed concepts in new clothes. And sure due to improved UX, computation capabilities and/or better engineering it now might succeed or well just fail again.
- most companies purpose is to create revenue (hopefully by creating a good product). So there isn't any interest to drive innovation if everything can be done completely fine with existing tech.
- Just using new tech doesn't necessary drive innovation, only by giving useful feedback can it drive innovation. Something which in my experience is often not done, especially in smaller startups.
- If exiting tech enables you to do thinks you couldn't do before or to do thinks much more efficient (mainly productivity wise) then sure go ahead and use it but in my experience for a lot of companies opting to use exiting tech it's not the case at all.
- Not all exiting tech fits all company sizes, there is quite a lot of exiting tech which is generally good but at some point as a massive major overhead. Which any massive company can handle but which makes it a horrible choice for smaller companies.
- Lastly some exiting tech is not just not innovation it's more like de-inovation and the only good think it has going for it is that it easy to get started with and "is fun"/"exiting" or similar.
So I would only use exiting tech if it gives you a good benefit over other tech you can use instead.
Be aware that better UX can totally be a benefit good enough to make it worth it. (With UX I mean the developer experience as the developer is the direct user of the tech.)
Use your spiffy new stuff to prove something is possible, to build that MVP. Then use something reliable to implement production version.
You can use a fancy million dollar CNC machine to build the engineering prototype of a gear set... but you're going to end up using some old as the hills Gleason or Barber-Coleman machines to make them in production quantities.
The CNC machine lets you iterate through the design space almost instantly... the gear cutting machines take a few hours each setup, but then produce gears much, MUCH faster than the CNC machine in actual production. They've been optimized to do so.
Stable platforms that you have experience on are well known, and your estimates of doing X on them are far more likely to be accurate.
Search for the late Christensen Clayton, who quoted "disruptive technologies". He has many youtubes great for a Sunday.
My dad’s been a joiner for 40+ years. At the time he started, the industry didn’t have access to things like MDF, cordless drills, nailguns, or various other tools and materials that are now taken for granted.
The general principle that he’s expressed to me—and one I’ve tried to follow—is that it’s worth investing in and keeping an eye on developments and new technology, and applying them in situations where you are confident they will offer a benefit. That might be faster completion of a job, or lower-cost materials, or a more robust outcome.
Jumping in to using new techniques “just because” is usually a bad idea, though sometimes it’s worth doing so in less critical situations to make sure your skills and knowledge are up to date. The flip-side is he mentioned a case where he’d hired someone experienced and sent them off to do something—I think sheeting a floor with plywood or something—and came back at the end of the day to find they’d spent the day trying to do the job with a hand drill instead of an electronic drill.
I’d say the balance is what is important. Boring technology is a good basis to start with and is usually the right choice, because most problems are boring. But this shouldn’t prevent you from applying exciting technology in cases where it offers a genuine benefit. Just be aware that excitement has a cost, and you have limited “excitement tokens” that you are able to spend, so it’s best to save them for the bits where they offer a real benefit.
In my experience, few things are as exciting as shipping. Watching people use the code I wrote, or turning a mature, battle-tested infrastructure over to a new team, and watching them take it to the stratosphere.
And not having to create a JIRA database for bug reports, because the quality is so high that an occasional email is all you get.
No...scratch that. Failing is also quite exciting. Not what you meant? Sorry about that.
I'm not a big fan of dogma. That includes "Use the latest <BUZZWORD DU JOUR>, or you're a loser," as well as "Stay the hell away from the latest <BUZZWORD DU JOUR>, or you might get hurt."
I write in Swift. Even though it is coming up on seven years old, it's still a baby, compared to languages like Rust and Python. I committed to using it, the day it was announced.
This was because the company that supported it (you may have heard of them) was demonstrably behind the language, and the guy that designed it, wrote LLVM, so I knew it had a future.
I feel like I have really only been good enough at it to be confident, for the last couple of years, despite shipping a number of apps, written in it, since 2014.
I write in PHP, because I don't like to spend too much time on the server end of the API, and want solid, reliable and supported tech on the backend. If I want something more "cutting edge," I'll hire someone that is more familiar with that tech, as opposed to trying to learn it, myself.
I took several bets with frameworks, libraries, databases and even languages during my career. Most of them worked out great. Only one time I needed to rewrite stuff because some library got deprecated. Overall it was well worth it.
From that POV most of what we do in the IT field is unspeakably ridiculous. Our machines are Fractal Rube Goldberg machines made out of Rube Goldberg machines.
- - - -
Elixir is a bad example, it's "boring" not "exciting". It's a thin syntactic layer over the BEAM, which is for running telephony exchanges. Those things could not be more "boring" in the sense we're using here: they just sit there and work, day in and day out, tolerating faults and load variances, routing phone calls.
But, if you can use something new and shiny, great. I rarely had that opportunity myself.
As an engineer what you can achieve, what you produce should excite you, what you produce, something that is useful and used. Something important. The product.
Technology is just an aspect to achoeve it. One of many. It can be exciting, it can be boring, but the ultimate excitement is the creation of something useful, not using a tool...
If the tool has the focus that is more like entertainment. Not engineering.
Use whatever you need, boring or exciting alike! Let the task and the product excite you, not the tools.
And over and over again I hear from companies that use boring tech that it’s extremely hard to hire top people and so they hire junior people and hope to turn them into senior people.
The first will let you honor your moral contract of service quality with your clients.
The latter will enable you to grow and experiment in a low-stakes environment. Also, when the new toys become boring, you'll be The Guru (tm) everyone goes to for advice.
You're happy, and everyone wins.
Edit: of course 'work' and 'home' are used loosely here, not taking into account real-world diversity.
I'm still excited about working with the same stack I used 5 years ago.
But neither of those positions necessarily contradicts the other’s stated goals. Familiar technology can certainly be exciting to work with, and unfamiliar technology can be used for pure dull getting stuff done.
In any event, the crux of the issue is how your tech handles failures. A new-fangled exotic technology that works really well is "boring". Case in point: Elm lang. Very exotic, totally boring.
You can use boring tech to solve exciting problems, or use exciting tech to solve boring problems.
Personally, I find joy in just shipping stuff, so I use what I know best.
I do try out new stuff every once in a while. Some new tools stick, others don’t. But that’s just updating my tool belt, not fixing my problems.
You have (had in that case) a better chance hiring someone passionate/talented if the technology is (was) not very mainstream.
What would be today's equivalent? Elixir? Rust?
Rust has already passed point of no return by gaining so much support (and hype) in the industry. I almost feel like it can hurt it. Too many articles here like "Some_random_foo implemented in Rust" look almost as "How some_random_bar will be revolutionized with blockchain."
So a good equivalent to that article's Python example is something simple, not very bloated that people might enjoy for rapid prototyping or for side projects. And at the same time not popular enough to have an army of newcomers or hundreds of "boring" jobs. Various FP languages set the bar to high to match these criteria. If there is such a language now, we'll know that for sure in 10 years.
Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721
Your bank is down because some yahoo thought Nim and GraphQL on Neo4j would be fun? Less so.
For me a key thing is that "boring" doesn't just mean mature and well established. C++ is mature and well established but it's not boring because there are all sorts of nasty memory safety issues to keep things "exciting". OracleDB is mature and well established, but from what I hear you have to pay expensive fees to do all sorts of things: that's not boring!
If management doesn't care, why should I?
Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.