20 ms·

Choose Boring Technology (2015)

459 points by dpcx 6y ago

whymauri 6y ago
Prior discussion from when the blog was originally written: https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 A related page I recall seeing on HN last summer: http://boringtechnology.club/ http://boringtechnology.club/
smabie 6y ago
If I use APL and Lisp, does that count as spending innovation tokens? Is boring technology old, or is it widely used? Most people I know don't consider J, kdb+/q, Haskell, or OCaml boring, but they are all awesome industrial strength languages/technologies.
- jowiar 6y ago
  I’ve found boring in this context to be a function of 3 things (in no particular order): - Your experience using the tool in question to solve this problem or very similar ones - Your teammates’ experience using the tool in question to solve this problem or very similar ones - The world’s experience using the tool in question to solve this problem or very similar ones The specific drivers of this tend to be a mix of problem-solving pattern matching ie “Hey, we know what the usual suspects are know when things are slow/crash”, and ecosystem robustness — what is the probability of you being the first to trip a bug in a dependency / has a library been used to solve 10000 problems or just 3 — It’s more likely that APIs have been sorted out, bugs have been closed, etc. or that your team knows the quirks. As an example, OCaml might be a relatively boring choice for writing a theorem prover, but for something like a RDBMS-backed web application, things are a lot more “interesting” as you go off the map much sooner.
- deleted 6y ago
  [deleted]
- ma2rten 6y ago
  I think it's the combination of mature and widely used. The company I worked at previously used Erlang. It caused a lot of headache in terms of finding well-supported database drivers and things like that.
- invalidOrTaken 6y ago
  Boring is boring---i.e., no surprises. Whether it's been tested by a lot of other people, a lot of years, or even just a lot of your time. APL is not boring to me, but it might be to you.
MattGaiser 6y ago
This makes sense until I need to find a new job in 18 months.
- WrtCdEvrydy 6y ago
  To be honest... someone who says 'I built it on something that already worked' is probably not that bad in today's market. There are three classes of companies: ones who haven't tried having a buffet of technologies, ones who already have and ones who are recovering.
- adrianN 6y ago
  I guess that depends on your specialization. If you build backend services with Java or C++ the job market is pretty big. Probably bigger than if you're a Go expert but don't know Java or C++.
- bdcravens 6y ago
  The risk of this attitude is that you may never get enough experience in a technology to approach expert level. If we're constantly reinventing the wheel, it means we never really have a chance to use that wheel to go anywhere.
- m463 6y ago
  It makes perfect sense if you want to work for Elon Musk under the streets of Hawthorne.
  - MattGaiser 6y ago
    If you are doing firmware development, sure. If you check out their full stack development jobs, they want Go and TypeScript. https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4747757002 https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4...
    - m463 6y ago
      ha, I was referring to "the boring company"
aaronbrethorst 6y ago
Five years ago I posted a comment on this same article, which you can read at https://news.ycombinator.com/item?id=9291437 https://news.ycombinator.com/item?id=9291437 I still stand by everything I said in that comment, and it has served me incredibly well on every project I've worked on since. At least in the cases where I followed my own advice :-\ tl;dr: if you're trying to build and ship something quickly, don't use any new technology. If you want to use your project as an excuse to learn a new technology, limit yourself to only one technology so you can better isolate issues when they crop up.
barbs 6y ago
(2015)
deleted 6y ago
[deleted]
Throwaway8588 6y ago
Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.
- hilbertseries 6y ago
  Rust may be “hot” but there are far more Java jobs than Rust jobs and I highly doubt that’s going to change anytime soon. And indeed Java developers have been highly employed for quite some time.
  - Throwaway8588 6y ago
    True, most transitions won’t be permanent but it really sucks to miss the ones that are (Angular and React eating everything).
  - jghn 6y ago
    Agreed. I personally love the "hot" tech, but anyone claiming there are more jobs for those skills than the tried & trued is being disingenuous
    - MattGaiser 6y ago
      I think it depends on where you want to work. If you check out the YC job boards, they want TypeScript, Go, and GraphQL.
      - didibus 6y ago
        I've found in general the places that use Java don't look for a Java developer. Its like they just assume you can pick it up. You might see things like knowledge of OOP, SQL, etc. on the job listing. For example, lots of large companies like Google, Microsoft, Amazon, Twitter, Netflix, etc. have a ton of Java, but their job descriptions don't really mention it. On the other hand, if a place needs Typescript, or GO, they'll mention it.
noncoml 6y ago
I thought MongoDB and NodeJS are the boring technology today... Edit: Oh, it needs a (2015)
- andi999 6y ago
  All the tech there is not really boring. If you want boring take db2.
- bob1029 6y ago
  I don't think 5 years has done much of a favor for MongoDB. Boring in this context doesn't necessarily mean 'old' technology. It means technology that is so stable & reliable that you forget it's there. I can go weeks on end before being tangentially reminded that we use SQLite to store business entities. I am usually in the arena of business logic working with our various customers. This is what boring technology means to me. Stuff that "just works" and never causes you to spend any time worrying about it.
- xtracto 6y ago
  MongoDB is full of surprises, especially when it chews your data for no given reason or when its performance slows to a crawl. I'll take ye old PostgreSQL (with JSONB if I need unstructured data) or even mariadb.
l0b0 6y ago
As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the frontend and backend. Then there's infrastructure: pick at least three infrastructure as code components (Puppet/Chef/Ansible/k8s/Docker/Docker Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers (Apache/nginx/traefik/your language's built-in server), and at least two TLS certificate providers because someone's nervous about moving everything to Let's Encrypt. I'm well aware that these don't have identical feature sets, but that's the point of the article: choosing a small and boring set of technologies is an advantage, not something to be ashamed of.
- gavinray 6y ago
  I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you get Javascript/Typescript on the backend as well, so the entire stack is just JS/TS the whole way through with a single UI/design language. It was really easy to hire developers this way and the transferable skills were high. However you look at it, this is sort of the deal with JS these days. From a productivity and development velocity perspective, it's really difficult to rationalize using other technologies when you can just holistically build your entire stack in one JS/TS UI framework for the clients (or Flutter, nowadays) and then JS/TS on the backend too. This is why I'm mentally shoehorned into using Typescript for everything. I enjoy it a lot, but there are other languages I enjoy too, it just doesn't make as much sense to throw them in the mix because then you've increased technical complexity and made it that much more difficult to source talent.
  - mettamage 6y ago
    Seconding this. I have the same experience.
