I think you are contorting the comment to mean something it doesn't mean. "every" is the keyword there. Not every programmer needs to know how memory works. Some programmers should know. I don't need to know for 99.99999999% of the work I do. But even that 0.00000001% it is debatable. I write code that runs on target systems. I can evaluate its performance on the target system. Now if I had to write software for a system and speed was critical and I could choose the type of memory to use, then you bet I would be reading up on this subject.
> I write code that runs on target systems. I can evaluate its performance on the target system. Now if I had to write software for a system and speed was critical and I could choose the type of memory to use, then you bet I would be reading up on this subject.
Differences between types of memory don't just matter when you're picking what hardware to purchase. It also matters greatly when trying to understand why your code achieves a certain level of performance. Understanding the characteristics of your memory matters even if you're targeting a single fixed hardware platform that you can profile your code on.
The why isn't very important. You only need to know the constraints of your system, you don't need to know why the constraints are what they are... maybe you want to, but not need.
The why does come into play, often quite unexpectedly if you don't really understand how your memory system works. I've seen StackOverflow questions about performance anomalies that could only be properly answered by digging into the details of not just cache line size, but also cache associativity.
Not understanding how the system works means that sometimes you'll have to settle for not being able to use the full performance of your hardware, and that your performance constraints will in practice be rather inscrutable and often unpredictable.
