3 ms·

wow, I didn't get that impression at all. And he clearly does say "Measure", not "shut off your brain". I would assume that if you measure enough things and co

wow, I didn't get that impression at all. And he clearly does say "Measure", not "shut off your brain". I would assume that if you measure enough things and code enough you may start to get a feel for what is going to be expensive and what is not. And then - as before - you can continue to measure and iterate. (Also, I think you said "first people" when you meant "first point")

IshKebab 3y ago
> And he clearly does say "Measure", not "shut off your brain". Yes but he doesn't say that if you don't measure (which most people won't) then you should still engage your brain. That's the missing point. Measuring is typically more effort than applying a little brain power and experience. So the choices shouldn't be "measure or nothing", but that's how people always interpret it.
- shadowgovt 3y ago
  The key thing that drives rule 1 and 2 is the assumption in rule 4: all other things being equal, terser code is easier to work with. The cheapest code to maintain is the code that doesn't exist. Therefore, given a choice between writing a little code to make the program work or writing a lot of code to maybe make the program work faster... Write a little code and go back and write the longer code iff it will actually help performance as per measurements. You're better off expanding a simple skeleton than moving bones around in an already-complex assembly.
  - IshKebab 3y ago
    Yes but for the 100th time, you don't get to just ignore performed because you haven't measured it. The fact that so many replies are not getting this goes to show how misleading this advice is.
    - shadowgovt 3y ago
      I don't see Pike recommending one ignore performance and I assume given the target audience for the advice, the audience is assumed to know that you can't ignore performance in the same way that a chef knows you can't ignore presentation. The focus of the advice to me is that software engineers frequently overestimate their ability to predict performance bottlenecks and efficiently allocate time to preemptively address them in the middle of writing the core of the system (for multiple reasons, including both the overall complexity of a complete system and the fact that performance is also a function of the way users interact with the system). I've built multiple systems where a component we never expected to become a bottleneck becomes the bottleneck because users choose to use the machine in an extremely novel way relative to our intent when we built it. Getting the software in front of users to get signal on the difficult-to-predict user factor was consistently a better use of our time than swapping out a functional n squared algorithm with an also functional n log n algorithm on a piece of the system that no users were operating with yet.
      - IshKebab 3y ago
        > I assume given the target audience for the advice, the audience is assumed to know that you can't ignore performance That's why it's bad advice! Perhaps I should rephrase: it's not incorrect advice (to the right target audience), but it most definitely is inadvisable advice. Who is the audience for the famous "premature optimisation" quote? Maybe originally it was "people who know you shouldn't ignore performance", but it definitely isn't now. Easily misinterpreted advice is bad advice in my book.

IshKebab 3y ago

> And he clearly does say "Measure", not "shut off your brain". Yes but he doesn't say that if you don't measure (which most people won't) then you should still engage your brain. That's the missing point. Measuring is typically more effort than applying a little brain power and experience. So the choices shouldn't be "measure or nothing", but that's how people always interpret it.

shadowgovt 3y ago
The key thing that drives rule 1 and 2 is the assumption in rule 4: all other things being equal, terser code is easier to work with. The cheapest code to maintain is the code that doesn't exist. Therefore, given a choice between writing a little code to make the program work or writing a lot of code to maybe make the program work faster... Write a little code and go back and write the longer code iff it will actually help performance as per measurements. You're better off expanding a simple skeleton than moving bones around in an already-complex assembly.
- IshKebab 3y ago
  Yes but for the 100th time, you don't get to just ignore performed because you haven't measured it. The fact that so many replies are not getting this goes to show how misleading this advice is.
  - shadowgovt 3y ago
    I don't see Pike recommending one ignore performance and I assume given the target audience for the advice, the audience is assumed to know that you can't ignore performance in the same way that a chef knows you can't ignore presentation. The focus of the advice to me is that software engineers frequently overestimate their ability to predict performance bottlenecks and efficiently allocate time to preemptively address them in the middle of writing the core of the system (for multiple reasons, including both the overall complexity of a complete system and the fact that performance is also a function of the way users interact with the system). I've built multiple systems where a component we never expected to become a bottleneck becomes the bottleneck because users choose to use the machine in an extremely novel way relative to our intent when we built it. Getting the software in front of users to get signal on the difficult-to-predict user factor was consistently a better use of our time than swapping out a functional n squared algorithm with an also functional n log n algorithm on a piece of the system that no users were operating with yet.
    - IshKebab 3y ago
      > I assume given the target audience for the advice, the audience is assumed to know that you can't ignore performance That's why it's bad advice! Perhaps I should rephrase: it's not incorrect advice (to the right target audience), but it most definitely is inadvisable advice. Who is the audience for the famous "premature optimisation" quote? Maybe originally it was "people who know you shouldn't ignore performance", but it definitely isn't now. Easily misinterpreted advice is bad advice in my book.