6 ms·

This is a mixed bag of advice. While it seems wise at the surface, and certainly works as an initial model, the reality is a bit more complex than aphorisms. F

This is a mixed bag of advice. While it seems wise at the surface, and certainly works as an initial model, the reality is a bit more complex than aphorisms. For example, what you know might not provide the cost benefit ratio your client would. Or the performance. If you only know Cloud Spanner but now there is a need for a small relational table? These maxims have obvious limitations. I do agree that the client doesn't care about the tech stack. Or that seeking a golden standard is a McGuffin. But it does much deeper than that. Maybe a great solution will be a mix of OCaml, Lua, Python, Perl, low latency and batches. A good engineer balances tradeoffs and solves problems in a satisfying way sufficing all requirements. That can be MySQL and Node. But it can also be C++ and Oracle Coherence. Shying away from a tool just because it has a reputation is just as silly as using it for a hype.

xandrius 2y ago
I'd saw nowadays, C++ is rarely the best answer, especially for the users.
- evidencetamper 2y ago
  It's true, and of course, all models are wrong, especially as you go into deeper detail, so I can't really argue an edge case here. Indeed, C++ is rarely the best answer. But we all know of trading systems and gaming engines that rely heavily on C++ (for now, may Rust keep growing).
- ChrisMarshallNY 2y ago
  ...unless you do HFT...
- williamcotton 2y ago
  For real time audio synthesis or video game engines then C++ is the industry standard.
- bluGill 2y ago
  C++ is often the best answer for users, but this is about how bad the other options are, and not that C++ is good. Options like Rust doesn't have the mature frameworks that C++ does. (rust-qt is often used as a hack instead of a pure rust framework). There is a big difference between modern C++ and the old C++98 as well, and the more you force you code to be modern C++ the less the footguns in C++ will hit you. The C++ committee is also driving forward in eliminating the things people don't like about C++. Users don't care about your tech stack. They care about things like battery life, and how fast your program runs, how fast your program starts - places where C++ does really well. (C, rust... also do very well). Remember this is real world benchmarks, you can find micro benchmarks where python is just as fast as well written C, but if write a large application in python they will be 30-60 times slower than the same written in C++. Note however that users only care about security after it is too late. C++ can be much better than C, but since it is really easy to write C style code in C++ you need a lot more care than you would want. If for your application Rust or ada does have mature enough frameworks to work with then I wouldn't write C++, but all too often the long history of C++ means it is the best choice. In some applications managed languages like Java works well, but in others the limits of the runtime (startup, worse battery life) make it a bad choice. Many things are scripts you won't run very much and so python is just fine despite how slow it is. Make the right choice, but don't call C++ a bad choice just because for you it is bad.
thecleaner 2y ago
> Shying away from a tool just because it has a reputation is just as silly as using it for a hype. Trying to explain this to a team is one of the most frustrating things ever. Most of the time people pick / reject tools because of "feels". On a related note, I never understood the hype around GraphQL for example.
- evidencetamper 2y ago
  I heavily dislike GraphQL for all of the reasons. But I'll say that for a lot of developers, if you are already setting up an API gateway, you might as well batch the calls, and simplify the frontend code. I don't buy it :) but I can see the reasoning.
DrScientist 2y ago
> Maybe a great solution will be a mix of OCaml, Lua, Python, Perl, low latency and batches. Your customer does care about how quickly you can iterate new features over time, and product stability. A stack with a complex mix of technologies is likely to be harder to maintain over the longer term.
- evidencetamper 2y ago
  That's also an aphorism that may or may not correspond to reality. Not only there are companies with highly capable teams that are able to move fast using a complex mix of technologies, but also there are customers who have very little interest in new features. This is the point of my comment: these maxims are not universal truths, and taking them as such is a mistake. They are general models of good ideas, but they are just starter models. A company needs to attend to its own needs and solve its own problems. The way this goes might be surprisingly different from common sense.
  - mexicocitinluez 2y ago
    > these maxims are not universal truths, and taking them as such is a mistake. Amen.
  - DrScientist 2y ago
    Sure universal truths are rare - though I think there are many more people using such an argument to justify an overly complex stack, than there are cases where it truly is the best solution long term. Remember even if you have an unchanging product, change can be forced on you in terms of regulatory compliance, security bugs, hardware and OS changes etc. I think the point of the original post is that most important part of the context is the people ( developers ) and what they know how to use well and I'd agree. I'd just say that one thing I've learnt is that even if the developer in the future that has to add some feature or fix some bug, is the developer who originally wrote it, life is so much easier if the original is as simple as possible - but hey maybe that's just me.
- JohnFen 2y ago
  > Your customer does care about how quickly you can iterate new features over time How true this is depends on your particular target market. There is a very large population of customers that are displeased by frequent iterations and feature additions/changes.
phantomathkg 2y ago
The author didn't say listen to the opinion of other, hype or not. The author said "set aside time to explore new technologies that catch your interest ... valuable for your product and your users. Finding the right balance is key to creating something truly impactful.". It means we should make our own independent, educated judgement based on the need of the product/project we are working on.
- evidencetamper 2y ago
  > Finding the right balance is key to creating something truly impactful This doesn't mean anything at all. These platitudes are pure vapor, and seem just solid enough that they make sense at first glance, but once you try to grasp it, there is nothing there. What is impactful? What is untruly impactful as opposed to truly impactful? Why is that important? Why is the right balance key for it? Balance of what? How do you measure if the balance is right? My expectation for engineering (including its management) is that we deal in requirements, execution, delivery, not vibes. We need measurable outcomes, not vapor clouds.
