The word "procedures" here is a bit of an anachronism I guess. Today we talk mostly of "methods " Perhaps we talk about "functions" or "subroutines" but we are really talking about the same things. We are talking about small routines with a defined way in and a defined way out. Generally we work pretty hard to make sure there is only one way in and one way out.
This is another proverb that has so become ingrained into the way we write code today that few even think about it. That's probably a good thing. Today we don't think about huge programs but about lots of small methods/functions/subroutines/procedures. These are the logical units that make up our solution.
One thing I would add to this thinking is that we need to teach more about refactoring. Beginners have this tendency to have code that grows over time. What starts out as a small, simple routine grows and grows in size and complexity. We need to teach beginners to recognize when something is too big and then how to create a new small procedure (or several) from the mess.
Refactoring tools that allow us to make this happen in an automated fashion have the potential to help avoid a lot of cut and paste errors. Some may argue that this is an advanced tool but I wonder if it is not even more important for beginners to learn. Experienced professionals working from a good design are less likely to need these tools unless the scope of a program changes unexpectedly. Well it's a theory anyway. Probably an unreasonable dream. But still teach them about this early. Maybe it will help get them into the "small is good" frame of mind early.
This is the sixth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.