Here are my thoughts about the inheritance slides.  If you did it
differently at Garfield and want to change things, that's fine, but
I'll give you my thoughts on the current version.  If you follow the
usual 142 flow, I think you won't finish early this time, because
there's a lot more code this time and more things to do and talk
about.  The slides have been flushed out a lot, too.  The old deck
assumed that the instructor would ramble on at the start a lot about
the company and employees (which you didn't do way back when, which
was probably actually a good thing, because that content isn't very
dense).  The current deck assumes a more brisk explanation of that
conceptual situation, more like what you did, which I think is the
better choice.  Here are specific comments; I'll refer to slides based
on the numbers in the 10au version.

* Slides 3-4: I do go through this employee analogy, but I try not to
spend a ton of time on it.  I explain the idea, the big/small training
manuals, etc.  And I describe the benefits and how this relates to
Java.  But I try not to get stuck here talking a lot about something
abstract that isn't code.  Another way you could approach this part is
that you could describe it without the "inheritance", that is, you
could say that the company gives everyone a 25-page manual but that
~20 pages of the manual are the same and 1-2 pages are mostly the same
/ identical for *most* of the subtypes.  Etc.  Up to you.

* Slides 7-8: I start out with the Employee class in my jGRASP, but
then I write Secretary with them.  I copy/paste Employee.java into
Secretary.java that we create, and then we change the class name and
add the new method.  I ask what they think of it, and of course they
tell me it's redundant.  I tell them this is an interesting new
situation that we haven't really been in before.  We've often had
redundant code that we put into methods, but this is an entire
redundant CLASS.  This is a situation we now find ourselves in now
that we're doing object-oriented programming.

Usually as I am implementing these various employee classes, after I
compile one, I go to Interactions and construct one and call some of
its various methods.  I don't make a client with a main method or
anything, usually, for speed.  I don't usually use the debugger to
step inside the methods because I think that doesn't really help for
such small methods.  Just seeing the output/behavior is enough I
think.  And I always use the same variable type as object type; I
never say,  Employee ed = new Secretary();

(Side note: Somebody once got offended because I used a female name
for the secretary.  Secretary suzy = new Secretary();  She said, why
does the secretary have to be a woman?  So now I always use Secretary
stan or something like that.  And I try to make the Lawyer a woman.
Lawyer lisa, etc.  The things we do for political correctness!)

* Slide 11: When I'm first showing them inheritance, I mostly describe
it as though it were a copy/paste of the superclass's innards into the
subclass.  I don't really go into the fact that it enables
polymorphism and that sort of thing; that's too subtle for them right
now.  I save that for a later lecture.

* Slide 13: When I describe Lawyer, I ask them for ideas on how to
implement that class, because it's similar to Employee but doesn't
want to inherit everything.  It's interesting to see what they say.
We could just not use inheritance.  Sometimes they ask if we can
extend individual methods, copy some but not all.  They can be
creative sometimes.  They sometimes do come up with the right idea,
extending but then replacing some parts.

* Slide 16: I don't actually write the Marketer shown here.  I like
having it in the slides, but it doesn't teach anything new, so I don't
spend class time on it.  I do actually implement the LegalSecretary
and all the other previous ones "live" with them, though.

* Slide 20: It would be good for you to get to at least some of this
'super' material Monday if possible.  I usually get through all of
these slides myself, because they are not all very dense.

I usually sit here on slide 20 and ask them what to do.  They tell me
to go to the 3 various places and change the salaries to implement the
overall raise.  Then I ask what is bad about this situation; they
usually do correctly say that it's bad to have to edit so many places
to change just one policy.  They usually suggest things like making a
constant.  Sometimes they ask me if it's legal for Secretary's
getSalary method to say, Employee.getSalary() or somesuch.  I tell
them that's a great instinct but not quite the right syntax.  Then I
show them slide 23 with the super syntax and we go from there.

* If you got all the way to the end and had even more time left, I
would just implement one more class with an interesting use of super.
For example, implement a PatentLawyer who is like Lawyer but his sue()
method prints:

You violated my intellectual property.
I'll see you in court!
I'm gonna take all your money now.

That way the super.sue() call is in the middle.  Something like that.
You probably won't have extra time, but I'm just showing what
generally I would do if I found myself here and had 4 minutes left
somehow.