11 ms·

Choose Exciting Technology

156 points by methyl 6y ago

amw-zero 6y ago
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?
- keithb- 6y ago
  This is a great comment, but I would generalize to just about any other profession. Are nurses bored with bandaids and hoping for better technology? And also comparisons between computer engineering and construction are always problematic because they are at completely different stages of maturity. Maybe what you suggest did happen in 1500 BC when the homeowner was like "Hey buddy, just build this closet with mud bricks" and the carpenter was like "Nar bro, I got these twigs I cut down that are super cool. Mud is for neubs".
  - Leherenn 6y ago
    Bandaids, I don't know, but they (at least some) certainly are about new sensors/techniques/catheters,... Also, people wanting to work on the latest and greatest because it is the latest and greatest is also sometimes an issue.
- Leherenn 6y ago
  Yes? Well maybe not clay, but the choice of materials is certainly subject to cycles and hype. See bioconcrete for instance these days for construction in general.
- interlocutor2 6y ago
  Carpentry is innovating new jigs, joinery methods, engineered wood, aesthetic trends, steam bending, finishes, and inlays.
- marcinzm 6y ago
  No but they will probably tell them to learn to use a CNC machine rather than just using a power saw.
- matthewmacleod 6y ago
  Yes, there’s actually a really similar throughline. 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.
bsenftner 6y ago
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.
anotherhue 6y ago
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.
- nicoburns 6y ago
  True, but if your app is running Rust on Postgres, then that might well be a win over C++ on OracleDB. 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!
  - flixic 6y ago
    Very good point. "Exciting" is in the eye of the beholder.
  - heurist 6y ago
    Safe and flexible would be a better target than exciting or boring. Those are a bit harder to quantify than newness though.
- elcritch 6y ago
  Point taken, but Nim is pretty stable in my (somewhat limited) experience with it. Though the original article does mention innovation tokens, which in this case would be exceeded.
- bluepizza 6y ago
  My bank is usually down because their systems were offshored to rather low paid professionals. If management doesn't care, why should I?
simonswords82 6y ago
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.
- methyl 6y ago
  This is exactly what I intended to do when publishing this article: provoke sensible discussion. I think it's valuable to talk about polarizing views. Often agreement solely depends on the context you are in and it's useful to get familiar with different contexts.
- xwdv 6y ago
  The bridge between polarizing views is in the comments. Comments are the last bastion of honest discussion, and it’s why people don’t bother reading articles. A good article is one that spawns good comments, and sometimes all you need is a good headline to spur the discussion. That’s why we have these kind of titles.
- ookdatnog 6y ago
  I'm not really sure why you think these articles are not contributing to sensible discussion. Both articles provide arguments for their case, neither seem dogmatic about it. 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.
- satyrnein 6y ago
  Has anyone ever argued against using the right tool for the job? That advice is unfortunately not very actionable. The whole discussion is about which tool is right for which job.
CSDude 6y ago
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.
- amw-zero 6y ago
  What is this idea that “engineers need to be kept happy?” Are programmers children that we need to entertain in order for them to do their job?
  - deleted 6y ago
    [deleted]
  - idorosen 6y ago
    They’re professionals whose decisions and input companies must afford the appropriate amount of consideration, and whose professional development companies must also respect to be competitive in the hiring market. These tech choices are usually contextual, and that context includes business factors such as continuity and retention, which present a trade off. That is a compressed version of the GP post.
  - killingtime74 6y ago
    Yes. It’s called job satisfaction. Also you don’t have to if you’re willing to pay more
  - bsenftner 6y ago
    In many cases, in some industries: yes. When working in media production, it does not matter if the media being produced is feature films, feature animated films, a TV series, an animated TV series, or a AAA to C level video game production - the software developers, digital artists, and line producers are ready to quit or reduce productivity to a trickle at the drop of a hat if they sense the production will not be a commercial success and not grant them social bragging rights. Yes, this sounds completely absurd, until you are in the media production industries and see it happening. It's an entitled attitude, but getting the line workers to see it that way is not gonna happen.
danabrams 6y ago
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.
qznc 6y ago
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.
Tomte 6y ago
"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.
amzans 6y ago
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.
_nhh 6y ago
Exciting has different meanings for everyone. Do what delivers value to someone. In the end it is a people thing, not a technology thing.
darkr 6y ago
Ironically, Elixir is a great example of a success largely due to being based on “boring” technology
- methyl 6y ago
  So it seems it took a boring technology and made it exciting. Way to go!
- dbattaglia 6y ago
  Erlang and BEAM are an interesting one in the "boring" to "exciting" spectrum, being quite mature and stable with a strong track record of successful large systems built on it, yet I'd imagine still considered exotic to the majority of developers out there cranking away on "boring" languages.