javajosh 6y ago
SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, PostCSS, TypeScript, React, Redux, RxJS, to be rather exciting, and that's only a few of the exciting parts of a mature SPA project. And of course this doesn't touch REST, GraphQL, CI/CD, testing, metrics, telemetry and all the other excitement. So, yeah, I would say that if you take the article seriously for a webapp, you'd limit yourself to a really boring Java (8) server-side architecture using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy if you want to get a little spicy and have good SSL and static serving performance, and an option for simple load balancing later. Oh and the only provisioning you get to do is individual VPSs or even better, bare metal on prem servers! Git and Jenkins is probably boring enough to use, though. But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3. Probably no CloudFlare. Google Analytics, sure, but only if you don't care about your users privacy. Sentry is too exciting. And then on the HTML side I'd argue that your templates should produce plain old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support for IE 11. And even for those languages you can cut out the most exciting features. Do you really need the "class" or "new" keywords in ES6? For JS modules, use the boring, built in browser module system (you knew it had one, right?![1]) 1 - https://caniuse.com/#feat=es6-module-dynamic-import https://caniuse.com/#feat=es6-module-dynamic-import
- baron816 6y ago
  React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have more overhead than using something more experimental like Elm or ReasonML. You should almost never use classes in JS, but when you do, they're much easier to work with and understand than defining properties on the prototype. The "new" keyword has been around since almost JS's inceptions (it's available in IE 3, which came out in 1996). Some of your technologies require no learning to start using (PostCSS). Some can require a whole new mental model/programming paradigm, but can be incredibly useful if used sparingly and in the right places (RxJS). And some things you just need to do to not have a garbage application (testing). Look, just make assessments as to what your needs are, what are common practices, what your current team is capable of being productive with, and what you're going to be able to hire from.
wp381640 6y ago
Welcome to the enterprise tech world - it's funny how hard-learned lessons are re-learned in startups the hard way.
- aaronbrethorst 6y ago
  Welcome to being older. It’s funny how hard-learned lessons are relearned by younger people the hard way.
  - Toine 6y ago
    Exception in thread "main" java.lang.StackOverflowError
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
hliyan 6y ago
Rapid progress and multiple options (like we have with front-end libraries, tool chains and cloud infrastructure) are great, if standardization (at least of the interfaces and vocabulary, if not the implementations) comes in their wake. Otherwise, only fragmentation, unpredictability and pain you will find. Edit: Just an hour ago I was learning Heroku (having primarily worked with AWS, Linode and bare-metal) and I found that they call a collection of Linux containers a dyno. So we have droplets (confession: never used these), pods, clusters and now dynos. If nothing else, should we not at least standardize the vocabulary?
- jakelazaroff 6y ago
  “Droplets” as in DigitalOcean? Those are literally just single virtualized servers — nothing fancy or property happening there, despite the cutesy name.
dmnd 6y ago
I'm constantly invoking this principle, but I have a small tweak: combine it with the (now anachronistically named) Python Paradox to get "use a tool from your toolbox". Restricting the number of different technologies in your toolbox gets you most of the benefits described in TFA. But contrary to "boring", it's actually preferable for some of those tools to be bleeding edge. That way you also get to enjoy the benefits of the Python Paradox. Of course, you need to have good enough taste to pick new techs, and sometimes the bleeding edge will cut you. But because you amortize that cut over the whole org it doesn't hurt much.
- brabel 6y ago
  > you need to have good enough taste to pick new techs... So you see tech as you see fashion, i.e it requires good taste?! When you choose a new tech, perhaps you should consider what problems it solves and whether its costs are worthwhile for you, not whether its a hot new fashionable thing to "wear" in parties (conferences).
  - dmnd 6y ago
    Tasteful ≠ trendy. By “good taste” I meant the ability to pick a technology you won’t regret later.
praveen9920 6y ago
We learned this lesson the hard way. A few years back, for a start-up, we picked angular 2.0 as our choice for frontend stack, when it is released. Though it was fun to develop it, We faced a lot of unknowns and issues to finally ship it. Too many changes for each version, The bundle size was too big. Angular SPAs were not great for SEOs etc. We ended up missing the shipping deadline by a couple of months. When you really want/have to `ship it`, pick any technology you and your team have delivered something before. When you have time to explore, pick any new shiny technology, and concentrate on learnings.
- winrid 6y ago
  Using Angular 8 and seems they fixed that if it was an issue. The bundle size is like 300kb without dependencies for a prod build, but I don't know what your requirements are. 300kb is a lot, but it's also a huge framework.
  - christophilus 6y ago
    Preact weighs in at 3kb. 300kb is a whole lot. I’ve written an entire SPA that is less than 300kb.
    - winrid 6y ago
      Yeah, Preact is tiny.
- ngngngng 6y ago
  I'm literally browsing hacker news right now to procrastinate work on an Angular task. I can't think of a less boring technology, I've been writing it for a couple years and it's still not simple to work with.
  - randombytes6869 6y ago
    Switch to React if you can. I've been using Angular for years and the solution to problems is generally "more magic". Its so convoluted these days I don't think its even realistic to build an Angular app outside of angular-cli.
archived22 6y ago
Job description these days become reflection of complexity in new age tech stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with Docker/K8 and with Azure/GCP/AWS. It is time consuming process to become expert of one thing, requires couple of years of continuous focus. I don't know How many people are actually expert of all these and how they are going to perform when some issue pop up in production. Try that judging it 30-to-60 minutes of interview.
- onion2k 6y ago
  I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed. You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long gone. Making modern web apps is a team sport. You literally can't be an expert in everything you need to build a robust, scalable, fast, accessible web app anymore.
  - archived22 6y ago
    Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience. They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech complexity. An idea or poc which could had been easily done and tested in market with small techstack/small team. No wonder lot of these products fail.
    - onion2k 6y ago
      They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything.. Anecdotally, in my 20+ years of working for website and web app companies, I have never had a client who has even suggested a specific way of implementing an app. The closest has been when a client has asked for a tech proposal and had it sanity checked by a third party. These days I mostly work on "rescuing" apps that a client has had built by one company, found it hasn't gone well, and has come to the company I work for to make it work properly. All of the crazy tech stack implementations I've seen have come from developers who think they're clever, and never the client demanding something trendy.
giza182 6y ago
Another reason for one to have side projects. With those, one has virtually an unlimited supply of innovation tokens to play with.
rooam-dev 6y ago
Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.
- darkwater 6y ago
  Nope, boring technology implies mature and tried enough ecosystem where the users community found out and know almost every failure scenario. Your team skills are not relevant in this definition, if a tech is "new" and "exciting".
  - rooam-dev 6y ago
    Indeed, team's experience is not relevant in the definition, however it's the main criteria to choose a [boring] tech, after the cost of course. To use/apply any tech or workflow depends on execution.
thesandi001 6y ago
Choosing boring tech ensures fastest GTM.
quickthrower2 6y ago
5 years later, NodeJS i'm using on a side project. I am assuming this is zero innovation tokens now!
raverbashing 6y ago
Yeah, this motto works. Until the "boring technology" breaks in your face or have a gotcha that everybody "forgets to mention" (which you might be able to work around, with various degrees of cleanliness). And I've seen it happen a couple of times.
- quintushoratius 6y ago
  ...and that's different from new, unproven technology how? Unproven technology has all that in spades.
nine_k 6y ago
I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choose exclusively among the top 5 most used in the field. The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company. A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.
- kitd 6y ago
  > YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.
  - beerbajay 6y ago
    The web has been around since the early 90's and Django was first released in 2005...
  - TheDong 6y ago
    The staples of the early web, in my mind, are html and perl CGI scripts. php might make the cut as early web, but web frameworks, like those in ruby and python, feel to me me much less like the early web, and much more like the web 2.0 days.
    - iso1210 6y ago
      Matts Script Archive was mid 90s. Mod perl maybe just squeezes into 'early web', I think /. used it in the late 90s. Perl wasn't the only CGI in the early days - a large internal web application I encountered as late as 2004 had it's CGIs written in C, running on IRIX PHP is certainly the newcomer as far as I'm concerned
at_a_remove 6y ago
I am all about the boring technology. I dislike the churn of learning something only to discard that knowledge in favor of something else a few months later. I would rather get better at the things I know how to do rather than learn how to do something new and hope to get proficient at it. It feels like time wasted, learning something that I know is disposable. I get it, in the end everything is disposable but I like to minimize that churn and polish what I have that works for me. It isn't as fashionable or as cool but I try to avoid those circles if I can.
peferron 6y ago
Also: please, please pay attention to the fundamental design decisions that underpin the technology you're choosing! Set aside the GitHub stars, contribution graphs and HN reviews, and boil the tech down to its fundamental principles. Then ask yourself how a perfect implementation of that design would solve your problems. It it solves them well, you're golden as long as the project is reasonably healthy. If it doesn't solve them well, you might be setting yourself up for serious pain down the line, and need to make a very conscious choice about whether the short-term benefits of that technology choice are worth it, and how an eventual migration to a better-fitting design would look like.
semicolonandson 6y ago
I've boot-strapped and lived from a web-application for over ten years, some of which have involved less than one day per month's worth of work. I credit this to boring technologies. Looking back, the best technical decisions were: - using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data. - emphasis on shell scripts and leaning on UNIX features (since these continue working in ten years rather than being abandoned) - deleting as many libraries and dependencies as practical (over a ten-year time frame, 80% will disappear or change in ways that require huge mental RAM on your behalf) - a preference for paying for hardware to solve performance issues (vs. complicating the code with fancy solutions) For anyone interested, I go into more detail in this video https://www.youtube.com/watch?v=rQegYUsU7ec https://www.youtube.com/watch?v=rQegYUsU7ec
- theshrike79 6y ago
  And vendor your dependencies if at all possible, that one library/tool you were using might just disappear of the internet. It will still work in 10 years if your toolchain hasn't changed much.
ngngngng 6y ago
I once overheard a conversation between two colleagues. "I'm not interested in learning Go because it doesn't have many compelling features" "That IS the feature"
- theshrike79 6y ago
  Having to build stuff from basic blocks with no hidden magic is the best part in Go. It's SO boring, but also very efficient. Yes, you type more words, but that's why you got the fancy clicky keyboard. You get stuff done and other people can actually understand your code, because there are no hidden gotchas, everything is just as you typed it out. Even the boring and repetitive if err != nil stuff just fades away, but you DO notice if it's missing somewhere.
  - xtracto 6y ago
    In 1999 when I finished my Bsc in Software Eng I loved to do my own tools instead of using stdlib or boost or other C libraries for the same reason. Now I value my time more and I prefer to focus on programming what gives value to the business I am building to.
    - theshrike79 6y ago
      Go isn't _that_ basic =) There are less abstractions to hide the costly operations.
scotty79 6y ago
I think the problem is that not all programmers are motivated by successfully building things. Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to. If you pick a 'boring' technology, you have less of those two things, and you are stuck with boring process of developing one feature after the other with boring technology until sufficient number is developed and you can go do something more interesting.
- pdimitar 6y ago
  I believe you are correct, at least judging by myself and several others I've talked with. We are creators and get bored of our creations pretty quickly. In that regard we aren't unlike painters or even book writers; something sparkles our interest, we work on it for a while but then we get tired of it and really want to do something else. That can easily be seen as unprofessional from the outside and I'd agree you shouldn't conduct yourself like that when there are money involved but that also leaves something to be said about the productivity of the tools we work with.
- non-entity 6y ago
  > I think the problem is that not all programmers are motivated by successfully building things. > Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to. I kinda realized this about myself recently, and now I'm wondering if I need to leave the field.
  - asddubs 6y ago
    just switch to doing javascript
    - scotty79 6y ago
      That's what I did. But in all seriousness. Software development does not only need builders. Builders build stuff well but at some point they make mistakes or overestimate their knowledge of technology. Then obsessive learners and investigators are godsend. Just know your limits and don't hope to do well at solo projects when you are in it for learning or bug hunting.
tjpnz 6y ago
This is something I've lived by for the majority of my career. I wish I could share in the excitement of my peers when they discover a new shiny thing and push really hard to have it incorporated, my inability to share in that excitement has even shaken my confidence at times. What's worse is that it has resulted in friction at some of the places I've worked, even more so when the issues I've raised end up biting us hard in production.
aww_dang 6y ago
I like to learn new things and solve new problems, but "Don't fix it if it isn't broken" are words to live by. Challenging myself with a new problem is rarely boring. So many new technologies seem like something new just for the sake of it. By the time they mature into something as practical as 'boring tech' they have many of the same pitfalls if not more. Perhaps many engineers lack agency in choosing the problems they solve, so they seek to change the tools they use instead?
dotemacs 6y ago
The author even has this whole site, which is essentially a slide deck: http://boringtechnology.club/ http://boringtechnology.club/ But even though he talks about "boring" tech, he did go on to have a startup, Skyliner, which was written in Clojure and subsequently acquired by Mailchimp. So I guess, you can't be using the borking stack all the time...
deleted 6y ago
[deleted]
loughnane 6y ago
When in doubt, make it stout out of stuff you know about.
systematical 6y ago
The most recent MVP I created: CakePHP, MySQL, jQuery (UI/UX called for minimal dynamic UI IMO), and bootstrap. Very boring full-scale MVP released in under three weeks. I designed as client-server in case the need arises to go SPA with React down the line or go with a mobile app option, but I doubt the need. Non-tech co-founder was worried from what he read on PHP etc.... Non-tech co-founder is not worried today.
leonardteo 6y ago
Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And this is real. I have dev friends who have left great jobs just because they wanted to move to some new tech and their company simply wasn't ready for the change yet. In the past I have been told that I "don't trust developers" (despite being one myself), and it has nothing to do with that. It's that some of us are left with the consequences of those decisions and having to maintain those NIH-riddled skeletons in the closet when those individuals leave - and the next person comes along, finds the skeletons and we end up having to rewrite/reimplement that whole part of the system. Creating an environment where we can thrive and be creative is really challenging. We've implemented the 20% time now where everyone in the company has 1 day a week to just experiment and do whatever they want, just to give the breathing room to be creative and try some of these new technologies. We finally got there. But for years, we just couldn't afford to do it as we were in survival mode. But the retention issue is still a big one. I feel the tension between having to empower people to make decisions that are for the greater good of the business, while balancing that those people can (and will) leave at any time and not face the consequences of those decisions. Curious to hear thoughts.
- granshaw 6y ago
  IMO giving Engineers “space to learn” and “work with new tech” is one of the greatest challenges any Engineering leader faces. I have a pet theory that the soa/micro services trend has in large part been driven by this problem - giving a space to work with such new tech with a limited blast radius, also at the expense of overall velocity and maintainability.
- praveen9920 6y ago
  If you are early stage start-up, all your employees including engineers should be onboarded with the idea rather than technology choice. If you have someone joined you for any reason other than the excitement for idea, there is higher chance that you will find them going off track too often and it will drag you back If you are mid-size company, I will assume that you can afford giving some breathing space for everyone to explore but still focus on the goal. You should ideally retain them with the culture. These are the suggestions based on my experience. I may be wrong.
LukeEF 6y ago
This thing is on a 6 month hacker news circuit. And front page every time. There is a psychological conceit in the backend about using tech 'that has 20 years of maturity' - that plays out with DBs more than anywhere else. 'Let the others do the innovation' seems to be the desire.
markus_zhang 6y ago
I actually get why engineers, especially young ones prefer new techs sometimes. Think it this way. You join a company and get two choices. One is to use a reliable albeit old system, read tons of legacy code and figure out how to do things other guys' way. The other is to build new things from ground up when you have a much bigger feeling of ownership, but risk breaking things up. Which one do you choose? Note that you are a junior engineer, not a lead, not an architect. Somewhat this is more like a class struggle instead of choosing the right tech.
- djmips 6y ago
  Every boring tech was once new and exciting at one time. Without someone taking a risk everything would be boring.
  - markus_zhang 6y ago
    Yeah exactly.
Haga 6y ago
You don't get to tell us how to run our Drilling companies!
nickysielicki 6y ago
One of the more frustrating things is that you can have a team that reads this article and all agree about the goal but disagree about what is actually boring and safe and worth doing. There are a lot of people who confuse “boring” with “well-known”, and they’re not the same thing. Example: you decide to write C++, but the C++ you write looks a lot like C99. You rationalize it as though you’re avoiding the overhead of all that nonsensical modern C++ and doing the simpler and thus more-boring thing. In reality: you’re writing shitty C++. For the technology you choose, you should buy into it. Full stop. Don’t half-ass it.
- hamilyon2 6y ago
  Your example is controversial. What if that C99 coding style is company-wide accepted and everyone is comfortable with it. On contrary, newer, more shiny thing, like c++20 is not supported in tools and adds significant mental overhead.
andersco 6y ago
This article reinforces one of the most important lessons I’ve learned as a developer - be careful, even suspicious of shiny new things - only after the sheen has faded after extensive use and they no longer are the new coolness is it usually safe to consider them for anything other than a toy project.
Animats 6y ago
The key point: "But more importantly, their (old technology) failure modes are well understood."
r0rshrk 6y ago
Ironic that Node is one of the boring choices nowadays.
ncmncm 6y ago
It's funny that he mentions Rumsfeld, without mentioning Rumsfeld's very public glaring omission that was ultimately responsible for everything that went wrong in Iraq. He cited "known knowns", "known unknowns", and "unknown unknowns", but completely missed the biggie, unknown knowns -- things you are convinced are true, but in fact are not. "It ain't what you don't know that gets you. It's the things you think you know that just aren't so." (Often mis-attributed to Mark Twain, but Josh Billings is a better choice.)
GavinHoltUK 6y ago
There are many parallels here for the selection of medical drugs and implants. Use treatments with a good evidence base, predictable outcomes and known complications (preferably with known solutions). Don't insist upon the latest new treatment, unless you fully accept the rôle of guinea pig - for better or worse!

459 points by dpcx 6y ago

Prior discussion from when the blog was originally written: https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 A related page I recall seeing on HN last summer: http://boringtechnology.club/ http://boringtechnology.club/

smabie 6y ago

If I use APL and Lisp, does that count as spending innovation tokens? Is boring technology old, or is it widely used? Most people I know don't consider J, kdb+/q, Haskell, or OCaml boring, but they are all awesome industrial strength languages/technologies.

jowiar 6y ago
I’ve found boring in this context to be a function of 3 things (in no particular order): - Your experience using the tool in question to solve this problem or very similar ones - Your teammates’ experience using the tool in question to solve this problem or very similar ones - The world’s experience using the tool in question to solve this problem or very similar ones The specific drivers of this tend to be a mix of problem-solving pattern matching ie “Hey, we know what the usual suspects are know when things are slow/crash”, and ecosystem robustness — what is the probability of you being the first to trip a bug in a dependency / has a library been used to solve 10000 problems or just 3 — It’s more likely that APIs have been sorted out, bugs have been closed, etc. or that your team knows the quirks. As an example, OCaml might be a relatively boring choice for writing a theorem prover, but for something like a RDBMS-backed web application, things are a lot more “interesting” as you go off the map much sooner.
deleted 6y ago
[deleted]
ma2rten 6y ago
I think it's the combination of mature and widely used. The company I worked at previously used Erlang. It caused a lot of headache in terms of finding well-supported database drivers and things like that.
invalidOrTaken 6y ago
Boring is boring---i.e., no surprises. Whether it's been tested by a lot of other people, a lot of years, or even just a lot of your time. APL is not boring to me, but it might be to you.

MattGaiser 6y ago

This makes sense until I need to find a new job in 18 months.

WrtCdEvrydy 6y ago
To be honest... someone who says 'I built it on something that already worked' is probably not that bad in today's market. There are three classes of companies: ones who haven't tried having a buffet of technologies, ones who already have and ones who are recovering.
adrianN 6y ago
I guess that depends on your specialization. If you build backend services with Java or C++ the job market is pretty big. Probably bigger than if you're a Go expert but don't know Java or C++.
bdcravens 6y ago
The risk of this attitude is that you may never get enough experience in a technology to approach expert level. If we're constantly reinventing the wheel, it means we never really have a chance to use that wheel to go anywhere.
m463 6y ago
It makes perfect sense if you want to work for Elon Musk under the streets of Hawthorne.
- MattGaiser 6y ago
  If you are doing firmware development, sure. If you check out their full stack development jobs, they want Go and TypeScript. https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4747757002 https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4...
  - m463 6y ago
    ha, I was referring to "the boring company"

aaronbrethorst 6y ago

Five years ago I posted a comment on this same article, which you can read at https://news.ycombinator.com/item?id=9291437 https://news.ycombinator.com/item?id=9291437 I still stand by everything I said in that comment, and it has served me incredibly well on every project I've worked on since. At least in the cases where I followed my own advice :-\ tl;dr: if you're trying to build and ship something quickly, don't use any new technology. If you want to use your project as an excuse to learn a new technology, limit yourself to only one technology so you can better isolate issues when they crop up.

barbs 6y ago

(2015)

deleted 6y ago

[deleted]

Throwaway8588 6y ago

Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.

hilbertseries 6y ago
Rust may be “hot” but there are far more Java jobs than Rust jobs and I highly doubt that’s going to change anytime soon. And indeed Java developers have been highly employed for quite some time.
- Throwaway8588 6y ago
  True, most transitions won’t be permanent but it really sucks to miss the ones that are (Angular and React eating everything).
- jghn 6y ago
  Agreed. I personally love the "hot" tech, but anyone claiming there are more jobs for those skills than the tried & trued is being disingenuous
  - MattGaiser 6y ago
    I think it depends on where you want to work. If you check out the YC job boards, they want TypeScript, Go, and GraphQL.
    - didibus 6y ago
      I've found in general the places that use Java don't look for a Java developer. Its like they just assume you can pick it up. You might see things like knowledge of OOP, SQL, etc. on the job listing. For example, lots of large companies like Google, Microsoft, Amazon, Twitter, Netflix, etc. have a ton of Java, but their job descriptions don't really mention it. On the other hand, if a place needs Typescript, or GO, they'll mention it.

noncoml 6y ago

I thought MongoDB and NodeJS are the boring technology today... Edit: Oh, it needs a (2015)

andi999 6y ago
All the tech there is not really boring. If you want boring take db2.
bob1029 6y ago
I don't think 5 years has done much of a favor for MongoDB. Boring in this context doesn't necessarily mean 'old' technology. It means technology that is so stable & reliable that you forget it's there. I can go weeks on end before being tangentially reminded that we use SQLite to store business entities. I am usually in the arena of business logic working with our various customers. This is what boring technology means to me. Stuff that "just works" and never causes you to spend any time worrying about it.
xtracto 6y ago
MongoDB is full of surprises, especially when it chews your data for no given reason or when its performance slows to a crawl. I'll take ye old PostgreSQL (with JSONB if I need unstructured data) or even mariadb.

l0b0 6y ago

As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the frontend and backend. Then there's infrastructure: pick at least three infrastructure as code components (Puppet/Chef/Ansible/k8s/Docker/Docker Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers (Apache/nginx/traefik/your language's built-in server), and at least two TLS certificate providers because someone's nervous about moving everything to Let's Encrypt. I'm well aware that these don't have identical feature sets, but that's the point of the article: choosing a small and boring set of technologies is an advantage, not something to be ashamed of.

