What every programmer should know about memory [2007]

Every programmer does not need to know this.

Coming from a programming background and moving more in to the management side of things, I've come to learn that while it's a lot of fun to know the minutia, it is not necessary to do your job. It can even be a waste of time.

The Six Sigma (I can feel you rolling your eyes) folks have a tool they call KPI (key performance indicators). KPI is like an abstraction for management. Think of it like a benchmarking or profiling utility for your organization. The purpose of the KPI is to abstract away the underlying complexity of the tasks being performed and answer the question: "Is our performance adequate?" This should help managers to avoid micro-managing their staff.

A generalist programmer does not need to know the internal differences between SRAM and DRAM because there is no change or improvement they can effect by knowing these details; not even on the optimization side of things. They only need to know how the two affect application peformance. To dig deeper is to commit to micro-managing the computer. Even worse, there's nothing you can change about the way SRAM or DRAM operates.

I understand completely if you enjoy knowing this kind of thing. I do to. I just don't accept that every programmer needs to know this.

I somehow asumed that the article was about the human's memory works, and tips on how to maximize your (programming) efficiency by better exploiting your working memory.

I guess I'll have to wait for that. Bummer! hehe