- cpursley 6y ago
  I activity encourage folks to avoid Elixir. After working with Elixir, it's very difficult and demotivating to go back to Ruby, Java and the like.
  - cutler 6y ago
    Even more difficult after you've been exposed to Clojure but I'd rather have Clojure any day than Java, .Net, Ruby or whatever.
  - davidw 6y ago
    How so? I've switched back and forth between Erlang and Rails at various companies. I still find Ruby a great way to get things done quickly and cleanly. I haven't used Elixir quite as much. It's a nice language, and I think genuinely improves on Erlang in some ways, but it's more the BEAM system that I like about it rather than it being a lot more productive than Ruby.
kamilafsar 6y ago
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.
grishka 6y ago
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.
mkl95 6y ago
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.
- Smaug123 6y ago
  Sorry to ask this, but there's one common thread in your experiences which "always" follow this pattern: you were one of the engineers on them. Do you have any evidence that you're not the problem here?
  - mkl95 6y ago
    I believe there is a teapot (too small to be detected) orbiting the Sun between the Earth and Mars, and no one has been able to disprove it. Don't quote me on this though.
    - Smaug123 6y ago
      I'd just like to make sure you've at least considered the hypothesis your words are strongly suggesting, namely that you specialise in producing tech debt and you quit whenever that debt crosses some critical threshold. If it's not actually like that, then great!
ahmedfromtunis 6y ago
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.
hliyan 6y ago
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.
- allan_s 6y ago
  I totally agree with you, I've been writing professionally php and python, vanilla js/react and postgresql for a good decade now and I'm still learning exciting new things in these technology. (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.
  - hliyan 6y ago
    I do the same thing. I write at least a hello world project in most new tech that comes my way. Sometimes I find some of them interesting and use them in production maybe a year or two later. But definitely not as soon as I learn them!
- phabora 6y ago
  To be fair C++ seems like a very non-boring technology. In the “may you lead an interesting life” sense.
  - lostcolony 6y ago
nawitus 6y ago
Choose a mix of boring and exciting technology instead. Pick 1-2 new things for your new app and you're probably good.
bigpeopleareold 6y ago
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.
Maascamp 6y ago
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.
- kevinconroy 6y ago
  Agreed. Their example is that selecting Elixir was a great choice for them. Cool. That was using an Innovation Token. 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.
  - davidw 6y ago
    > Like using `cron` or `at` 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.
dsiegel2275 6y ago
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.
ChrisMarshallNY 6y ago
> 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.
rogual 6y ago
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.
- mattgreenrocks 6y ago
  This reason is why I don’t get along well with most frameworks. 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.
  - ghaff 6y ago
    >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?
    - mattgreenrocks 6y ago
      Not sure who is arguing that. 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.
odiroot 6y ago
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.
vlttnv 6y ago
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.
atleta 6y ago
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.
DanielBMarkham 6y ago
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.
naranha 6y ago
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.
shoulderfake 6y ago
These are becoming such clickbait articles
mihaaly 6y ago
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.
mikesabbagh 6y ago
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.
tzs 6y ago
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.
- dwb 6y ago
  Agreed, but don't conflate "solving business problems" with "best solution for the customer".
- 6y ago
mikewarot 6y ago
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.
- satyrnein 6y ago
  Interesting take, but within software, isn't using brand new tech that you need to learn (plus has less documentation, ecosystem, community, etc) slower for iteration?
  - mikewarot 6y ago
    The spiffy new language usually has some feature the developer can use to save time making the prototype. Since long term maintenance isn't an issue, you are free to iterate until it works. 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.
davidw 6y ago
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.
eyelidlessness 6y 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.
- carapace 6y ago
  You've got it half right, the term "exciting" is being used for "exotic" or "novel" (and note that these are subjective: they depend on the history of the speaker) while "boring" means something more like "reliable" or "low-maintenance" (which is much less subjective and can be more-or-less measured and quantified in hard data.) 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.
  - eyelidlessness 6y ago
    You’re restating my point in slightly different words. The reason that I addressed the “boring” side the way I did is because it’s so often used reflexively to discourage use of newer/more exotic tech like Elm without acknowledging that it is, in fact, “boring” in the intended sense.
carapace 6y ago
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.
bullen 6y ago
Elixir is not exiting. Erlang cannot share memory efficiently between threads: Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.
dathinab 6y ago
> 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.)
forgotmypw17 6y ago
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.
surajs 6y ago
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.
dang 6y ago
Current and related: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721
mike_k 6y ago
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 http://www.paulgraham.com/pypar.html
- rahimnathwani 6y ago
  Wow, from Aug 2004: "And people don't learn [Python] because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know." What would be today's equivalent? Elixir? Rust?
  - mike_k 6y ago
    Elixir seems to be quite pragmatic choice despite being a niche tool (most Erlang OTP pros and cons are is still there). 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.