gavinray 6y ago
I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you get Javascript/Typescript on the backend as well, so the entire stack is just JS/TS the whole way through with a single UI/design language. It was really easy to hire developers this way and the transferable skills were high. However you look at it, this is sort of the deal with JS these days. From a productivity and development velocity perspective, it's really difficult to rationalize using other technologies when you can just holistically build your entire stack in one JS/TS UI framework for the clients (or Flutter, nowadays) and then JS/TS on the backend too. This is why I'm mentally shoehorned into using Typescript for everything. I enjoy it a lot, but there are other languages I enjoy too, it just doesn't make as much sense to throw them in the mix because then you've increased technical complexity and made it that much more difficult to source talent.
- mettamage 6y ago
  Seconding this. I have the same experience.

javajosh 6y ago

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, PostCSS, TypeScript, React, Redux, RxJS, to be rather exciting, and that's only a few of the exciting parts of a mature SPA project. And of course this doesn't touch REST, GraphQL, CI/CD, testing, metrics, telemetry and all the other excitement. So, yeah, I would say that if you take the article seriously for a webapp, you'd limit yourself to a really boring Java (8) server-side architecture using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy if you want to get a little spicy and have good SSL and static serving performance, and an option for simple load balancing later. Oh and the only provisioning you get to do is individual VPSs or even better, bare metal on prem servers! Git and Jenkins is probably boring enough to use, though. But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3. Probably no CloudFlare. Google Analytics, sure, but only if you don't care about your users privacy. Sentry is too exciting. And then on the HTML side I'd argue that your templates should produce plain old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support for IE 11. And even for those languages you can cut out the most exciting features. Do you really need the "class" or "new" keywords in ES6? For JS modules, use the boring, built in browser module system (you knew it had one, right?![1]) 1 - https://caniuse.com/#feat=es6-module-dynamic-import https://caniuse.com/#feat=es6-module-dynamic-import

