3 ms·

I agree at the level of source code, but sometimes algorithm skills affect the whole architecture. Even simple things like where certain data and logic would op

by fl0ki 2y ago

I agree at the level of source code, but sometimes algorithm skills affect the whole architecture. Even simple things like where certain data and logic would optimally exist can have cascading and compounding consequences for the whole rest of the system. To see better solutions, you have to know what's possible with algorithms and data structures. To give a contrived example that I think should make sense no matter what kind of software people actually work on: Imagine nobody had ever figured out video compression and the only way we could see electronic video required orders of magnitude higher costs. VOD and video conferencing may not even be viable for most people. We'd still be live streaming television over analog radio. It would have vast consequences throughout other technologies and what we can do with them. If a service gets the kind of viral growth that their creators dearly hope they will, that will almost certainly involve a level of scale that would benefit from knowledge of algorithms (including practical mathematics as a subset) and the difference between a good or bad solution could have far-reaching consequences. Of course many problems do have well-known solutions that anybody can look up, but many projects do end up needing solutions novel to them.

TrackerFF 2y ago
Yes, I absolutely buy the argument that doing things the optimal way will make a difference at scale. When some method is being called, or some data structure is being used, trillions or quadrillions of times (all the users of facebook/tiktok/etc. clicking on something / using a feature) - even small optimizations can add up quickly, which can obviously mean more compute or storage. But I do not believe that you will find a single point of failure for those cases. In fact, no single person should be able to create such failures. And at companies that operate at such scale, there are many, many safety measures put up - not to mention the continuous performance analysis and reviews.
- fl0ki 2y ago
  > And at companies that operate at such scale, there are many, many safety measures put up - not to mention the continuous performance analysis and reviews. If I can see these issues hit at multiple separate FAANG companies famed for their algorithm interviewing then we still don't have enough safety measures. As long as a spectrum of individual algorithm skill goes as low as X, there's always a non-zero probability you'll have a whole team around that level X. A larger institution just creates more opportunities for random teams to be low outliers just like you'd hope some would be high outliers. Sure, these situations shouldn't last forever, sooner or later the problem will be bad enough that someone has to come in and rescue the project. I've been that person multiple times [1], so some might say maybe I've just seen the worst of it and my experience isn't universal, but ask yourself how likely it is that I've had to save multiple large projects across multiple large companies if there isn't enough of this in the industry to go around. It's always a total disaster when you get to a project like that. There'll be one "worst" algorithm but there'll also be many other terrible algorithms. I wish I could say they were only inefficient; people who don't understand algorithms usually produce plainly incorrect algorithms, not just inefficient ones, because algorithm knowledge is required for both. Even if they bother to write tests, which is far from a given, they won't think of the algorithmic edge cases most deserving of tests. If you're very lucky, you can find a way to regenerate production data to fix whatever errors were introduced by the incorrect algorithms. Often this is impossible because the original inputs were not saved because of the assumption that the algorithm was correct even if inefficient. We can talk all we want about how there should be safety nets for these things, but there's no denying incorrect code does sometimes end up in production even at a large scale. [1] I'm really not even that good at algorithms. I can do every day in Advent of Code without spoilers, but nowhere near a competitive level, and not always the most efficient algorithm for a given day. It turns out that's still far more algorithm knowledge than the average senior FAANG engineer who doesn't even attempt AoC because they're too busy step-debugging their last dumpster fire.

by fl0ki 2y ago

TrackerFF 2y ago

Yes, I absolutely buy the argument that doing things the optimal way will make a difference at scale. When some method is being called, or some data structure is being used, trillions or quadrillions of times (all the users of facebook/tiktok/etc. clicking on something / using a feature) - even small optimizations can add up quickly, which can obviously mean more compute or storage. But I do not believe that you will find a single point of failure for those cases. In fact, no single person should be able to create such failures. And at companies that operate at such scale, there are many, many safety measures put up - not to mention the continuous performance analysis and reviews.

fl0ki 2y ago
> And at companies that operate at such scale, there are many, many safety measures put up - not to mention the continuous performance analysis and reviews. If I can see these issues hit at multiple separate FAANG companies famed for their algorithm interviewing then we still don't have enough safety measures. As long as a spectrum of individual algorithm skill goes as low as X, there's always a non-zero probability you'll have a whole team around that level X. A larger institution just creates more opportunities for random teams to be low outliers just like you'd hope some would be high outliers. Sure, these situations shouldn't last forever, sooner or later the problem will be bad enough that someone has to come in and rescue the project. I've been that person multiple times [1], so some might say maybe I've just seen the worst of it and my experience isn't universal, but ask yourself how likely it is that I've had to save multiple large projects across multiple large companies if there isn't enough of this in the industry to go around. It's always a total disaster when you get to a project like that. There'll be one "worst" algorithm but there'll also be many other terrible algorithms. I wish I could say they were only inefficient; people who don't understand algorithms usually produce plainly incorrect algorithms, not just inefficient ones, because algorithm knowledge is required for both. Even if they bother to write tests, which is far from a given, they won't think of the algorithmic edge cases most deserving of tests. If you're very lucky, you can find a way to regenerate production data to fix whatever errors were introduced by the incorrect algorithms. Often this is impossible because the original inputs were not saved because of the assumption that the algorithm was correct even if inefficient. We can talk all we want about how there should be safety nets for these things, but there's no denying incorrect code does sometimes end up in production even at a large scale. [1] I'm really not even that good at algorithms. I can do every day in Advent of Code without spoilers, but nowhere near a competitive level, and not always the most efficient algorithm for a given day. It turns out that's still far more algorithm knowledge than the average senior FAANG engineer who doesn't even attempt AoC because they're too busy step-debugging their last dumpster fire.