One of the things that I'm passionate about is that at the end of the day, customers don't really care what your tech stack is, as long as you deli...
For further actions, you may consider blocking this person and/or reporting abuse
I know Alex has heard me say this before (hi Alex!), but blaming a language or stack for your problems is like blaming the English language for Twilight.
While I have sometimes seen situations where a stack or language seems to hold a team back, often there is a deeper problem behind it - usually that the team doesn't actually understand the stack they're using. The best developers are the ones who aren't content with a cursory understanding of the tools they use; they always seek to learn the tools better.
I've made it a goal to always try and learn things at least one level deeper than where I actually work. For example, the more I get into Node development, the more I have tried to learn about the internals: the module loader, the V8 parser/compiler, etc. I don't have a very deep knowledge of them, and I don't use that knowledge every day, but that deeper understanding allows me to write better code. This strategy has served me well, and has allowed me to become proficient in multiple stacks (especially since, once you peel away the superficial API, most tools in a given problem space are pretty similar).
I wish we could all learn to stop blaming our tools for our own crummy code. While tooling can make a big difference, having the fanciest knives in the world won't make me a better cook until I've studied and practiced all of the other things that go into preparing a meal.
I thought @jjude had another good post on picking stacks. dev.to/jjude/guidelines-for-pickin...
And I agree. Tech stacks aren't all the same, but there are tradeoffs for each one, the popular ones are pretty general-purpose anyway. As you mention, we're on the "slow" stack with dev.to but our site is pretty damn fast!
As an engineer I just naturally gravitate towards the tech stack. But, what you say is absolutely correct. At the end of the day, a platform is being built for a business, and that business needs to make money to survive. I've worked client facing for a few years, and the thing I learned very quickly is that the business does not care that you chose tech X instead of Y for technical reason Z.
The business/client wants to use the product they are investing in as quickly as possible and make it do the thing they expect it to do.
There needs to be a balance, however in the crafting of that technology stack. So, when it comes to fine tuning those pieces when you have gone to market, you won't be shooting yourself in the foot for the constant debt you can't climb out of.
So, while I agree 100% about not being too anal about what technology stack you choose, I think there needs to be some thought on how it is built to a certain extent. All while ensuring you don't start over engineering and prematurely optimizing that eventually lead to delays in the release.
What matters is the extent you leverage your tech stack vs how much that forces a full rewrite when it becomes deprecated. Any tech stack can be tweaked to perform well, to a point (not going to be high speed trading without low level stack)
I agree. Yet, I think it makes sense to choose a stack that helps to rapidly build a great product. I'm biased toward rails here cause I think the convention stuff is doing the team a favor, but the mile may vary for a team with (say) more javascript experience.
Whenever there is some 'fights' about what technology or language is best, I have this quote from Bjarne Stourstrup in mind:
We all love what is new and shiny. Some solves problems, but how many different languages have existed, exist today and will exist in the future?
And I'm just on programming languages here :D
Maybe we're doomed to never be satisfied with what we have. Until people legislate and force us to use whatever they chose.
The customer generally doesn't care about your tech stack but "programmer happiness" does factor into the equation.
If there are 2 equivalent stacks that both do the job more or less well but one gives the dev team a good feeling and the other doesn't then that could be a valid reason. Another valid reason is that as a developer or team you learn and grow from trying out new stuff.
But in the end the product and the customer should be leading, of course.
I agree Alex, the stack is not that important. The choice should be a balance between available developer skill (in and out the company), product requirements and time to market.
See Elixir for example, it's a great technology but experts in Elixir/Erlang are not easy to find so, as a freelance developer, if I were to convince a company to let me create a web app with that I would also increase their risk of failure the day I left.
Another thing to keep in mind: in 2017 with Heroku/AWS Elastic Beanstalk/Digital Ocean Droplet/Docker (pardon the generalization) it's not impossible to be a polyglot company, always keeping in mind the product requirements.
I would also recommend this article: "Is Ruby Too Slow For Web-Scale?" speedshop.co/2017/07/11/is-ruby-to... which also stresses the concept of context when we talk about speed
TL;DR the best stack is the stack you know
I cannot agree more. Lovely post Alex.
Tech stacks come and go, so I've come to realise that picking the best stack for the requirement always wins. And this isn't just a statement but it's proven in our company where we grew our customer engagement by 3X against a SPA written using a popular framework with an SSR running Java and using Vanilla JS for client side interactions.
It's a true success story to back this post.
Who said anybody Valued the tech stack other than the engineers hired to build it ?
I think it's partially about fear.
Fear of the unknown, it's easier to bash something than to learn about it.
Fear of being left behind as everyone moves on to the new and shiny.
If you're aiming to ship something, the best stack is the one your comfortable with. There is always time to improve the app at the end of the day. Getting your project out there should is the goal.