jhanschoo 6y ago
Choosing JS instead of Ruby for a stack 3 years ago isn't really choosing exciting technology vs. boring technology.

156 points by methyl 6y ago

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?

keithb- 6y ago
This is a great comment, but I would generalize to just about any other profession. Are nurses bored with bandaids and hoping for better technology? And also comparisons between computer engineering and construction are always problematic because they are at completely different stages of maturity. Maybe what you suggest did happen in 1500 BC when the homeowner was like "Hey buddy, just build this closet with mud bricks" and the carpenter was like "Nar bro, I got these twigs I cut down that are super cool. Mud is for neubs".
- Leherenn 6y ago
  Bandaids, I don't know, but they (at least some) certainly are about new sensors/techniques/catheters,... Also, people wanting to work on the latest and greatest because it is the latest and greatest is also sometimes an issue.
Leherenn 6y ago
Yes? Well maybe not clay, but the choice of materials is certainly subject to cycles and hype. See bioconcrete for instance these days for construction in general.
interlocutor2 6y ago
Carpentry is innovating new jigs, joinery methods, engineered wood, aesthetic trends, steam bending, finishes, and inlays.
marcinzm 6y ago
No but they will probably tell them to learn to use a CNC machine rather than just using a power saw.
matthewmacleod 6y ago
Yes, there’s actually a really similar throughline. 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.

bsenftner 6y ago

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.

anotherhue 6y ago

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.

nicoburns 6y ago
True, but if your app is running Rust on Postgres, then that might well be a win over C++ on OracleDB. 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!
- flixic 6y ago
  Very good point. "Exciting" is in the eye of the beholder.
- heurist 6y ago
  Safe and flexible would be a better target than exciting or boring. Those are a bit harder to quantify than newness though.
elcritch 6y ago
Point taken, but Nim is pretty stable in my (somewhat limited) experience with it. Though the original article does mention innovation tokens, which in this case would be exceeded.
bluepizza 6y ago
My bank is usually down because their systems were offshored to rather low paid professionals. If management doesn't care, why should I?

simonswords82 6y ago

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.

methyl 6y ago
This is exactly what I intended to do when publishing this article: provoke sensible discussion. I think it's valuable to talk about polarizing views. Often agreement solely depends on the context you are in and it's useful to get familiar with different contexts.
xwdv 6y ago
The bridge between polarizing views is in the comments. Comments are the last bastion of honest discussion, and it’s why people don’t bother reading articles. A good article is one that spawns good comments, and sometimes all you need is a good headline to spur the discussion. That’s why we have these kind of titles.
ookdatnog 6y ago
I'm not really sure why you think these articles are not contributing to sensible discussion. Both articles provide arguments for their case, neither seem dogmatic about it. 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.
satyrnein 6y ago
Has anyone ever argued against using the right tool for the job? That advice is unfortunately not very actionable. The whole discussion is about which tool is right for which job.

CSDude 6y ago

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.

amw-zero 6y ago
What is this idea that “engineers need to be kept happy?” Are programmers children that we need to entertain in order for them to do their job?
- deleted 6y ago
  [deleted]
- idorosen 6y ago
  They’re professionals whose decisions and input companies must afford the appropriate amount of consideration, and whose professional development companies must also respect to be competitive in the hiring market. These tech choices are usually contextual, and that context includes business factors such as continuity and retention, which present a trade off. That is a compressed version of the GP post.
- killingtime74 6y ago
  Yes. It’s called job satisfaction. Also you don’t have to if you’re willing to pay more
- bsenftner 6y ago
  In many cases, in some industries: yes. When working in media production, it does not matter if the media being produced is feature films, feature animated films, a TV series, an animated TV series, or a AAA to C level video game production - the software developers, digital artists, and line producers are ready to quit or reduce productivity to a trickle at the drop of a hat if they sense the production will not be a commercial success and not grant them social bragging rights. Yes, this sounds completely absurd, until you are in the media production industries and see it happening. It's an entitled attitude, but getting the line workers to see it that way is not gonna happen.

danabrams 6y ago

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.

qznc 6y ago

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.

Tomte 6y ago

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

amzans 6y ago

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.

_nhh 6y ago

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

darkr 6y ago

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

