Not just when the user is a programmer maintaining the code. But also when the user is a programmer attempting to integrate it into a new environment, or an auditor looking for security holes. Or, and this applies most especially to OpenSource products, the user just wants to make sure it does what it is supposed to and doesn't engage in dubious shenanigans beyond his or her ken.

A corollary to TheSourceCodeIsTheDesign is that the SourceCodeIsUserInterface without a doubt every programmer's least favorite task is maintaining other peoples code. But of course that is exactly what we are usually doing most of the time. It's even worse when you are the so-and-so who wrote the code in the first place. You probably know the feeling "what kind of Idiot wrote this...Oh yeah...that was me". 

PhysicalCuesInSoftwareDevelopment discusses some of these issues, most notably how physical constraints affecting the presentation of code can affect how the code is written (for the better usually). Various CodingConventions have been tried over the years, none that I know of is markedly superior as long as it is clear and consistently followed. (this is probably a case of NoSilverBullet).

-----
Corollary to the corollary, ProgrammersAreUsersToo, this is something worth noting. Especially in an age when many users expect to be able to alter products to fit changing needs.

LiterateProgramming is one approach to improving upon this aspect of programming, WellWrittenCode that is a pleasure to read can make complex ideas clear.

An interesting take on this is a discussion of SourceCodeInDatabase that can be found at
http://www.mindprod.com/scid.html
they even discuss JimLittle's PrismProject.

This is a great insight. I'll bet that there's a "Therefore:" or two just waiting to jump out of this. -- PhilGoodwin
-----

You spend more time maintaining existing code
''('''including''' code you wrote just yesterday)''
than you spend writing new code.
	Therefore:	Write code so that it's readable.

-----
Discussion moved to LanguageUsability


The programming community has a real cultural problem with the concept that SourceCodeIsUserInterface, and that therefore some language features are better than others.  I think this is because programmers think of themselves as a mix of artistic prima donnas and tall-foreheaded geniuses who can understand complex tools that are beyond the ken of normal folk (I know I sometimes do).
Unfortunately we shoot ourselves in the foot because of it.  Software has the image of being unreliable and insecure because, to use the terminology Fred Brooks used in NoSilverBullet, our languages force us to work too hard on the "accidental" difficulties of programming and so we cannot concentrate on the "essential" difficulties where we should be focussing our efforts.
----
I found this while digging through the literature:

''Methodologists who insist on separating analysis and design from coding are missing the essential feature of design: [TheSourceCodeIsTheDesign], not in a document or in a diagram. Half a programmer's time is spent exploring the code, not in typing it in or changing it. When you look at the code you see its design, and that's most of what you're looking at, and it's mostly while coding that you're designing.'' --RichardGabriel (in PatternsOfSoftware)

So what are the features of code that can emphasise and reveal the design as much as possible? How can SourceCode be framed and presented so as to make as much of the underlying structure of the program available to the reader without overwhelming her with detail?

* FeaturesOfCodeWhichRevealDesign may be a way of finding the answer to that question.