Programmer Literacy History
Programmer Literacy HistoryThis is the original discussion from ProgrammerLiteracy. Please continue the discussion there.
As the book CulturalLiteracy attempts to list everything that a literate American should know, is such a list of what all programmers should know feasible? Actually, as I believe that programming is largely skill-based, it seems that such a list would be of limited use. But, if such a list existed and were useful, it could be used to help determine, in a small part, if a person were a competent programmer. It could also help a programmer or wannabe to evaluate their own knowledge and use it as a guide for learning new areas that might make them a more complete programmer. It could even be used as a guide for someone writing a book or developing curriculum. Basically, what does a person need to know to be considered a programmer?
Ideally, such a list would not include language specific or platform specific or domain specific knowledge. Yes, those are all very important to any specific programming job, I'm looking here to abstract out Programmer from Windows C++ Programmer, or Java programmer, or whatever.
Also, this is not an attempt to identify "skill sets" but simply knowledge that is common (or should be) to all programmers. I've actually started two lists below, one for all programmers, and a more specific list for OO Programmers.
Please add your thoughts as to essential knowledge for All or All OO Programmers below, or your thoughts on why such a list is nonsense.
ProgrammerLiteracy : All Programmers
Important theoretical concepts every programmer should know:
One might ask: Granted, every programmer should know the definition of an interpreter and a compiler. But should a programmer need to know the details of how to implement an interpreter or compiler? (E.g., "basic coding strategy", "Formal Grammars", and "BNF")
Measure yourself against what you want to know, not what anyone says you should know. Treat these lists as a menu from which you can try new tastes, not as a checklist which, in failing to have a tick on every item, shows you to be deficient.
Good advice. I would personally consider the language tools mentioned above (BNF, compiler construction etc) as useful knowledge for a programmer to possess. But not necessary to be a programmer. Depending upon domain, of course.
This seems like a somewhat retro list to me. Granted, all these are valuable skills for a programmer to have currently, but are they skills that are at the essence of the job? Increasingly I don't think so. As the machine is abstracted further and further away in the process, and as programmers increasingly become Lego engineers, plugging COM object X into EJB Y, then understanding recursion becomes less and less relevant.
However, certain core competencies remain. These are tied not to technology, but rather to process. Working with a customer to understand a need. Being disciplined enough to produce systems that meet that need. Being creative enough to produce systems capable of adapting to different needs. Testing those systems. Staying current with breaking technologies. Staying connected with the real world. To my mind these are far more important and fundamental skills.
Then there comes the issue of implementation. This is where one last process skill comes in. Programmers must be responsible enough to ensure they possess the low-level skills needed to make them proficient in their target environment. Java programmers need all the skills (and more) from the list at the top of the page. Those that drag-n-drop components into some workflow tool might not. I personally think that far too few of today's programmers are competent with the tools they use - programmers are undertrained and do not care enough about their craft. But to focus on just a list of skills is to miss the larger, more important, picture.
As technology moves on, and as more and more of the general public become programmers (even if it's just writing the filter rules for their e-mail), skills lists must give way to something more fundamental. -- DavidThomas
DavidThomas makes many good points about skills but they do not address the original question of knowledge; perhaps the skills he is referring to could form a separate page of ProgrammerSkills?. I would suggest that skills = knowledge + action (with perhaps some experience or practice thrown in).
What I was trying to get at was a list of knowledge common to nearly all programmers. As an example, the concept of a variable is, I believe, universal to the practice of programming. Even if all we are talking about is creating a simple Excel spreadsheet that adds three numbers, the user knows the concept of variable. In this case they make think of it as cell, and their understanding may not be as refined as someone we might consider a real programmer, but they have that knowledge. Similarly, if someone is programming in bare machine language, again, they are using the concept of variable (even if it is just a memory address). It may be difficult or impossible to make such a list, and such a list may be of limited value and may evolve over time, but such a list may still be useful, or at least interesting. And, I'm rather curious if there can be general agreement on just what that common knowledge might be.
And, if a person is just "plugging COM object X into EJB Y" are they programming?
Twenty years ago someone might have asked: 'if they don't understand the register architecture of the machine, are they programming? If they don't code their own binary to decimal routine, are they programming? Programming seems to me to be the art of getting machines to do something repeatedly and at the same time with a degree of flexibility. Ten years from now, "make it so" might be all it takes. -- Dave
So what knowledge is required to be a programmer, then? Nothing? Actually, I would argue that the definition of programming has regressed in the last twenty years so that things that would have been considered programming no longer are. Twenty years ago, writing a program to do your payroll calculations would commonly have been considered programming. Doing so today with Excel is generally not. Successful programmers do many things that are not programming. If at some time "make it so" gets the job done, thats great. But, its also not programming (but it is using the programs of someone or something else). My question above about "is plugging etc" programming is not meant to be derisive of someone who does this. But if that is literally all one is doing, it might be useful but I would not consider it programming. At the extreme, your definition would include all users of computers as programmers and make no distinction for the people that actually wrote the software. -- Glenn
One of the reasons I started this discussion was an issue that arose at work a few months back. We were designing a test to administer to prospective employees. I suggested the questions "1) What is a binary search, and 2) How much faster is a binary search than a linear search" and other programmers that I work with thought that this knowledge was not very important. Admittedly, I would rather have a programmer that can figure this out than one who has memorized this information, but I would consider this information important to being a good programmer. But not to being a programmer. Which lead me to wondering what other people thought a programmer should know.
-- GlennWilson
So, if the above list of knowledge required of a programmer is "retro" what knowledge do you think such a list should contain? -- Glenn
What knowledge should an artist have? A mechanic? Does a mechanic who makes watches need the same knowledge as a mechanic who grinds the bits for oil drills?
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.
Then there are basic technical skills, such as those encapsulated in the list above. Absolutely, they are needed with current languages. But defining a programmer using these as a filter, or designing a course of learning with these as a syllabus, is to miss the essence of the job. -- DavidThomas
Yes, but what is the knowledge that would distinguish a programmer from a mechanic or an artist or a carpenter? You seem to be describing skills (disciplined, creative, etc) that are equally valuable to a multitude of endeavors. And, yes, I agree those are useful or required of a programmer. But, are there any bits of knowledge (not skills) that are generally common to programmers and not so in non-programmers? That is the essence of the question I am trying to ask. Which I think is a reasonable question to ask. Whether such a list can be created, I am not sure. The value of such a list, I am not sure. But, such a list is very different than a list of programming skills, and such a list is very different than a list of "people skills" required for nearly any avocation including programming. Another way, perhaps, to ask the same question would be "What, if any, knowledge does a programmer generally possess that a non-programmer generally does not?" And, again, I agree that skills are of the utmost importance (see 2nd sentence on this page), but, I am asking about a more fundamental, and I think far simpler issue; about knowledge.
Put another way, lets say you were creating a knowledge based game that would have programmers (from many different platforms, languages, tools, etc) and non-programmers compete. If you wanted the programmers to usually win, what should the questions be about? (Or, what would the programmers tend to know that the other participants would tend not to know?). Is it possible to create such a list? -- GlennWilson
Well, let's look at the list above. Number one: variables. Hmmm.. seems good. I guess it's reasonable to say that users of pure functional programming languages aren't programmers. Loops? Let's eliminate all those Prolog people too. Inheritance. I guess the folks who use prototype-based class systems can can a hike.
Excellent point. Such a list may only be feasible based upon general language categories. But, the languages you mention represent a small minority of usage, and users of those languages likely know more mundane languages also. In which case they are likely to also be familiar with basic, traditional concepts. But alas, your points do illustrate the difficulty (or impossibility) of creating a single list. -- Glenn
So, you tell me - what would be good questions for your game that fairly test knowledge across the whole range of folks who call themselves programmers? I'm not being nasty here - it's a genuine question.
[At some point, we're also going to have to work out how to unthread this page..]
Is the distinction between "programmer" and "mechanic" really valid? A large part of what a "mechanic" does is figure out how to make something, follow a process in making it, and test that he made it correctly. It sounds a lot like programming. An AnalogyBetweenProgrammingAndManufacturing further extends the idea that TheSourceCodeIsTheDesign.
Yes, the distinction is valid. ThingsThatAreDifferentAreNotTheSame. There are similarities and common characteristics, of course. And some people can be both. But they are not the same and are not interchangeable. -- Glenn
Hmm, how about
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
There are two meanings of 'literate':
I think your [Falk's] definition corresponds to the former in programming terms. Some of the items on the list at the top appear to be aiming at the latter. I'd rather we aimed out-and-out at the latter. (Certainly, excluding part-timers and hobbyists makes it sound like this is what the original author intended). 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:
I think there are possibly two threads on this page, arguing about the two meanings.
With regard to the first meaning, I think the fundamental requirement is that a programmer knows how to state a problem and work towards a solution. 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
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search