3 ms·

This is a thing I've been pondering recently, and I don't have the same takeaway as you. My thought is: The context doesn't always matter, and a quotation can m

This is a thing I've been pondering recently, and I don't have the same takeaway as you. My thought is: The context doesn't always matter, and a quotation can mean different things in different contexts, and that's not a bad thing. For example, with the Knuth quote, both interpretations can be valuable? There are people who need to be told "don't optimise yet", and there are people who need to be told "there are critical times and places to optimise, and you probably shouldn't just breeze past a 12% execution time improvement". Neither of these lessons are "wrong". The main wrong thing is probably attributing the intent of the first to Knuth, which uses his status as an expert to (falsely) back it. I think Scott Alexander from SSC wrote something about opposite pieces of advice (eg. telling college nerds to "get out more" and telling college partygoers to "buckle down and study more", because neither of those can be universal pieces of advice), but I don't feel like searching for it rn. It's a good read though.

kelnos 6y ago
I guess it depends on the purpose of using a quotation. My belief is that most people cite a quotation when arguing something as an appeal to authority. "Knuth says don't optimize at all, so we shouldn't do it either." In that case, I think understanding the context is key: if you use someone's words to back up your point, but that's not actually what they meant, then context does matter. Yes, it's true that different people might need to hear different things at different times. If you're trying to tell someone not to micro-optimize ahead of time before profiling, then quoting Knuth is appropriate. If you're trying to tell someone not to optimize at all (let's say you have a valid reason for not optimizing at all), then its disingenuous (or at best ignorant) to use the Knuth quote.
mherdeg 6y ago
So in general I'm OK with using someone's words to illustrate a different point than they were originally making. But when I do this I prefer to explicitly state the original context and explain how I am reusing their work -- I try to point out what next information changes their idea, or where I disagree with them. This helps in a few ways: (1) Improves communication. When I use a quotation, some readers or listeners will know the whole context (or think they do). If I use it in a dissonant way and explicitly acknowledge the contradiction, that part of the audience will be more likely to trust that I have understood the person I am quoting. I won't be dismissed as ill-informed or as deliberately misinterpreting my sources. For example I might say "yes, this part of the code is hard to read. Here is the deal. Knuth said that premature optimization was the root of all evil, and that you should understand what your code's slow parts are before you try to optimize it. But in this specific case I cannot easily modify my code after I deploy it and cannot easily test it on all kinds of real-world data I am expecting it to encounter pre-production, so we are defensively making this function very complex but also very performant on a diverse variety of inputs. That is why this function is so complicated up front." (2) Improves understanding. For audience members who don't know the original context of the quotation, explaining it will help them learn something new. I thought the idea was interesting enough to quote, so probably it's worth at least a footnote about what the idea originally meant? Often if you beyond the one sentence there is a rich tapestry of prior context that is worth understanding. Humans spread our thoughts via the fragile web of written language and reiterating what has been said before can help reinforce those links and make our knowledge more durable. For example I might say "You may have heard that Knuth said that premature optimization was the root of all evil. But it's worth reading the full three paragraphs from his paper, 'Structured Programming With Go To Statements' (1974), because he develops an entire nuanced argument that today is settled wisdom in software engineering practice. He argues that optimizations can be a great idea on the core inner loop of your program, even if they significantly hurt readability and maintainability. This still holds true with complex networked software -- you should always know what your system's slow inner loops are and you should be willing to go to unusual lengths to speed up the slowest parts. Here are some ways that distributed tracing can help with that…" (3) Knowing what the original author was getting at seems to help me form my thoughts better. In particular, reading the whole paper before I quote it helps me avoid re-discovering an idea that Knuth already had, and it helps me think more clearly about "given what he knew then and what I know now, what are the next logical steps? What can we learn?" Overall the rule of thumb I use of reading/watching an entire work before quoting from it is … not for everyone. It can be exhausting. But it helps me learn and (I can't prove this) it feels like it improves the quality of discussion.

kelnos 6y ago

I guess it depends on the purpose of using a quotation. My belief is that most people cite a quotation when arguing something as an appeal to authority. "Knuth says don't optimize at all, so we shouldn't do it either." In that case, I think understanding the context is key: if you use someone's words to back up your point, but that's not actually what they meant, then context does matter. Yes, it's true that different people might need to hear different things at different times. If you're trying to tell someone not to micro-optimize ahead of time before profiling, then quoting Knuth is appropriate. If you're trying to tell someone not to optimize at all (let's say you have a valid reason for not optimizing at all), then its disingenuous (or at best ignorant) to use the Knuth quote.

mherdeg 6y ago

So in general I'm OK with using someone's words to illustrate a different point than they were originally making. But when I do this I prefer to explicitly state the original context and explain how I am reusing their work -- I try to point out what next information changes their idea, or where I disagree with them. This helps in a few ways: (1) Improves communication. When I use a quotation, some readers or listeners will know the whole context (or think they do). If I use it in a dissonant way and explicitly acknowledge the contradiction, that part of the audience will be more likely to trust that I have understood the person I am quoting. I won't be dismissed as ill-informed or as deliberately misinterpreting my sources. For example I might say "yes, this part of the code is hard to read. Here is the deal. Knuth said that premature optimization was the root of all evil, and that you should understand what your code's slow parts are before you try to optimize it. But in this specific case I cannot easily modify my code after I deploy it and cannot easily test it on all kinds of real-world data I am expecting it to encounter pre-production, so we are defensively making this function very complex but also very performant on a diverse variety of inputs. That is why this function is so complicated up front." (2) Improves understanding. For audience members who don't know the original context of the quotation, explaining it will help them learn something new. I thought the idea was interesting enough to quote, so probably it's worth at least a footnote about what the idea originally meant? Often if you beyond the one sentence there is a rich tapestry of prior context that is worth understanding. Humans spread our thoughts via the fragile web of written language and reiterating what has been said before can help reinforce those links and make our knowledge more durable. For example I might say "You may have heard that Knuth said that premature optimization was the root of all evil. But it's worth reading the full three paragraphs from his paper, 'Structured Programming With Go To Statements' (1974), because he develops an entire nuanced argument that today is settled wisdom in software engineering practice. He argues that optimizations can be a great idea on the core inner loop of your program, even if they significantly hurt readability and maintainability. This still holds true with complex networked software -- you should always know what your system's slow inner loops are and you should be willing to go to unusual lengths to speed up the slowest parts. Here are some ways that distributed tracing can help with that…" (3) Knowing what the original author was getting at seems to help me form my thoughts better. In particular, reading the whole paper before I quote it helps me avoid re-discovering an idea that Knuth already had, and it helps me think more clearly about "given what he knew then and what I know now, what are the next logical steps? What can we learn?" Overall the rule of thumb I use of reading/watching an entire work before quoting from it is … not for everyone. It can be exhausting. But it helps me learn and (I can't prove this) it feels like it improves the quality of discussion.