[GlennWilson]

Original discussion moved to ProgrammerLiteracyHistory.
----
''As several responses effectively showed, I was originally asking the wrong questions and looking for the wrong answers.  This is refactored to reflect a change in the definition of ProgrammerLiteracy.''

There are two meanings of 'literate':
	1. One who can read and write. 
	2. A well-informed, educated person. 
(Taken from the American Heritage Dictionary, here: http://www.bartleby.com/cgi-bin/texis/webinator/sitesearch/?query=%28col61%29+literate&db=db&cmd=context&id=38d470eb74a#hit1)  -- BrianEwins

'' ProgrammerLiteracy -- Things that a well-informed, educated programmer should know, but are not generally known by well-informed, educated non-programmers. We added the last clause to the definition to avoid listing all those things that well-informed, educated persons, in general, should know. --Glenn''

In which case - you need at least TWO programming languages, preferably in two different programming paradigms. Otherwise (IMHO) you're doomed to 'see everything as nails', as the saying goes. Personally I wouldn't really consider someone to be a literate programmer in the second sense, though, until they have  at least a passing knowledge of:
	* LispLikeLanguages (separating the languages from the paradigms)
	* Several of the AlgolFamily (eg Pascal, Modula, C, Java)
	* RelationalDatabases;
	* ObjectOrientedProgramming;
	* FunctionalProgramming;
	* PrototypeBasedProgramming
	* LogicProgramming
	* ConstraintSystems
	* ConcurrencyIssues
	* CompilerWriting
	* GuiConstruction
	* A variety of OS (Unices, Windows, MVS?)
	* TopDown and BottomUp design
These spring to mind, but I'm sure more will later. To me, the above is a step towards Dickens and Dostoevsky. Requiring that a programmer know about recursion is like requiring that they can write (or recognize) a rhyme.

Having taught programmers, it seems to me that the language doesn't matter, until they can solve problems no amount of drag and drop UI can help them. -- BrianEwins
----
	* Computer User Literacy
	* Algorithms
	* The fact that one person's data is another's program, and ''vice versa''.
	* Refactoring ''(The idea, if not the term.)''
----
Important theoretical concepts every programmer should know:
	* FormalGrammars and BackusNaurForm
	* LanguageInterpreters (definition and basic coding strategy)
	* Compilers (definition and basic coding strategy, see CompilerWriting)
	* OnePersonsProgramIsAnotherPersonsData, and ''vice versa''.

These are important because:

	* Programming language technology has lead to a vast leap in programming productivity, and
	* these concepts can be used by programmers to build DomainSpecificLanguage''''''s for a problem area.
	* Being able to think in terms of interpreter and compiler design helps programmers to build systems which use metadata.
	* Text and parse tree manipulation is generally useful in many applications (consider XML DTDs and FusionMethodology lifecycle expressions for example).

I consider these language technology concepts to be important for professional programmers. I'd even include these concepts in a list of what "component assemblers"  need to know.
I'm not addressing what part-timers, hobbyists need to know.

----
The fundamental skills of a programming are not technical---a brilliant technician who doesn't listen to their client will produce less useful code than an average technician who works closely with their user. That's why the start of ThePragmaticProgrammer has no code in it at all--the foundation is human, not hardware.

Beyond that, there are process skills in team working, abstract skills in structuring (for example DontRepeatYourself or OnceAndOnlyOnce, understanding orthogonality and decoupling) testing, and the like. There are attitudes towards quality, documentation, debugging. ---DavidThomas
----
Hmm, how about
	* knowing at least one programming paradigm and one corresponding programming language
	* knowing how to recursively break a problem into smaller chunks according to that paradigm, down to the language level
	* having some kind of heuristic to choose between alternative ways to break up the problem.
--FalkBruegmann
----
Most of us will have come across people in this industry who really understand what software is about and others who somehow don't, even though they may be great at specific tasks such as low-level coding. I was recently trying to capture an answer to the question WhatIsSoftwareAllAbout but ended up getting very woolly and vague. One thing that seems fundamental to me is that creation of software is a form of human communication (some parts of which just happens to be machine readable). From there I went looking for the types of things we need to communicate well and came up one thing: a clear capture of the EssentialDifficulty of our systems. Everything else (OnceAndOnlyOnce, AbStraction, DoTheSimplestThingThatCouldPossiblyWork, etc) seems to be a means to this end. Perhaps I'm barking up the wrong tree but understanding this could be necessary not just to be a good programmer but to be JustaProgrammer. Perhaps there is a defined skill set for human communication that could serve as a starting point? --NeilGall

''Does this imply that programming is inherently an AsynchronousSocialActivity? 

Actually I think that people are the only things that are important to people when you bring life to its most basic parts, therefore, everything is about communication. --ShaeErisson''
----