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.
This is pretty much spot on. People usually missing the point of 'boring' because they would think of unpleasant and ancient stuff.
The key value is indeed to avoid surprises.
When I read WhatsApp used Erlang back in the day, I was pretty impressed. Not only the obvious things like Erlang was the forgotten secret weapon for massive concurrent apps, but also details like they used FreeBSD back in the day when there was no preemptive scheduling but Erlang has preemptive scheduling so it was okay. Those details reflect they were very confident and they know perfectly what they were doing.
There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die.
In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes.
* Created in 1995 and is a very mature platform
* Easy to learn and productive
* I was very comfortable hiring multiple ColdFusion engineers over the years
But, the community moved on and the tooling is now nonexistent compared to other programming languages. ColdFusion will live on, but as a shadow of what it once was. Which is unfortunate because I actually enjoyed the language and platform.
> YouTube was (and still largely is) written in Python, way before it was cool and well-known
That's a good point. I wonder how many successful apps used tech that only appeared boring after the fact. Rails is a fairly boring stack today but back when GitHub started, it probably wasn't.
If you know you need to cut a hundred trees to foot-long logs in a certain time-frame, you don't pick the new fancy gadget you just got from Kickstarter. You know, the one with a WiFi notification system and a cloud SaaS service etc.
You go with a regular hand-saw, axe and a proper chainsaw. You'll get your stuff done - on time and on budget. You might not get the thrill of using the latest and greatest tools, but you'll get paid.
After that you can grab the Solar/Hydrogen-powered Indiegogo-funded whizbang and go test in on a tree or two on your own time.
People use "boring" in opposition to "hyped" or "trendy", which like you said totally misses the point. I jumped on react right away when it came out, but not because of it being trendy, but because like you said I could be productive with it right way, I knew it'd be around for 5+ years and that I could hire engineers.
Agreed. I find "boring" to be an unreliable metric for decision-making in software. A boring tool could result in damage to the long term development of software if it is inflexible, for example. Migrations between tools are easily some of the most expensive technical debt costs any software organization may face.
I also agree that the better measurement of good software is that which is unsurprising. Code should be easy to follow, and the decisions for the software tools that are used should be given the same treatment. You should be able to explain your code or infra to most developers without any raised eyebrows. That doesn't make it boring. In fact, it's very interesting when a problem that looks complex on the surface can be solved by relatable means.
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.
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.
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.
>"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."
That's fine, let them go. There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home. The stack doesn't really matter. The "mission" doesn't really matter. Even the product barely matters. I've found that people who are leaving a job for the new shiny thing are either very early career, or the dilettantes who leave behind messes to be cleaned up by professionals.
Massive companies have been built around a Spring/Rails/Zend monolith with a few jQuery plugins on the frontend. Anyone who thinks they need more than that is probably wrong.
Can I be honest? I fucking hate developers. We're like magpies of the worst variety. How many times have I had to argue against bringing in ${NEW_TECH} or ${NEW_TECHNIQUE} because it would be more trouble than its worth. No, it doesn't look as cool engineering-wise, and yes, our work may be a little harder because of it. But then they win the argument and we implement it and hey! Those problems I told you about? They're real! And if they had done it my way we could have moved on to the next thing and not had to worry about this.
Fuck the latest thing. Fuck resume driven development. Fuck magpies. Choose the boring path. Fuck developers!
The worst thing we do is obsess over the latest, coolest tech. Everyone is stepping on their brothers and sisters in this field because they want to be the loser that invented ${NEW_TECH}. We spend so much time optimizing for 'developer happiness' (a.k.a. the new shiny thing) that we forget about architecture.
I went through this recently when I joined a company and a small team to do a particular overhauling project. One of the developers was relatively junior, but smart, driven, and in love with shiny new tech. For the particular piece he worked on he chose modern solutions that went a bit out of the companywide envelope. I figured it's fine since if we forced the "boring" company-standard set of technologies he might get bored and leave. Well guess what, he left anyway and now we're left holding the bag. All custom stuff that could have easily been reused: scheduler, base container, code generation, language. So I guess my big takeaway is, regarding retention, they may leave anyway. If you're going to open the "new tech faucet" to slow that down, keeping it sequestered may be worthwhile.
I've seen an internal tool at a previous company that seemed to be built similarly by developers who wanted to try new tech. A pretty fancy RoR with a lot of custom changes and integrations. I am sure they had a ton of fun building it, but again, guess what, they were all already gone by the time I started there. And those who stayed hated that code base with a passion because it was near impossible to upgrade, so now we were stuck on an ancient RoR version, and since it was integrated with a lot of other systems it blocked those upgrades as well. Cautionary tale I guess.
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.
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.
I think introducing new tech is fine as long as it solves a new problem for your business. If you haven’t yet used a cache, but have a need for one, introducing Redis or Memcached makes sense. If you have a new need for pub/sub workflows, introducing Kafka or a webhook dispatcher makes sense. Same with Elasticsearch or whatever if you’re building out your first search feature, etc.
What rarely makes sense is introducing new tech that heavily overlaps with existing tech. You don’t wanna end up on MySQL and Postgres and Mongo. Python and PHP and Go. Django and Flask. EC2 autoscaling and Mesos and Kubernetes. Even worse, you definitely don’t wanna start building your own versions of tech that there’s a good off the shelf solution for. If someone tries to build their own UI framework, ORM, service discovery system, etc., kill that IMMEDIATELY.
Introducing new tech that overlaps with existing tech should only be done if you’re going to migrate OFF the existing tech. Obviously this is often a major effort, so the new tech has to be a HUGE win.
My current company was pretty immature for a long time in terms of tech decisions, and the costs are massive. For service-to-service communication we use REST, gRPC and this terrible in-house re-implementation of HTTP over ZeroMQ, complete with hand written clients and server frameworks in multiple languages. We’ve been trying to migrate off that for ages, at massive cost. We’re almost done, but even then will still be stuck with both HTTP and gRPC, when we only need one. Similarly, we use PHP, Scala, Go and Python on the backend. With multiple server frameworks for each. We use MongoDB and MySQL. Redis and Memcached.
The cost of all this is massive. Developers have to learn SO much to be productive in our stack(s). Every time we want to write some middleware, tooling, etc., we have to write like 15 versions of it, because we have about 15 unique combos of backend language/network protocol/framework. Losing a few immature devs who care more about using shiny new tech than solving business problems is a very, very small cost to pay to avoid this situation.
Ironically I was watching a talk on youtube yesterday by Richard Feldman of NoRedInk[0] that was basically explaining why and how they implemented Elm in production. The most interesting part of the talk to me was how he said it shaped their recruitment pipeline, going from needing recruiters to basically having it full and they can take their pick, and this mostly due to the fact that they were willing to use newer technology stacks. So the long and the short of it is I think you're right, this would affect retention and probably recruiting as well.
I'm a new developer looking for my first job and so I'm making side project to learn in the meantime and what I primarily want from a job is the ability to increase my skills, to get better and to improve, I feel like the kinds of places that are willing and able to experiment will not only have more of a learning culture but will attract others like that as well, so they are more attractive to me as a developer. I imagine this could be countered by things like proper mentor-ship programs or side project time like you've already implemented.
Be happy to see them go. They are the wrong developers for you to employ. Their focus is all about self-indulgence and not on creating a viable long-term business. Don't ever hire anybody who calls them self a "ninja developer" or equivalent. Instead, ask them to send in their CV again when they are grown up.
I'm against letting juniors or random devs introducing stuff you don't want to maintain in to your codebase for the sake of using the latest fad tech, chances are they will leave anyway and you will be left holding their mess. If they know what they are doing (ie. you hired someone with experience in stack Y and they want to help you migrate) then I'd say go for it if you can afford it. But picking a "safe but boring" stack puts you in the same hiring pool as everyone else picking that stack - can you compete on other terms to attract employees ?
Let's say you decided to write a webapp a few years back when RoR and AngularJS/CoffeScript was the popular stack. You wanted to write it in Clojure but you though "I can't hire Clojure devs reliably and RoR is popular so let's go with that". You are a small business/not high growth - you grow your app steadily - you now have a sizeable codebase on a legacy code stack that nobody really wants to touch or learn, there are plenty of job openings on that stack you have to compete with. Meanwhile people enthusiastic about Clojure were probably above average developers who would be happy to take below market rates just to work on a stack they enjoy and you could easily find people even today.
In a market where demand outpaces supply I'd say the "safe stack" is not a correct choice for small companies - if you have the know-how to pull off something more cutting edge. If you don't then ofc. use what you can to get the job done.
You cannot ignore all progress, but not all motion is progress.
Technology selection is a very underappreciated and largely unreported skill set.
I think it relates to the Principle of Least Surprise. You can pick tech that has a lot of upside and isn't riddled with gotchas or demanding of eternal vigilance, or you can pick stuff that makes you feel like you're alive all the time.
The latter is risk-taking behavior. It's thrill-seeking. Several other replies exhibit disdain for this behavior, as I think we all should. These people are risking your company for cheap thrills. As one responder puts it, fuck 'em.
Ask them live support your app, esp code they didn't write. Or some kind of dev log from the ops people hunting down their bugs. Tricky fun frameworks then become a pita.
I am in the same situation as you. My plan is to build the best personal growth organization that I can. Developers who value that and long-term growth should want to stick around. Developers who want something shiny can look elsewhere.
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)
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])
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
“Droplets” as in DigitalOcean? Those are literally just single virtualized servers — nothing fancy or property happening there, despite the cutesy name.
[+] [-] nine_k|5 years ago|reply
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.
[+] [-] namelosw|5 years ago|reply
The key value is indeed to avoid surprises.
When I read WhatsApp used Erlang back in the day, I was pretty impressed. Not only the obvious things like Erlang was the forgotten secret weapon for massive concurrent apps, but also details like they used FreeBSD back in the day when there was no preemptive scheduling but Erlang has preemptive scheduling so it was okay. Those details reflect they were very confident and they know perfectly what they were doing.
[+] [-] robert_g|5 years ago|reply
In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes.
* Created in 1995 and is a very mature platform
* Easy to learn and productive
* I was very comfortable hiring multiple ColdFusion engineers over the years
But, the community moved on and the tooling is now nonexistent compared to other programming languages. ColdFusion will live on, but as a shadow of what it once was. Which is unfortunate because I actually enjoyed the language and platform.
[+] [-] _hardwaregeek|5 years ago|reply
That's a good point. I wonder how many successful apps used tech that only appeared boring after the fact. Rails is a fairly boring stack today but back when GitHub started, it probably wasn't.
[+] [-] theshrike79|5 years ago|reply
If you know you need to cut a hundred trees to foot-long logs in a certain time-frame, you don't pick the new fancy gadget you just got from Kickstarter. You know, the one with a WiFi notification system and a cloud SaaS service etc.
You go with a regular hand-saw, axe and a proper chainsaw. You'll get your stuff done - on time and on budget. You might not get the thrill of using the latest and greatest tools, but you'll get paid.
After that you can grab the Solar/Hydrogen-powered Indiegogo-funded whizbang and go test in on a tree or two on your own time.
[+] [-] gcoguiec|5 years ago|reply
[+] [-] d0m|5 years ago|reply
[+] [-] zpallin|5 years ago|reply
I also agree that the better measurement of good software is that which is unsurprising. Code should be easy to follow, and the decisions for the software tools that are used should be given the same treatment. You should be able to explain your code or infra to most developers without any raised eyebrows. That doesn't make it boring. In fact, it's very interesting when a problem that looks complex on the surface can be solved by relatable means.
[+] [-] kitd|5 years ago|reply
I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.
[+] [-] djmips|5 years ago|reply
[+] [-] lazyant|5 years ago|reply
[+] [-] limomium|5 years ago|reply
[+] [-] tarkin2|5 years ago|reply
[+] [-] l0b0|5 years ago|reply
[+] [-] gavinray|5 years ago|reply
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.
[+] [-] leonardteo|5 years ago|reply
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.
[+] [-] aphextron|5 years ago|reply
That's fine, let them go. There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home. The stack doesn't really matter. The "mission" doesn't really matter. Even the product barely matters. I've found that people who are leaving a job for the new shiny thing are either very early career, or the dilettantes who leave behind messes to be cleaned up by professionals.
Massive companies have been built around a Spring/Rails/Zend monolith with a few jQuery plugins on the frontend. Anyone who thinks they need more than that is probably wrong.
[+] [-] tomc1985|5 years ago|reply
Fuck the latest thing. Fuck resume driven development. Fuck magpies. Choose the boring path. Fuck developers!
The worst thing we do is obsess over the latest, coolest tech. Everyone is stepping on their brothers and sisters in this field because they want to be the loser that invented ${NEW_TECH}. We spend so much time optimizing for 'developer happiness' (a.k.a. the new shiny thing) that we forget about architecture.
I am so sick of this field.
[+] [-] foobarian|5 years ago|reply
I've seen an internal tool at a previous company that seemed to be built similarly by developers who wanted to try new tech. A pretty fancy RoR with a lot of custom changes and integrations. I am sure they had a ton of fun building it, but again, guess what, they were all already gone by the time I started there. And those who stayed hated that code base with a passion because it was near impossible to upgrade, so now we were stuck on an ancient RoR version, and since it was integrated with a lot of other systems it blocked those upgrades as well. Cautionary tale I guess.
[+] [-] granshaw|5 years ago|reply
[+] [-] praveen9920|5 years ago|reply
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.
[+] [-] yashap|5 years ago|reply
I think introducing new tech is fine as long as it solves a new problem for your business. If you haven’t yet used a cache, but have a need for one, introducing Redis or Memcached makes sense. If you have a new need for pub/sub workflows, introducing Kafka or a webhook dispatcher makes sense. Same with Elasticsearch or whatever if you’re building out your first search feature, etc.
What rarely makes sense is introducing new tech that heavily overlaps with existing tech. You don’t wanna end up on MySQL and Postgres and Mongo. Python and PHP and Go. Django and Flask. EC2 autoscaling and Mesos and Kubernetes. Even worse, you definitely don’t wanna start building your own versions of tech that there’s a good off the shelf solution for. If someone tries to build their own UI framework, ORM, service discovery system, etc., kill that IMMEDIATELY.
Introducing new tech that overlaps with existing tech should only be done if you’re going to migrate OFF the existing tech. Obviously this is often a major effort, so the new tech has to be a HUGE win.
My current company was pretty immature for a long time in terms of tech decisions, and the costs are massive. For service-to-service communication we use REST, gRPC and this terrible in-house re-implementation of HTTP over ZeroMQ, complete with hand written clients and server frameworks in multiple languages. We’ve been trying to migrate off that for ages, at massive cost. We’re almost done, but even then will still be stuck with both HTTP and gRPC, when we only need one. Similarly, we use PHP, Scala, Go and Python on the backend. With multiple server frameworks for each. We use MongoDB and MySQL. Redis and Memcached.
The cost of all this is massive. Developers have to learn SO much to be productive in our stack(s). Every time we want to write some middleware, tooling, etc., we have to write like 15 versions of it, because we have about 15 unique combos of backend language/network protocol/framework. Losing a few immature devs who care more about using shiny new tech than solving business problems is a very, very small cost to pay to avoid this situation.
[+] [-] michaelbrave|5 years ago|reply
I'm a new developer looking for my first job and so I'm making side project to learn in the meantime and what I primarily want from a job is the ability to increase my skills, to get better and to improve, I feel like the kinds of places that are willing and able to experiment will not only have more of a learning culture but will attract others like that as well, so they are more attractive to me as a developer. I imagine this could be countered by things like proper mentor-ship programs or side project time like you've already implemented.
[0]https://www.youtube.com/watch?v=5CYeZ2kEiOI
[+] [-] mbrodersen|5 years ago|reply
[+] [-] rubber_duck|5 years ago|reply
Let's say you decided to write a webapp a few years back when RoR and AngularJS/CoffeScript was the popular stack. You wanted to write it in Clojure but you though "I can't hire Clojure devs reliably and RoR is popular so let's go with that". You are a small business/not high growth - you grow your app steadily - you now have a sizeable codebase on a legacy code stack that nobody really wants to touch or learn, there are plenty of job openings on that stack you have to compete with. Meanwhile people enthusiastic about Clojure were probably above average developers who would be happy to take below market rates just to work on a stack they enjoy and you could easily find people even today.
In a market where demand outpaces supply I'd say the "safe stack" is not a correct choice for small companies - if you have the know-how to pull off something more cutting edge. If you don't then ofc. use what you can to get the job done.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] hinkley|5 years ago|reply
Technology selection is a very underappreciated and largely unreported skill set.
I think it relates to the Principle of Least Surprise. You can pick tech that has a lot of upside and isn't riddled with gotchas or demanding of eternal vigilance, or you can pick stuff that makes you feel like you're alive all the time.
The latter is risk-taking behavior. It's thrill-seeking. Several other replies exhibit disdain for this behavior, as I think we all should. These people are risking your company for cheap thrills. As one responder puts it, fuck 'em.
[+] [-] drwiggly|5 years ago|reply
[+] [-] satya71|5 years ago|reply
[+] [-] semicolonandson|5 years ago|reply
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
[+] [-] theshrike79|5 years ago|reply
It will still work in 10 years if your toolchain hasn't changed much.
[+] [-] javajosh|5 years ago|reply
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
[+] [-] peferron|5 years ago|reply
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.
[+] [-] archived22|5 years ago|reply
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.
[+] [-] whymauri|5 years ago|reply
https://news.ycombinator.com/item?id=9291215
A related page I recall seeing on HN last summer:
http://boringtechnology.club/
[+] [-] nickysielicki|5 years ago|reply
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.
[+] [-] scotty79|5 years ago|reply
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.
[+] [-] praveen9920|5 years ago|reply
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.
[+] [-] ngngngng|5 years ago|reply
[+] [-] winrid|5 years ago|reply
300kb is a lot, but it's also a huge framework.
[+] [-] noncoml|5 years ago|reply
Edit: Oh, it needs a (2015)
[+] [-] at_a_remove|5 years ago|reply
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.
[+] [-] LukeEF|5 years ago|reply
[+] [-] markus_zhang|5 years ago|reply
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.
[+] [-] tjpnz|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] systematical|5 years ago|reply
Non-tech co-founder was worried from what he read on PHP etc.... Non-tech co-founder is not worried today.
[+] [-] smabie|5 years ago|reply
[+] [-] hliyan|5 years ago|reply
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|5 years ago|reply