Engineers need to be kept happy. Some like tech, some money. It's a personal preference. Businessses need to deliver in-time and also profit, or they just need to be stable.

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.

Engineers who find a stable technology boring after a few years probably lack curiosity and are not digging deep enough. It's a form of ADHD.

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.

First of all, this is a typical example of survivorship bias: look, we picked exciting tech and we've succeeded. The point of using 'boring tech' was never to state that everyone should stay away from new/exciting things. It's about managing risks. First of all, if you are building a startup, a new service, you already have a ton of risks and unknowns (and excitement) so it makes little sense to top it with untested, new, exciting technology. Unless you have a very good reason. (And no, anticipating to have a huge number of users X years down the road and the perceived need need for super scalability is not a good reason.)

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.

Feels like this person completely missed the point of choose boring technology. The point isn't to never use anything new or exciting, the point is to save the excitement for your core value prop so that you're not wasting time e.g. debugging why your customer database keeps losing data instead of iterating on your actual product, where all the excitement is.

Both this and the other post trending on HN right now about boring technology show yet again that the Internet is a place for polarising views and clickbait titles rather than sensible discussion.

Choose the right tech for the job. Let's move on.

I have worked for several startups as a Python engineer and the job always follows this pattern:

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.

For me, at this point, using exciting technology is like writing a book on exciting paper.

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.

The textbook used in a digital electronics design course I took in college in the early '80s ended with a section called "The Engineer as Dope Pusher".

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 problem, I believe, is in the word "exciting". It's simply too broad to make reasonable generalizations about. Exciting technology to one person might be sorting a text file, to another person it might be creating a GAN dapp.

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.

I don't get this whole debate. Who decides what is boring and what is exciting technology?

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.

I liked this article and I feel there is validity to the point that innovation can be stifled by strictly choosing boring technology.

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.

This is an interesting question. Some thoughts in no particular order:

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.

> Slowing down innovation

- 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.)

The goal should be to maximize the amount of solution space that can be explored, and them maintained, for a given amount of effort.

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.

I think sometime we, software engineers, forget that we are hired to do a job and not to play around with toys in the sandbox.

Choose boring technology, and every other person can copy your work. Choose exciting new technology, you will be able to have features that few can replicate, or it will take them more time to do so. The question should be, are the features you need important for your business or have a supporting role only? U dont need to re-invent the wheel and use the greatest and latest to run a database. But u definitely need to have a cutting edge feature that others will have tough time building.

Search for the late Christensen Clayton, who quoted "disruptive technologies". He has many youtubes great for a Sunday.

How do you think the field of carpentry feels about this? Do you think they tell young carpenters in the field to convince homeowners to build their next closet in clay, because wood is old and boring?

"Choose boring tech" doesn't mean you should never try something new and fun. It means you limit those new things to a few. The original article speaks of innovation tokens.

Ironically, Elixir is a great example of a success largely due to being based on “boring” technology

> Don’t follow rules of thumb blindly. If excitement drives you, you are not alone.

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 agree 100%, but you also need to know which tech is going to get mainstream later on. Nobody wants to use tech which was once exciting, and now deprecated.

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.

The point is not to always choose boring technology. The useful concept are the innovation tokens. If you spent your innovation tokens on other stuff (org change, process change, new customer, new product), then you should at least keep the tech stable. Otherwise, feel free to invest some innovation tokens into exciting technology.

Ya know what is super duper exciting? Finding a boring product/service area no one is exploiting and you can design the entire experience for customers, infrastructure, and partners and reap all the profits. That's exciting.

A metaphor I use that seems to help me cut through some nonsense is that computer systems are factories.

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.

I used to always get excited over new tools, but stopped because if they don't solve a type of problem I must or want to solve, it's just not that interesting. Algorithms, data structures, design decisions and methods (with their limitations), business domains I develop towards, and choosing what to solve end up be more interesting. I started to look at Rust, for example, for at most a few days, but I am not solving anything that needs it at the moment, but can understand why it exists at least.

But, if you can use something new and shiny, great. I rarely had that opportunity myself.

Technology is just a tool like a spoon. It is uninteresting and boring on its own account.

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.

Over and over again I hear from friends who work at companies that chose exciting technology that a major benefit is that it makes it easy to hire talented engineers who are exceptionally good, because that’s who’s interested in learning the exciting tech—and for startups this can mean being able to afford a top-notch engineer when they otherwise might not.

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.

As I see it, choose boring tech where stability is paramount, i.e. at work. Opt for fancy new stuff when you want to learn, i.e. at home.

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.

New often doesn't mean more exciting. It's usually just catering to some niche requirement of the author(s).

I'm still excited about working with the same stack I used 5 years ago.

I think part of what’s weird about this discussion is that the usage of “boring” or “exciting” is somewhat misapplied. What’s apparently the distinguishing property is “common” or “familiar” vs “exotic” or “novel”.

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.

I believe the key is to solve the problems that are getting between you and your goals, not potential issues you think one day will be yours.

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.

Exciting has different meanings for everyone. Do what delivers value to someone. In the end it is a people thing, not a technology thing.

Choose a mix of boring and exciting technology instead. Pick 1-2 new things for your new app and you're probably good.

This is also very in sync with the The Python Paradox[1] article by Paul Graham.

You have (had in that case) a better chance hiring someone passionate/talented if the technology is (was) not very mainstream.

[1] http://www.paulgraham.com/pypar.html

I think boring/exciting are a matter of context, some new tech is exciting because of its implications on a broader level... i do buy the "Excitingly boring" compliment bit but anything new isn't necessarily exciting and old stuff isn't always boring.

Current and related:

Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721

I think Exciting Technology, especially in the programming world, is mostly built on top of existing technology, and for me personally, I choose Boring Technology for doing that.

For unimportant products, or features of your product (maybe), sure.

Your bank is down because some yahoo thought Nim and GraphQL on Neo4j would be fun? Less so.

Elixir is not exiting. Erlang cannot share memory efficiently between threads:

Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.

Choosing JS instead of Ruby for a stack 3 years ago isn't really choosing exciting technology vs. boring technology.

These are becoming such clickbait articles

You can't just choose technologies, especially frameworks, the way you would choose tools. Tools simply shape the result of your work — it doesn't matter what you used to make something, as long as it turned out good. Frameworks and libraries stay inside your product, and directly affect how your users experience it.