> It's about as relevant as implementing quicksort. ...did you actually read my comment? Because I went on to say that I didn't think it was relevant. That sa

> It's about as relevant as implementing quicksort. ...did you actually read my comment? Because I went on to say that I didn't think it was relevant. That said, understanding how quicksort works is important, not because you'll be called on to implement it, but because there are key strategies used in its implementation. And yes, I can implement quicksort without looking up the algorithm. It's really not that hard. > Or it's actually a javascript event handler that is doing something else expensive per char delete. It's more important to know to profile rather than try to memorize every algorithm used by a system and guess which one is causing the problem. Once you identify where the bottleneck is, you can search for "efficient algorithms to do X". Sorry, but no, wrong answer. Partial credit for suggesting profiling. Let me take this apart: > Or it's actually a javascript event handler that is doing something else expensive per char delete. If they're calling a function that triggers an event handler for every character deletion when they're deleting a block of text, then they're Doing It Wrong. Yes, profiling is important. But calling delete one character at a time for a block of text is plain lazy. > Memorize every algorithm used by a system Umm....this is a text editor we're talking about. There are very few algorithms, and it shouldn't be a case of "memorize them" as much as "observe them." If there are more than 3-4 algorithms, then it should also include "draw a picture of how they interact," if your abilities at modeling them in your head are insufficient. But someone who is strong at algorithms should be able to just see what's wrong with a text editor that deletes characters one at a time. It should be obvious that it's likely to be a problem, and they shouldn't do it to begin with. > People who profile and fix bottlenecks are much more valuable than people who think they have implemented the most efficient algorithm for every operation in their program. Both are necessary, and as I've said elsewhere, "developers that are anal about optimizing everything" is a straw man; good developers know when optimization is important, and good developers can write more optimal code without making it harder to read. Just knowing how to optimize doesn't automatically make you optimize every single routine, nor does it mean everything is more complex. Half the time when I optimize something the code ends up cleaner and easier to read, in fact. And it's not always about bottlenecks. Sometimes it really is about the algorithm, and if you don't know your algorithms, you won't be able to recognize this. As said above, it's a prime example of the Dunning-Kruger effect: If you don't know algorithms, you don't even know what you don't know. Claiming you don't need to know algorithms just reinforces the point. Sorry. In another comment on this post I described an optimization that I did that had no easy-to-fix bottleneck that was slowing things down, and that required a high level algorithmic change to fix. [1] In about an hour I sped it up by a factor of about a thousand. Ultimately I was doing the same things, but I was able to improve the algorithmic efficiency. And someone strictly looking for bottlenecks can look at that code forever and not see the algorithmic change needed, because the code itself was written to be pretty optimal; it was a high level change to the algorithm that made it so much faster. [1] https://news.ycombinator.com/item?id=13701931 https://news.ycombinator.com/item?id=13701931