5 ms·

I think this is terrible advice. There's plenty of ways to write highly performant, wrong sofware, that contains bugs. What's worse than a slow program? One

I think this is terrible advice. There's plenty of ways to write highly performant, wrong sofware, that contains bugs. What's worse than a slow program? One that doesn't run. 1/10 of the time. Whats worse than a program that runs 1/10 of the time? One that runs with high uptime and resiliency, but handles funds with the wrong sign.

octocop 7y ago
Is it really terrible advice for anyone to actually think about performance when programming.
- fatbird 7y ago
  No, but you usually don't know what will be the poorly performing part or in need of optimization, beyond the macro level. Don't check your brain at the door, but don't overthink it too early. Someone else cites old systems with core decisions that are unchangeable because a data structure or algorithm is central to the entire codebase, as an example of "should have thought of performance earlier". My reaction to that was: why is the code structured in such a way that a particular data structure or algorithm is central to the entire edifice. I think the error the article makes is in describing later performance improvements as "accidental" and low hanging fruit, which is nonsense. If your code can't handle continual refactoring, including to realize significant performance gains, then you have a deeper problem than performance.
- dnautics 7y ago
  yes. Because for most programmers, who are basically becoming webdevs, the internet is now a distributed system, and when you try to use old "performance" algorithms, you're going to be in a world of hurt when suddenly things are distributed and asynchronous. Advice about what algorithms have what big-O goes out the window when you're in a distributed system. Just use what works, what your framework provides, because smarter people have solved this problem, the network is your bottleneck anyways. Just like "don't roll your own crypto" probably "don't roll your algos" is pretty sound advice for most programmers in 2020. Yes, I know not everyone is a webdev, but the median programmer receiving advice is.

octocop 7y ago

Is it really terrible advice for anyone to actually think about performance when programming.

fatbird 7y ago
No, but you usually don't know what will be the poorly performing part or in need of optimization, beyond the macro level. Don't check your brain at the door, but don't overthink it too early. Someone else cites old systems with core decisions that are unchangeable because a data structure or algorithm is central to the entire codebase, as an example of "should have thought of performance earlier". My reaction to that was: why is the code structured in such a way that a particular data structure or algorithm is central to the entire edifice. I think the error the article makes is in describing later performance improvements as "accidental" and low hanging fruit, which is nonsense. If your code can't handle continual refactoring, including to realize significant performance gains, then you have a deeper problem than performance.
dnautics 7y ago
yes. Because for most programmers, who are basically becoming webdevs, the internet is now a distributed system, and when you try to use old "performance" algorithms, you're going to be in a world of hurt when suddenly things are distributed and asynchronous. Advice about what algorithms have what big-O goes out the window when you're in a distributed system. Just use what works, what your framework provides, because smarter people have solved this problem, the network is your bottleneck anyways. Just like "don't roll your own crypto" probably "don't roll your algos" is pretty sound advice for most programmers in 2020. Yes, I know not everyone is a webdev, but the median programmer receiving advice is.