Tutoring computer science, you deal with constructs that are both ideas and real-life segments of code.  The tutor brings forth the idea of subroutines.

In old-style programming (ie, during the 70s and 80s), the concept of a subroutine was crucial.  Other names for it were “procedure” or “function”.  The subroutine was a self-contained mini-program that was called, did a job for the main program, then was left alone again.  It could be called repeatedly.  A typical program you might write for an assignment could have numerous subroutines; a large program might easily have dozens or more.

As I recall, before the days of object-oriented programming, subroutines were the focus. Students were taught to think and program in terms of subroutines: the main task was meant to be divided into smaller, separate ones, for each of which a subroutine could be written. Not only could each subroutine be written independently; it could also be tested independently.  Finding a bug is much easier in a subroutine than in a larger program.  Moreover, it is easier for another person, who didn’t write the program, to understand how it works when the program’s functionality is divided among subroutines. Each subroutine would, of course, be appropriately commented (see my post here), so that the reader would easily know its purpose.

The approach to programming that centers around subroutines is called procedural. You’ll hear it called the procedural paradigm. While it’s probably been eclipsed by object oriented programming (the object oriented paradigm), it’s still preferred in some circles.

I’ll be further discussing underlying approaches to programming – for instance, the object oriented approach – in future posts. Cheers:)

Source: Wikipedia
Jack of Oracle Tutoring by Jack and Diane, Campbell River, BC.