Teaching C#, Java, etc. to students who are bad at OOP

Question

Last semester, I was assigned two classes of C# and assuming them to be well-versed in Programming Fundamentals (PF) and Object Oriented Programming (OOP), I started the course at normal pace. After a few weeks, I took an introductory lab test (it was pretty easy one actually, summation of n Fibonacci terms) and some of the astonishing "discoveries" after my round of the class (about 30 mins after assigning the task) were:

• Around 1/3rd didn't have Visual Studio installed
• One guy was coding it in SQL Server (genius?)
• Those who didn't have VS installed were given option of online IDEs (like this one) and it "dawned" upon me that they were coding in Java (didn't even care to change Language in options)

Then, during lecture, I discovered some more facts, like:

• In a class of 50, less than 10 knew the concept of basic OOP like Inheritance or static members.
• Non has implemented Polymorphism before.
• Function Pointers was a thing unknown to them (even they had studied OS and I think PThreads are pretty much part of it)

It not only left me heart-broken, but also prompted me to teach them OOP's concepts from scratch, which meant that I had to compromise over some advanced topics of .Net

Question

Now my question is that, what should be the correct approach to teach an advanced language like C#, Java to a class given:

1. Majority of them are bad at OOP (lets assume they are ok at PF)
2. There are some students which are/were good at OOP and eager to learn new technology (and should not be punished for others mistakes/negligence)
3. There is no Lab to complement your class (even the lab test I took was by my own efforts)

Update

As per @Jay and @Buffy's points, here is further explanation:

• It is a recurring process as although I have taught C# only once but observed such a weak links (in Programming Fundamentals and especially OOP) when teaching other courses as well.
• I don't have enough power to arrange Bootcamps (I used to have them in earlier institute but here limited class rooms means we can't arrange Bootcamps unfortunately)
• I don't have enough power to affect the overall process either.

Looking forward to your interesting inputs. Thanks.

Answer 1

One thing to keep in mind is that topics that seem obvious to you (who presumably has years of experience) are not at all obvious to novices.

Stuff like:

• Which editor should I be using?
• How do I compile code again?
• What's the difference between a class and an instance?

This stuff is obvious to you because you've had years of experience. But these students have taken a couple classes so far. That's not enough experience for this stuff to be obvious or come naturally yet.

So you're going to have to hold their hands a little bit more, especially at the beginning of the course. Spend a class reviewing the stuff you assume they already know, or walking through what you expect them to do.

• "Does everybody have Visual Studio installed?"
• "Okay, for your first assignment, let's make sure you have everything hooked up correctly by compiling and running this basic program."
• "Everybody remember OOP? Who can remind us of what static means?"
• "Your next homework assignment is to take OOP to the next level by..."

I'm not saying you should spend half your course on this catch-up, but spending part of your first class on this, and assigning a few token homework assignments to make sure everybody is on the same page, will go a long way.

Taking a step back, you say that it took you a few weeks to realize that students weren't at the level you thought they were. Why did it take you so long? You should be finding this stuff out as early as possible, and correcting it before you start throwing tests at them. That makes it sound like you were lecturing without really engaging the students or making sure they understood what you were talking about, which is not great.

Instead, you need to make sure you're engaging students by meeting them at their level. Understand that they don't have years of experience, and that they might need to be reminded of things that you think are obvious. A little bit of understanding your students will go a long way here.

Answer 2

I know exactly what you are talking about. Back when I was still ( I am glad I am no longer doing that) working as a faculty in a university, I ran into situations like this. In fact, with my usual style, I got confrontational with the faculty who was supposed to teach OOP in the previous semester and stuff happened.

Here is what I did.

1. First up, the logistics. I had a detailed discussion with the HOD and also with the students, and convinced all of them to come for additional classes (I called them Bootcamps)
2. The Bootcamp was a 2 day affair ( 6 hours each ) and was held on a holiday. No attendance or anything like that. Students who are serious can come (and 80 % of the class showed up)
3. Taught the basics of OOPS. I essentially summarised the entire semester worth of contents into 12 hours.

Did this work? For me, it did. I was able to carry on with my usual syllabus with confidence that they are at least, not as blind as before. sure, I had to spend 2 of my personal days, but it was worth it.

Here are the things I crunched on those 2 days.

• Classes and Objects (and the interconnection between, and compared them favourably with structs)
• Encapsulation (especially private and public and why this is important)
• Inheritance (the big boss of OOP, and by far the most important thing about any OOP language)
• Polymorphism (although this was pretty straightforward and did not drive people crazy like inheritance or the initial discussion of classes and objects)

So, talking from first experience, the situation you described is the norm rather than the exception. If you want to get them up to speed, I suggest a bootcamp or a similar variation.

Answer 3

tl;dr: (a) solve the problem at its root, (b) know your students.

There are some things that aren't clear from your question and they impact on what action is appropriate.

First, you describe the problem in the past tense. But is it a continuing problem or just a one time occurrence due to poor instruction in previous terms? If is just a one-off, perhaps you don't need any solution at all. If you expect it to continue, perhaps you should attack the problem at its root.

You don't describe your own position within the institution. Do you have any power at all to affect the overall process? Can you start discussions about what is happening and come to an overall solution, perhaps involving other courses, that make the problem go away. The specific symptoms you describe seem to imply poor teaching in an earlier term. Can your institution fix that problem (if that is really it)? Perhaps an earlier professor needs help and is either inexperienced or was him/herself faced with a problem such as yours and had to compensate just as you did.

Of course, you need to be proactive in a situation in which it is likely to recur. Do something at the very start to help you know your students better. A few weeks is far too late to learn these things. Some sort of exam or exercise at the start can tell you a lot. If you wind up in the same situation again and need to compensate, a boot camp such as suggested by Jay here might work for you. You can also prepare a checklist of tasks for the students on the first day (Install the IDE...). Also a syllabus that details expectations (using the appropriate language...). If you can't make assumptions about the students, as you seem to have done, then try to anticipate the problems.

But if you are without power to affect anything, then you are also at professional risk if the students don't complete the course requirements and pass into the next course. This again, suggests that you have an institutional problem and not just one with a given class.

Note that institutional change may be difficult. In some institutions students are allowed to take courses without the necessary prerequisites. In some institutions that accept students from elsewhere, it is difficult to impossible to assess the real skills of the students prior to enrollment. If any such issues are present, a discussion within the department about how to make everything work is called for. It need not be confrontational.