How to keep students heads from exploding from complex, interconnected topics

Question

My students will soon be learning ADO.Net in C#, adding on to the Windows programming skills that they recently gained. Just a few pages from one chapter in the textbook introduce the set of layers and interconnected objects needed to do the simplest first program: a DataGridView that allows full update of a table. I have taught this once before, so I have some idea what landmines to avoid, but the fact is that they will need to know pretty much the whole picture to do anything. As Chogyam Trungpa said (about the spiritual path), "It is like swallowing a porcupine: once you start, you have to eat the whole thing."

I was able to learn and understand all of this last year because I had the fortunate accident of a very intense introduction to database programming in my first "real job" in 1989, taking over the development and support of a PC distributed database product written in C. I had no significant instruction in databases before that except to do some work with dBase III. I know the concepts that dictate the structure of the ADO.Net classes, because I learned these fundamental, invariant ideas in an entirely different context. Thus, I can also teach these concepts.

But with so many moving parts to master up front, I think that the students get very deeply lost, and it is hard to disentangle their errors and help them even start on some lab exercises. Do you have any suggestions for how to introduce a subject where one must know so many new ideas all at once in order to begin?

Answer 1

Students are better able to handle structured information when they understand, at the start, what that structure is.

Explain the situation to your students. You are about to present a series of deeply interconnected systems, and though they form a beautiful system together, they essentially can't do anything until they're all moving in tandem. That means that there are two levels of learning that the students must engage in:

1. The systems themselves; and
2. how they play with one another.

I would show them a list of the systems at play in as neat of a form as I could. I am unfamiliar with the topic that you are teaching, so I don't know if this would be possible, but an interconnected graph would be ideal for this.

Explain that you will be going through the systems (the nodes), and that students can make a check-mark on each node as they come to understand them independently. But you will also be going over the vertices, and these are just as important. They also need check-marks.

Over the course of the unit, students can refer to this graph as a way to measure their own progress and understanding, and to take charge of their own learning.

This graph has an additional benefit; your own teaching can now follow the same model. You now have a structure that the students will already understand from which to spin out your lessons. And if a student seems to be having trouble, pull that graph out and have that student begin explaining certain nodes or vertices back to you; it should quickly become apparent where the confusion lies.

Good luck!

Answer 2

This answer is a supplement to those of BenI. and ctrl-alt-delor, with a specific suggestion. Call it an implementation strategy.

Your problem is that the topic is broad, with lots of parts. You can show them the big picture by showing them a complete application that is as shallow as can be (broad but shallow). It has all the parts, but each part is as simple as you can make it. It could even be a dummy app with almost no functionality. That is a way to implement BenI.'s solution. Then have them work with it to deepen parts of it (as ctrl-alt-delor suggests) filling in gaps.

If you give them a complete simple solution it is an example of the Lay of the Land Pedagogical Pattern or Kerstin Voigt's Big Picture on a Small Scale

An alternative is to do the above but also break your solution a bit in ways that fixing it will be instructive and then give them the broken almost solution with instructions to fix it. That would make it an example of the Fixer-Upper, which can be found in the book, also.

This might be a good place to use teamwork or pairing so that the students can help one another with understanding the parts and the connections.

Answer 3

It seems that you are not teaching a subject, but training in the use of a tool.

First ask what is your objective. Is it to train in this tool, or to teach computing principles.

Then in either case, teach the principles (first or only).

Get them to do part of the problem/program «fill in the gaps».

I have been playing with couch-db / mustache / html / css, each of this can be taught separately, and some have multiple parts, and you can't really understand couch-db without it all. So a similar situation.

I would

• first look for parts that could be taught independently. And teach them.
• show them the big picture (See Ben.I's answer) (you may do this earlier, if needed, else show a smaller big picture earlier).
• then look at parts that you can teach by creating most of the solution your self, and having them «fill in the gaps». This should involve using only one, or a few, principles at a time.
• continue with them filling in the gaps or making improvements to your existing code. You may need several projects for them to work on. One for each fill in the gaps exercise.