mexicocitinluez 2y ago
> , the reality is a bit more complex than aphorisms. This is the entire tech blog, social media influencer, devx schtick though. Nuance doesn't sell. Saying "It depends" doesn't get clicks.

xandrius 2y ago

I'd saw nowadays, C++ is rarely the best answer, especially for the users.

evidencetamper 2y ago
It's true, and of course, all models are wrong, especially as you go into deeper detail, so I can't really argue an edge case here. Indeed, C++ is rarely the best answer. But we all know of trading systems and gaming engines that rely heavily on C++ (for now, may Rust keep growing).
ChrisMarshallNY 2y ago
...unless you do HFT...
williamcotton 2y ago
For real time audio synthesis or video game engines then C++ is the industry standard.
bluGill 2y ago
C++ is often the best answer for users, but this is about how bad the other options are, and not that C++ is good. Options like Rust doesn't have the mature frameworks that C++ does. (rust-qt is often used as a hack instead of a pure rust framework). There is a big difference between modern C++ and the old C++98 as well, and the more you force you code to be modern C++ the less the footguns in C++ will hit you. The C++ committee is also driving forward in eliminating the things people don't like about C++. Users don't care about your tech stack. They care about things like battery life, and how fast your program runs, how fast your program starts - places where C++ does really well. (C, rust... also do very well). Remember this is real world benchmarks, you can find micro benchmarks where python is just as fast as well written C, but if write a large application in python they will be 30-60 times slower than the same written in C++. Note however that users only care about security after it is too late. C++ can be much better than C, but since it is really easy to write C style code in C++ you need a lot more care than you would want. If for your application Rust or ada does have mature enough frameworks to work with then I wouldn't write C++, but all too often the long history of C++ means it is the best choice. In some applications managed languages like Java works well, but in others the limits of the runtime (startup, worse battery life) make it a bad choice. Many things are scripts you won't run very much and so python is just fine despite how slow it is. Make the right choice, but don't call C++ a bad choice just because for you it is bad.

thecleaner 2y ago

> Shying away from a tool just because it has a reputation is just as silly as using it for a hype. Trying to explain this to a team is one of the most frustrating things ever. Most of the time people pick / reject tools because of "feels". On a related note, I never understood the hype around GraphQL for example.

evidencetamper 2y ago
I heavily dislike GraphQL for all of the reasons. But I'll say that for a lot of developers, if you are already setting up an API gateway, you might as well batch the calls, and simplify the frontend code. I don't buy it :) but I can see the reasoning.

DrScientist 2y ago

> Maybe a great solution will be a mix of OCaml, Lua, Python, Perl, low latency and batches. Your customer does care about how quickly you can iterate new features over time, and product stability. A stack with a complex mix of technologies is likely to be harder to maintain over the longer term.

evidencetamper 2y ago
That's also an aphorism that may or may not correspond to reality. Not only there are companies with highly capable teams that are able to move fast using a complex mix of technologies, but also there are customers who have very little interest in new features. This is the point of my comment: these maxims are not universal truths, and taking them as such is a mistake. They are general models of good ideas, but they are just starter models. A company needs to attend to its own needs and solve its own problems. The way this goes might be surprisingly different from common sense.
- mexicocitinluez 2y ago
  > these maxims are not universal truths, and taking them as such is a mistake. Amen.
- DrScientist 2y ago
  Sure universal truths are rare - though I think there are many more people using such an argument to justify an overly complex stack, than there are cases where it truly is the best solution long term. Remember even if you have an unchanging product, change can be forced on you in terms of regulatory compliance, security bugs, hardware and OS changes etc. I think the point of the original post is that most important part of the context is the people ( developers ) and what they know how to use well and I'd agree. I'd just say that one thing I've learnt is that even if the developer in the future that has to add some feature or fix some bug, is the developer who originally wrote it, life is so much easier if the original is as simple as possible - but hey maybe that's just me.
JohnFen 2y ago
> Your customer does care about how quickly you can iterate new features over time How true this is depends on your particular target market. There is a very large population of customers that are displeased by frequent iterations and feature additions/changes.

phantomathkg 2y ago

The author didn't say listen to the opinion of other, hype or not. The author said "set aside time to explore new technologies that catch your interest ... valuable for your product and your users. Finding the right balance is key to creating something truly impactful.". It means we should make our own independent, educated judgement based on the need of the product/project we are working on.

evidencetamper 2y ago
> Finding the right balance is key to creating something truly impactful This doesn't mean anything at all. These platitudes are pure vapor, and seem just solid enough that they make sense at first glance, but once you try to grasp it, there is nothing there. What is impactful? What is untruly impactful as opposed to truly impactful? Why is that important? Why is the right balance key for it? Balance of what? How do you measure if the balance is right? My expectation for engineering (including its management) is that we deal in requirements, execution, delivery, not vibes. We need measurable outcomes, not vapor clouds.

mexicocitinluez 2y ago

> , the reality is a bit more complex than aphorisms. This is the entire tech blog, social media influencer, devx schtick though. Nuance doesn't sell. Saying "It depends" doesn't get clicks.