baron816 6y ago
React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have more overhead than using something more experimental like Elm or ReasonML. You should almost never use classes in JS, but when you do, they're much easier to work with and understand than defining properties on the prototype. The "new" keyword has been around since almost JS's inceptions (it's available in IE 3, which came out in 1996). Some of your technologies require no learning to start using (PostCSS). Some can require a whole new mental model/programming paradigm, but can be incredibly useful if used sparingly and in the right places (RxJS). And some things you just need to do to not have a garbage application (testing). Look, just make assessments as to what your needs are, what are common practices, what your current team is capable of being productive with, and what you're going to be able to hire from.

wp381640 6y ago

Welcome to the enterprise tech world - it's funny how hard-learned lessons are re-learned in startups the hard way.

aaronbrethorst 6y ago
Welcome to being older. It’s funny how hard-learned lessons are relearned by younger people the hard way.
- Toine 6y ago
  Exception in thread "main" java.lang.StackOverflowError

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

hliyan 6y ago

Rapid progress and multiple options (like we have with front-end libraries, tool chains and cloud infrastructure) are great, if standardization (at least of the interfaces and vocabulary, if not the implementations) comes in their wake. Otherwise, only fragmentation, unpredictability and pain you will find. Edit: Just an hour ago I was learning Heroku (having primarily worked with AWS, Linode and bare-metal) and I found that they call a collection of Linux containers a dyno. So we have droplets (confession: never used these), pods, clusters and now dynos. If nothing else, should we not at least standardize the vocabulary?

jakelazaroff 6y ago
“Droplets” as in DigitalOcean? Those are literally just single virtualized servers — nothing fancy or property happening there, despite the cutesy name.

dmnd 6y ago

I'm constantly invoking this principle, but I have a small tweak: combine it with the (now anachronistically named) Python Paradox to get "use a tool from your toolbox". Restricting the number of different technologies in your toolbox gets you most of the benefits described in TFA. But contrary to "boring", it's actually preferable for some of those tools to be bleeding edge. That way you also get to enjoy the benefits of the Python Paradox. Of course, you need to have good enough taste to pick new techs, and sometimes the bleeding edge will cut you. But because you amortize that cut over the whole org it doesn't hurt much.

brabel 6y ago
> you need to have good enough taste to pick new techs... So you see tech as you see fashion, i.e it requires good taste?! When you choose a new tech, perhaps you should consider what problems it solves and whether its costs are worthwhile for you, not whether its a hot new fashionable thing to "wear" in parties (conferences).
- dmnd 6y ago
  Tasteful ≠ trendy. By “good taste” I meant the ability to pick a technology you won’t regret later.

praveen9920 6y ago

We learned this lesson the hard way. A few years back, for a start-up, we picked angular 2.0 as our choice for frontend stack, when it is released. Though it was fun to develop it, We faced a lot of unknowns and issues to finally ship it. Too many changes for each version, The bundle size was too big. Angular SPAs were not great for SEOs etc. We ended up missing the shipping deadline by a couple of months. When you really want/have to `ship it`, pick any technology you and your team have delivered something before. When you have time to explore, pick any new shiny technology, and concentrate on learnings.

winrid 6y ago
Using Angular 8 and seems they fixed that if it was an issue. The bundle size is like 300kb without dependencies for a prod build, but I don't know what your requirements are. 300kb is a lot, but it's also a huge framework.
- christophilus 6y ago
  Preact weighs in at 3kb. 300kb is a whole lot. I’ve written an entire SPA that is less than 300kb.
  - winrid 6y ago
    Yeah, Preact is tiny.
ngngngng 6y ago
I'm literally browsing hacker news right now to procrastinate work on an Angular task. I can't think of a less boring technology, I've been writing it for a couple years and it's still not simple to work with.
- randombytes6869 6y ago
  Switch to React if you can. I've been using Angular for years and the solution to problems is generally "more magic". Its so convoluted these days I don't think its even realistic to build an Angular app outside of angular-cli.

archived22 6y ago

Job description these days become reflection of complexity in new age tech stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with Docker/K8 and with Azure/GCP/AWS. It is time consuming process to become expert of one thing, requires couple of years of continuous focus. I don't know How many people are actually expert of all these and how they are going to perform when some issue pop up in production. Try that judging it 30-to-60 minutes of interview.

onion2k 6y ago
I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed. You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long gone. Making modern web apps is a team sport. You literally can't be an expert in everything you need to build a robust, scalable, fast, accessible web app anymore.
- archived22 6y ago
  Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience. They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech complexity. An idea or poc which could had been easily done and tested in market with small techstack/small team. No wonder lot of these products fail.
  - onion2k 6y ago
    They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything.. Anecdotally, in my 20+ years of working for website and web app companies, I have never had a client who has even suggested a specific way of implementing an app. The closest has been when a client has asked for a tech proposal and had it sanity checked by a third party. These days I mostly work on "rescuing" apps that a client has had built by one company, found it hasn't gone well, and has come to the company I work for to make it work properly. All of the crazy tech stack implementations I've seen have come from developers who think they're clever, and never the client demanding something trendy.

giza182 6y ago

Another reason for one to have side projects. With those, one has virtually an unlimited supply of innovation tokens to play with.

rooam-dev 6y ago

Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.

darkwater 6y ago
Nope, boring technology implies mature and tried enough ecosystem where the users community found out and know almost every failure scenario. Your team skills are not relevant in this definition, if a tech is "new" and "exciting".
- rooam-dev 6y ago
  Indeed, team's experience is not relevant in the definition, however it's the main criteria to choose a [boring] tech, after the cost of course. To use/apply any tech or workflow depends on execution.

thesandi001 6y ago

Choosing boring tech ensures fastest GTM.

quickthrower2 6y ago

5 years later, NodeJS i'm using on a side project. I am assuming this is zero innovation tokens now!

raverbashing 6y ago

Yeah, this motto works. Until the "boring technology" breaks in your face or have a gotcha that everybody "forgets to mention" (which you might be able to work around, with various degrees of cleanliness). And I've seen it happen a couple of times.

quintushoratius 6y ago
...and that's different from new, unproven technology how? Unproven technology has all that in spades.

nine_k 6y ago

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choose exclusively among the top 5 most used in the field. The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company. A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.

kitd 6y ago
> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.
- beerbajay 6y ago
  The web has been around since the early 90's and Django was first released in 2005...
- TheDong 6y ago
  The staples of the early web, in my mind, are html and perl CGI scripts. php might make the cut as early web, but web frameworks, like those in ruby and python, feel to me me much less like the early web, and much more like the web 2.0 days.
  - iso1210 6y ago
    Matts Script Archive was mid 90s. Mod perl maybe just squeezes into 'early web', I think /. used it in the late 90s. Perl wasn't the only CGI in the early days - a large internal web application I encountered as late as 2004 had it's CGIs written in C, running on IRIX PHP is certainly the newcomer as far as I'm concerned

at_a_remove 6y ago

I am all about the boring technology. I dislike the churn of learning something only to discard that knowledge in favor of something else a few months later. I would rather get better at the things I know how to do rather than learn how to do something new and hope to get proficient at it. It feels like time wasted, learning something that I know is disposable. I get it, in the end everything is disposable but I like to minimize that churn and polish what I have that works for me. It isn't as fashionable or as cool but I try to avoid those circles if I can.

peferron 6y ago

Also: please, please pay attention to the fundamental design decisions that underpin the technology you're choosing! Set aside the GitHub stars, contribution graphs and HN reviews, and boil the tech down to its fundamental principles. Then ask yourself how a perfect implementation of that design would solve your problems. It it solves them well, you're golden as long as the project is reasonably healthy. If it doesn't solve them well, you might be setting yourself up for serious pain down the line, and need to make a very conscious choice about whether the short-term benefits of that technology choice are worth it, and how an eventual migration to a better-fitting design would look like.

semicolonandson 6y ago

I've boot-strapped and lived from a web-application for over ten years, some of which have involved less than one day per month's worth of work. I credit this to boring technologies. Looking back, the best technical decisions were: - using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data. - emphasis on shell scripts and leaning on UNIX features (since these continue working in ten years rather than being abandoned) - deleting as many libraries and dependencies as practical (over a ten-year time frame, 80% will disappear or change in ways that require huge mental RAM on your behalf) - a preference for paying for hardware to solve performance issues (vs. complicating the code with fancy solutions) For anyone interested, I go into more detail in this video https://www.youtube.com/watch?v=rQegYUsU7ec https://www.youtube.com/watch?v=rQegYUsU7ec

theshrike79 6y ago
And vendor your dependencies if at all possible, that one library/tool you were using might just disappear of the internet. It will still work in 10 years if your toolchain hasn't changed much.

ngngngng 6y ago

I once overheard a conversation between two colleagues. "I'm not interested in learning Go because it doesn't have many compelling features" "That IS the feature"

theshrike79 6y ago
Having to build stuff from basic blocks with no hidden magic is the best part in Go. It's SO boring, but also very efficient. Yes, you type more words, but that's why you got the fancy clicky keyboard. You get stuff done and other people can actually understand your code, because there are no hidden gotchas, everything is just as you typed it out. Even the boring and repetitive if err != nil stuff just fades away, but you DO notice if it's missing somewhere.
- xtracto 6y ago
  In 1999 when I finished my Bsc in Software Eng I loved to do my own tools instead of using stdlib or boost or other C libraries for the same reason. Now I value my time more and I prefer to focus on programming what gives value to the business I am building to.
  - theshrike79 6y ago
    Go isn't _that_ basic =) There are less abstractions to hide the costly operations.

scotty79 6y ago

I think the problem is that not all programmers are motivated by successfully building things. Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to. If you pick a 'boring' technology, you have less of those two things, and you are stuck with boring process of developing one feature after the other with boring technology until sufficient number is developed and you can go do something more interesting.

pdimitar 6y ago
I believe you are correct, at least judging by myself and several others I've talked with. We are creators and get bored of our creations pretty quickly. In that regard we aren't unlike painters or even book writers; something sparkles our interest, we work on it for a while but then we get tired of it and really want to do something else. That can easily be seen as unprofessional from the outside and I'd agree you shouldn't conduct yourself like that when there are money involved but that also leaves something to be said about the productivity of the tools we work with.
non-entity 6y ago
> I think the problem is that not all programmers are motivated by successfully building things. > Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to. I kinda realized this about myself recently, and now I'm wondering if I need to leave the field.
- asddubs 6y ago
  just switch to doing javascript
  - scotty79 6y ago
    That's what I did. But in all seriousness. Software development does not only need builders. Builders build stuff well but at some point they make mistakes or overestimate their knowledge of technology. Then obsessive learners and investigators are godsend. Just know your limits and don't hope to do well at solo projects when you are in it for learning or bug hunting.

tjpnz 6y ago

This is something I've lived by for the majority of my career. I wish I could share in the excitement of my peers when they discover a new shiny thing and push really hard to have it incorporated, my inability to share in that excitement has even shaken my confidence at times. What's worse is that it has resulted in friction at some of the places I've worked, even more so when the issues I've raised end up biting us hard in production.

aww_dang 6y ago

I like to learn new things and solve new problems, but "Don't fix it if it isn't broken" are words to live by. Challenging myself with a new problem is rarely boring. So many new technologies seem like something new just for the sake of it. By the time they mature into something as practical as 'boring tech' they have many of the same pitfalls if not more. Perhaps many engineers lack agency in choosing the problems they solve, so they seek to change the tools they use instead?

dotemacs 6y ago

The author even has this whole site, which is essentially a slide deck: http://boringtechnology.club/ http://boringtechnology.club/ But even though he talks about "boring" tech, he did go on to have a startup, Skyliner, which was written in Clojure and subsequently acquired by Mailchimp. So I guess, you can't be using the borking stack all the time...

deleted 6y ago

[deleted]

loughnane 6y ago

When in doubt, make it stout out of stuff you know about.

systematical 6y ago

The most recent MVP I created: CakePHP, MySQL, jQuery (UI/UX called for minimal dynamic UI IMO), and bootstrap. Very boring full-scale MVP released in under three weeks. I designed as client-server in case the need arises to go SPA with React down the line or go with a mobile app option, but I doubt the need. Non-tech co-founder was worried from what he read on PHP etc.... Non-tech co-founder is not worried today.

leonardteo 6y ago

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And this is real. I have dev friends who have left great jobs just because they wanted to move to some new tech and their company simply wasn't ready for the change yet. In the past I have been told that I "don't trust developers" (despite being one myself), and it has nothing to do with that. It's that some of us are left with the consequences of those decisions and having to maintain those NIH-riddled skeletons in the closet when those individuals leave - and the next person comes along, finds the skeletons and we end up having to rewrite/reimplement that whole part of the system. Creating an environment where we can thrive and be creative is really challenging. We've implemented the 20% time now where everyone in the company has 1 day a week to just experiment and do whatever they want, just to give the breathing room to be creative and try some of these new technologies. We finally got there. But for years, we just couldn't afford to do it as we were in survival mode. But the retention issue is still a big one. I feel the tension between having to empower people to make decisions that are for the greater good of the business, while balancing that those people can (and will) leave at any time and not face the consequences of those decisions. Curious to hear thoughts.

granshaw 6y ago
IMO giving Engineers “space to learn” and “work with new tech” is one of the greatest challenges any Engineering leader faces. I have a pet theory that the soa/micro services trend has in large part been driven by this problem - giving a space to work with such new tech with a limited blast radius, also at the expense of overall velocity and maintainability.
praveen9920 6y ago
If you are early stage start-up, all your employees including engineers should be onboarded with the idea rather than technology choice. If you have someone joined you for any reason other than the excitement for idea, there is higher chance that you will find them going off track too often and it will drag you back If you are mid-size company, I will assume that you can afford giving some breathing space for everyone to explore but still focus on the goal. You should ideally retain them with the culture. These are the suggestions based on my experience. I may be wrong.

LukeEF 6y ago

This thing is on a 6 month hacker news circuit. And front page every time. There is a psychological conceit in the backend about using tech 'that has 20 years of maturity' - that plays out with DBs more than anywhere else. 'Let the others do the innovation' seems to be the desire.

markus_zhang 6y ago

I actually get why engineers, especially young ones prefer new techs sometimes. Think it this way. You join a company and get two choices. One is to use a reliable albeit old system, read tons of legacy code and figure out how to do things other guys' way. The other is to build new things from ground up when you have a much bigger feeling of ownership, but risk breaking things up. Which one do you choose? Note that you are a junior engineer, not a lead, not an architect. Somewhat this is more like a class struggle instead of choosing the right tech.

djmips 6y ago
Every boring tech was once new and exciting at one time. Without someone taking a risk everything would be boring.
- markus_zhang 6y ago
  Yeah exactly.

Haga 6y ago

You don't get to tell us how to run our Drilling companies!

nickysielicki 6y ago

One of the more frustrating things is that you can have a team that reads this article and all agree about the goal but disagree about what is actually boring and safe and worth doing. There are a lot of people who confuse “boring” with “well-known”, and they’re not the same thing. Example: you decide to write C++, but the C++ you write looks a lot like C99. You rationalize it as though you’re avoiding the overhead of all that nonsensical modern C++ and doing the simpler and thus more-boring thing. In reality: you’re writing shitty C++. For the technology you choose, you should buy into it. Full stop. Don’t half-ass it.

hamilyon2 6y ago
Your example is controversial. What if that C99 coding style is company-wide accepted and everyone is comfortable with it. On contrary, newer, more shiny thing, like c++20 is not supported in tools and adds significant mental overhead.

andersco 6y ago

This article reinforces one of the most important lessons I’ve learned as a developer - be careful, even suspicious of shiny new things - only after the sheen has faded after extensive use and they no longer are the new coolness is it usually safe to consider them for anything other than a toy project.

Animats 6y ago

The key point: "But more importantly, their (old technology) failure modes are well understood."

r0rshrk 6y ago

Ironic that Node is one of the boring choices nowadays.

ncmncm 6y ago

It's funny that he mentions Rumsfeld, without mentioning Rumsfeld's very public glaring omission that was ultimately responsible for everything that went wrong in Iraq. He cited "known knowns", "known unknowns", and "unknown unknowns", but completely missed the biggie, unknown knowns -- things you are convinced are true, but in fact are not. "It ain't what you don't know that gets you. It's the things you think you know that just aren't so." (Often mis-attributed to Mark Twain, but Josh Billings is a better choice.)

GavinHoltUK 6y ago

There are many parallels here for the selection of medical drugs and implants. Use treatments with a good evidence base, predictable outcomes and known complications (preferably with known solutions). Don't insist upon the latest new treatment, unless you fully accept the rôle of guinea pig - for better or worse!