Research has demonstrated that humans have a very sophisticated way of processing information. Our minds relate to information in chunks. Although the number of chunks a person can retain in short-term memory (i.e. have in mind at once) is very limited, the complexity of a chunk is essentially unlimited. What determines chunk size is basically an individual's experience relating to the kind of information under question.

Let's illustrate with an example: What makes information useful is the meaning we attach to the data we receive. A baby learns about shapes by observing them in different objects under different circumstances. Round things roll around and are fun so something which is round may be identified as something with which to play. The sight of a ball then constitutes a simple chunk of information. At a later stage of development, the same shape may be associated with a name: ball. The sound of the word "ball" is the next chunk.

Later, the child's parent explains that a round shape also represents the letter "o." This is another chunk of information, which is soon associated with a set of possible sounds which it can make. When the child begins to read, s/he begins processing words one letter at a time, since s/he doesn't have enough experience with words yet to process more than one letter at a time. The child perceives in chunks of individual letters. Eventually, however, the child comes to recognize whole words. Each word becomes it's own chunk and the child is ready to start reading sentences, first one word at a time, and then later taking in an entire sentence as a chunk. (Children can process a whole thought expressed orally much earlier than they can read them, so this last step is purely an advance in reading ability.)

One of the primary functions of an educator is to break down large chunks into smaller chunks so that students can absorb and rehearse them until they master them. Then a teacher can slowly present larger and larger chunks.

Computers only processes very small chunks of information—only one machine instruction at a time. However, since it's not feasible to write all our computer programs in machine language, we create frameworks for ourselves which approximate the educational process. A compiler or interpreter provides us the ability to divide tasks into objects and subroutines. So we can write computer programs the way we think.

Of course, the computer doesn't need to practice to acquire a new chunk. It does exactly what you tell it. However, the programmer, like the teacher struggles to overcome the limitation inherent in human thinking: once you think in big chunks, it's hard to communicate in little chunks. So the programmer has to check each chunk thoroughly to make sure s/he communicated it accurately.

Coding in chunks facilitates programming and also makes the program easier to read. In truth, programming usually is an educational process, though this isn't always acknowledged; at some point or another, other programmers have to learn the code. This is where we have to discuss some practical aspects of programming.

Here are a few precepts I believe are important to both teachers and computer programmers:

Specify the specific goal clearly. This is true for everything in life. In Stephen Covey's words, begin with the end in mind. Anyone undertaking an endeavor will be more effective with a clearly defined measure of what s/he wants to accomplish. The easier it is to measure progress towards the goal, the easier it will be to attain that goal. A teacher ought to have an observable objective for each lesson so that both s/he and the student will know if the student is succeeding. Ultimately, this can be the basis for a grade. At the beginning of a lesson, however, it enables the teacher to provide appropriate feedback. People learn by repetition. Only a teacher who can objectively measure a student's initial success can ensure that the student won't be practicing a mistake. If the teacher can provide a means for the student to measure his/her own success, the transition from guided practice to independent practice will be easier. This is also the idea behind test-first development. Only when the programmer's goal can be translated into a well-defined test can s/he be sure of meeting that goal.

Take small steps towards the goal; measure progress often. People have a very limited capacity for processing new information; on average the limit is between 3 and 5 new pieces of information at a time. A teacher must break complex tasks into simpler ones, large quantities of information into smaller ones, so that students can gradually and steadily accomplish the learning goals. Programming demands a similar approach, but often for the opposite reason: it is hard for the developer to hold the nitty-gritty details of a moderate-sized program in mind at once. It is also impossible to effectively test more than one aspect of a program or module at a time.

Communicate intent clearly. Ultimately, both teaching and computer programming are a form of communication. A teacher communicates new ideas and skills to students. A computer programmer communicates with the computer, but more importantly with other programmers and with the users. Both the teacher and the computer programmer need to be sly and effective about how they communicate. It's well known that students aren't always receptive. It's less known that a programmer's audience is also often less-than-receptive. Users often can't be bothered to read the manual; they expect an intuitive interface. Other programmers usually can't or won't take time to read the code carefully.