methyl 6y ago
So it seems it took a boring technology and made it exciting. Way to go!
dbattaglia 6y ago
Erlang and BEAM are an interesting one in the "boring" to "exciting" spectrum, being quite mature and stable with a strong track record of successful large systems built on it, yet I'd imagine still considered exotic to the majority of developers out there cranking away on "boring" languages.
cpursley 6y ago
I activity encourage folks to avoid Elixir. After working with Elixir, it's very difficult and demotivating to go back to Ruby, Java and the like.
- cutler 6y ago
  Even more difficult after you've been exposed to Clojure but I'd rather have Clojure any day than Java, .Net, Ruby or whatever.
- davidw 6y ago
  How so? I've switched back and forth between Erlang and Rails at various companies. I still find Ruby a great way to get things done quickly and cleanly. I haven't used Elixir quite as much. It's a nice language, and I think genuinely improves on Erlang in some ways, but it's more the BEAM system that I like about it rather than it being a lot more productive than Ruby.

kamilafsar 6y ago

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.

grishka 6y ago

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.

mkl95 6y ago

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.

Smaug123 6y ago
Sorry to ask this, but there's one common thread in your experiences which "always" follow this pattern: you were one of the engineers on them. Do you have any evidence that you're not the problem here?
- mkl95 6y ago
  I believe there is a teapot (too small to be detected) orbiting the Sun between the Earth and Mars, and no one has been able to disprove it. Don't quote me on this though.
  - Smaug123 6y ago
    I'd just like to make sure you've at least considered the hypothesis your words are strongly suggesting, namely that you specialise in producing tech debt and you quit whenever that debt crosses some critical threshold. If it's not actually like that, then great!

ahmedfromtunis 6y ago

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.

hliyan 6y ago

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.

allan_s 6y ago
I totally agree with you, I've been writing professionally php and python, vanilla js/react and postgresql for a good decade now and I'm still learning exciting new things in these technology. (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.
- hliyan 6y ago
  I do the same thing. I write at least a hello world project in most new tech that comes my way. Sometimes I find some of them interesting and use them in production maybe a year or two later. But definitely not as soon as I learn them!
phabora 6y ago
To be fair C++ seems like a very non-boring technology. In the “may you lead an interesting life” sense.
- lostcolony 6y ago

nawitus 6y ago

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

bigpeopleareold 6y ago

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.

Maascamp 6y ago

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.

kevinconroy 6y ago
Agreed. Their example is that selecting Elixir was a great choice for them. Cool. That was using an Innovation Token. 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.
- davidw 6y ago
  > Like using `cron` or `at` 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.

dsiegel2275 6y ago

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.

ChrisMarshallNY 6y ago

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

rogual 6y ago

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.

mattgreenrocks 6y ago
This reason is why I don’t get along well with most frameworks. 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.
- ghaff 6y ago
  >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?
  - mattgreenrocks 6y ago
    Not sure who is arguing that. 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.

odiroot 6y ago

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.

vlttnv 6y ago

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.

atleta 6y ago

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.

DanielBMarkham 6y ago

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.

naranha 6y ago

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.

shoulderfake 6y ago

These are becoming such clickbait articles

mihaaly 6y ago

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.

mikesabbagh 6y ago

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.

tzs 6y ago

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.

dwb 6y ago
Agreed, but don't conflate "solving business problems" with "best solution for the customer".
6y ago

mikewarot 6y ago

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.

satyrnein 6y ago
Interesting take, but within software, isn't using brand new tech that you need to learn (plus has less documentation, ecosystem, community, etc) slower for iteration?
- mikewarot 6y ago
  The spiffy new language usually has some feature the developer can use to save time making the prototype. Since long term maintenance isn't an issue, you are free to iterate until it works. 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.

davidw 6y ago

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.

eyelidlessness 6y 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.

carapace 6y ago
You've got it half right, the term "exciting" is being used for "exotic" or "novel" (and note that these are subjective: they depend on the history of the speaker) while "boring" means something more like "reliable" or "low-maintenance" (which is much less subjective and can be more-or-less measured and quantified in hard data.) 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.
- eyelidlessness 6y ago
  You’re restating my point in slightly different words. The reason that I addressed the “boring” side the way I did is because it’s so often used reflexively to discourage use of newer/more exotic tech like Elm without acknowledging that it is, in fact, “boring” in the intended sense.

carapace 6y ago

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.

bullen 6y ago

Elixir is not exiting. Erlang cannot share memory efficiently between threads: Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.

dathinab 6y ago

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

forgotmypw17 6y ago

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.

surajs 6y ago

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.

dang 6y ago

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

mike_k 6y ago

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 http://www.paulgraham.com/pypar.html

rahimnathwani 6y ago
Wow, from Aug 2004: "And people don't learn [Python] because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know." What would be today's equivalent? Elixir? Rust?
- mike_k 6y ago
  Elixir seems to be quite pragmatic choice despite being a niche tool (most Erlang OTP pros and cons are is still there). 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.

jhanschoo 6y ago

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