For newbies, good examples are devoid of abstractions. They are concrete and clearly—almost too clearly—convey the intentions of what we’re teaching. They provide good context.

On the other hand, poor examples are littered with abstractions and vague differentiations. Here’s a classic case of such an example.

When Clarity Met Sally

Imagine we’re teaching a beginning programmer the basics of object-oriented programming. We might start, naturally, by discussing class constructors and object instantiation. At some point in our talk, we scribble a line of code like this:

For us, this is a ho-hum line of example code. It says to create an instance of an object of type Object, called myObject. It’s known to us that the name myObject is just any old name we decide to give this newly birthed instance. On the contrary, the constructor Object isn’t just named anything we want; it has to be named exactly the same as the name of the class.

We can mention all of this to our student. He can take notes and read them over again. To someone learning object instantiation for the first time, that seemingly straightforward line of code is going to look like this:

For someone just beginning, it’s hard to conceptualize which Object is the type, which is the constructor, and which is the name of the instance. Cover up that line of code and ask the student to rewrite it, and don’t be surprised if he gives you something like Object Object() = new myObject; or my new Object = Object();.

Let’s start making that example more obvious. Here’s a better rewrite:

Now we’re getting somewhere. Object is still important, but it’s clear that it has no implications on the name of the instance of the object. It’s also more evident now that the name of the instance lives to the right of its type.

Still, for a first-time object-oriented programmer, this could still be a little too in-the-weeds. Of all the possible types of objects we could create, the one called Object could very well be the most abstract of them all. Let’s stick to our goal of avoiding unnecessary abstractions. Let’s modify our example again, with a much more descriptive name:

Ah, yes! Now, Human is significant. The relationship between Human and sally is intuitive for anyone living on this planet, even for someone who doesn’t write code for a living. It’s obvious that sally is the name we’ve chosen to call this instance of Human.

However, something is still hard to understand. A newbie’s next question might be this: if we already say “Human Sally,” isn’t it obvious that she’s a new Human? What, exactly, is the point of a constructor?

Constructors that don’t accept any parameters are fairly common in programming. For the seasoned developer, we’re accustomed to working with classes that don’t accept any parameters when instantiated. We leave them without parameters until we find good reason to add constructors that require more information at the time of construction. And so, the conventional new Object() (or new Human() or new List<DateTime>()) feels intuitive to us.

To the newbie, it seems mindless. Constructors that don’t accept parameters and, even worse, don’t do anything in their definition aside from instantiating the object, baffle the OOP neophyte. So, sometimes even the default approach to a concept isn’t always the best example for teaching that concept to someone new. In this case, we’re far better off making the example constructor accept a parameter (or two).

Ask the newbie if he can create another human named Harry, who just got his driver’s license, and there’s a good chance he’ll be able to figure out the answer.

When showcasing examples, be overwhelmingly obvious. Sacrifice the default approach for the more explicit one. Cut out the generalities, generic names, and theory for something tangible and obvious. Even an example as fundamental as object instantiation went through four iterations to get to the point of clarity.