3 ms·

> The old advice is to ignore performance because it’s not important. I think you misunderstood the instructions and anecdotes that you were given about how an

by IncRnd 8y ago

> The old advice is to ignore performance because it’s not important. I think you misunderstood the instructions and anecdotes that you were given about how and when to optimize. Alternatively, your definition of "old" in "old advice" is a very short time in the past.

hinkley 8y ago
The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. I spent a big chunk of my early career doing performance analysis work in a language stereotyped as being slow. My thesis was that it was down to developer skill and not the language. By the time someone spoke Knuth's aphorism at me it was people who were standing between me and the strategic goals of the company. Using it as a shield to get out of doing the hard work to match a competitor or customer expectations. As I quickly discovered, there are a whole set of performance optimizations that also improve readability, and that got around the friction with the foot dragging Knuth quoters. There's a host of other things never show up in the literature. It's a shame, really.
- basilgohar 8y ago
  A lot of this is due to misunderstanding the quote and knowing the bounds where it applies. Premature optimization being the root of all evil means those misapplying the addage are using it as a crutch. Good code is both performant and also easy to scale because of how it's designed (as mentioned elsewhere in this thread). See [0]. It is suspect that most folks ever got it to "Make it right" in the first place. Executive pressure and lack of support from managers needs to be called out as well as contributing to problems with quality of code ad teams oftentimes are not given the chance to make it right under pressure to deliver under unrealistic deadlines. [0] http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
  - hinkley 8y ago
    There's some truth to that, but I'm still going to stick by my my first line: The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. I consider "premature optimization" a spectacular failed experiment.
  - hinkley 8y ago
    After a few hours to think about this, I’m afraid you may be right about nearly everything here. But I have a big problem with developers needing permission from business to do the right thing. That’s not how ethics works, and I’ve caught too many devs in the lie when we do get free time and they still don’t want to do the hard work they dodged because of time constraints. There are people who want to appear high minded but have no interests beyond virtue signaling.
- de_watcher 8y ago
  > My thesis was that it was down to developer skill and not the language. It's not the language, it's that one first example that came with the language, and everybody has copied it.
  - hinkley 8y ago
    Ouch. ...you are not wrong. Lack of imagination then?
- IncRnd 8y ago
  > The old advice is to ignore performance because it’s not important. > The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. > I spent a big chunk of my early career doing performance analysis work in a language stereotyped as being slow. Something doesn't compute with those statements. Can you profile what it might be?
  - hinkley 8y ago
    If it ain’t broke don’t fix it. Even though we just spent ten minutes detailing how it’s broken. As someone else stated, make it work make it right make it fast, but people never get past make it work. They fear changing the code. It’s one of the things I loved most about XP (and I barely got to use it before it was already going out of fashion). Get over the fear.
    - IncRnd 8y ago
      You replied to the wrong comment. None of that is related to what I wrote.
mockingbirdy 8y ago
Agreed that this advice is not very old. Always reminds me of the Story of Mel http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
- IncRnd 8y ago
  That's always a great read. Thank you.

by IncRnd 8y ago

hinkley 8y ago

The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. I spent a big chunk of my early career doing performance analysis work in a language stereotyped as being slow. My thesis was that it was down to developer skill and not the language. By the time someone spoke Knuth's aphorism at me it was people who were standing between me and the strategic goals of the company. Using it as a shield to get out of doing the hard work to match a competitor or customer expectations. As I quickly discovered, there are a whole set of performance optimizations that also improve readability, and that got around the friction with the foot dragging Knuth quoters. There's a host of other things never show up in the literature. It's a shame, really.

basilgohar 8y ago
A lot of this is due to misunderstanding the quote and knowing the bounds where it applies. Premature optimization being the root of all evil means those misapplying the addage are using it as a crutch. Good code is both performant and also easy to scale because of how it's designed (as mentioned elsewhere in this thread). See [0]. It is suspect that most folks ever got it to "Make it right" in the first place. Executive pressure and lack of support from managers needs to be called out as well as contributing to problems with quality of code ad teams oftentimes are not given the chance to make it right under pressure to deliver under unrealistic deadlines. [0] http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
- hinkley 8y ago
  There's some truth to that, but I'm still going to stick by my my first line: The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. I consider "premature optimization" a spectacular failed experiment.
- hinkley 8y ago
  After a few hours to think about this, I’m afraid you may be right about nearly everything here. But I have a big problem with developers needing permission from business to do the right thing. That’s not how ethics works, and I’ve caught too many devs in the lie when we do get free time and they still don’t want to do the hard work they dodged because of time constraints. There are people who want to appear high minded but have no interests beyond virtue signaling.
de_watcher 8y ago
> My thesis was that it was down to developer skill and not the language. It's not the language, it's that one first example that came with the language, and everybody has copied it.
- hinkley 8y ago
  Ouch. ...you are not wrong. Lack of imagination then?
IncRnd 8y ago
> The old advice is to ignore performance because it’s not important. > The only yardstick of teaching that means anything is to look at what people go and do with what you taught them. > I spent a big chunk of my early career doing performance analysis work in a language stereotyped as being slow. Something doesn't compute with those statements. Can you profile what it might be?
- hinkley 8y ago
  If it ain’t broke don’t fix it. Even though we just spent ten minutes detailing how it’s broken. As someone else stated, make it work make it right make it fast, but people never get past make it work. They fear changing the code. It’s one of the things I loved most about XP (and I barely got to use it before it was already going out of fashion). Get over the fear.
  - IncRnd 8y ago
    You replied to the wrong comment. None of that is related to what I wrote.

mockingbirdy 8y ago

Agreed that this advice is not very old. Always reminds me of the Story of Mel http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html

IncRnd 8y ago
That's always a great read. Thank you.