Some points I believe to be missing is modern programming environments:

1. Making "why" a property to be populated by the programmer in all
programing artifacts. Like a Jr. programmer, if the "why" property is
not populated, the interface should gently, non-disruptively ask
"why". Some say that the answer to "why" is already in the programming
source code. I rather disagree. Often, even Sr. Programmers experiment
with the code to discover the chosen way that is eventually preserved
for the record in the distribution. However, the learning process
itself, and hence the reason why, is thrown away. "Why" often
documents the code that shouldn't be there, rather than the code that
is. A system without "why" preserved in it can exhibit the problem in
the form of many different programmers submitting a "fix" for the same
"problem" and only told "why" the fix won't work after they went
through the effort of "fixing" it. Reflexive, logic programming
languages like Prolog have the advantage of describing "how" they've
reached some conclusion which is similar to explaining "why".

2. Check out Jef Raskin's book, "They Humane Interface" for some very
insightful observations from a cognitive psychology perspective.

3. Along with "why", I believe "who", "what", "where", "when", and
"how" should be configurable properties of all programming artifacts.
They imply many important questions often left unanswered but are
necessary for understanding and modifying other programmers' code.
These need not be just "text" or "tag" properties, but full fledge
objects and code that can be extracted, examined, programatically
reasoned from, or modified programatically. Something like the
semantic web.

4. Zoomable names/labels. Because programing languages have most often
been expressed in text (for the advantage of the compiler) a lot of
burden has been placed on the meaning of a field name. In fact, and
enormous burden is placed on field names. This fact can by illustrated
by some who need to use Camel Case, Hungarian Notation, quotation
marks for  names with white space, type systems, scoping rules, dot
notation, syntax highlighting, autocompletion lists, name spaces,
globals, method-name/property-name/database-field-name confusion,
defs, source code readability, etc. These names and labels are often
defined far from where they are used placing a burden on the
programmer's memory or spend the programmer's time to jump from one to
the other. Rather, I believe, as long as we program in a _GUI_ we
should allow labels to be dynamically zoomed, in-place, to the level
of detail required by the programmer's memory and experience... any
level of detail. Even after the code is persisted to storage,
subsequent programmers should still have the dynamic freedom to
re-zoom the label to the same degree as the original programmer.

5. Continuous unit testing and integration testing should be built-in
to even the tiniest artifacts of coding so that such things become
visual, automatic, unconscious to the developer. (cf Raskin).

6. I would include audio documentation to be a normal part of source
code documentation. This would be a crutch for the "documentation
writing challenged" among us. Such things could me setup to be
programatically translated to other languages, accents, or dialects.

More later.