Realism in teaching examples/questions is a bit of a red herring. Corporate education particularly loves the buzzword of 'business-relevant', but I think it's often actively harmful.
When you're teaching something new, you want to be able to isolate that concept/technique and focus in on it. A simplified example, or a question with strict parameters, both allow the student(s) to concentrate on the key idea.
If you want to teach someone about SELECT in SQL, for example, it's useful to abstract away the database setup for that particular lesson. It's also useful to use a simplified database concerned with familiar entities, so that SELECT remains the focus rather than one new element of many.
Of course, these simplified examples shouldn't be used in isolation. Instead, you should have a number of them, eaching illustrating/assessing some small point or idea. Once the students have absorbed those ideas, then you start combining the initial building blocks into more complex ideas, just as you'd take a tiered approach when testing software; start with unit tests, then build up.
While I think that you are right, but the right level of abstraction is super important. Here teachers should try to look at the business relevant applications. In university we had one course on databases. This was introduced by means of formal relational databases and relational algebra. Most of the students explained the stuff to each other by working with the more concrete translation in SQL. So if you had problems understanding what the restriction operation (σ) did, somebody told you that it maps to a SELECT in SQL.
What's interesting is that I had my one database course in college that taught relational algebra. We had access to an Oracle database against which we probably only wrote a handful of queries. Almost all of the work was, well, math and theory.
When I got my first development job, I started out scribbling relational algebra on scrap paper and then translating it to SQL. I got faster and faster until I could think in SQL.
Agreed; you have to find a level that clicks for your students otherwise you're just throwing jargon at them. It's difficult to balance because knowing the subject well is required to teach it well, but knowing the subject well also means that your preferred abstractions are going to be too complicated [1].
A lot of people who want/need to understand the broad strokes of a database and how to query it effectively don't need to understand the deep, deep under-pinnings, and (unless you approach it cautiously) diving into it all will be actively counter-productive.
There should be examples (saying things like "oh, by the way, the projection operator is the SELECT clause of a SQL query" costs literally zero) but theory is important.
People who don't understand relational theory can't write SQL to save their lives.
I've seen schemas that literally made me scream.
I think the same applies to algorithms and data structures, e.g. red-black trees from the Cormen are literally std::map.
I found it to be a bit of a chicken-and-egg problem. At the time I learned it, I didn't really understand why relational theory was important. I trusted that it was, I just didn't really grok all of it. But later I found it of immense practical help when writing, and especially debugging, sql queries.
Perhaps the ideal order to learn in would be practical, theoretical, practical (applied theoretical), though that's just a gut feeling.
I dunno. I learned relational theory in college along with SQL. Since then, I've forgotten all of relational theory since I never used it for anything, but my SQL has improved quite a lot through use.
I'm thinking you may have a third variable problem here; people who write sucky SQL tend not to have spent a lot of time thinking about how to write non-sucky SQL. People who write non-sucky SQL have. The former has nearly zero chance to have been exposed to relational theory...the latter has a non-zero chance to have been. Correlation /= causation and all that, and the actual causative variable is time spent learning how to write non-sucky SQL.
> People who don't understand relational theory can't write SQL to save their lives.
Source?
From anecdotal experience, I've seen countless developers write reasonably acceptable SQL without even knowing relational algebra exists in the first place.
I disagree with this traditional pedagogical approach. Learning is much easier when motivated by a complex problem to solve that requires learning and applying multiple "building block" concepts. Start big, then learn small.
It seems counter-intuitive, but I've found that this works for me also. For example, I could never learn basic mathematical concepts until I had seem them in action as a part of a larger framework or practical problem.
For example, differentiation by itself is just pushing symbols around according to some arbitrary-seeming rules. It's not until I did physics that its purpose made sense. I studied calculus for years, and it never "clicked" for me, and I forgot most of it promptly. Then in just a semester of physics where I was applying it in the context of complicated problems, it suddenly felt like second-nature. I had to basically re-learn all of it from scratch, but with the context of my physics problems it was so easy!
I've had similar experiences teaching programming to junior staff. Anything you talk about in isolation goes in one ear and out the other. They have to encounter the problem in something larger that they are solving for the solution to make sense and motivate them to learn.
An example is string-escaping. E.g.: how do you represent the quote symbol in a quoted string? This seems trivial, but it trips up everyone when they are getting started. I mean literally everyone. So okay, I make sure to cover it in like... lesson #1 or #2 because string literals are everywhere, and escaping is common. Every single time, the people that sat through that lesson will ask me a week later to help me fix as program that has a literal like 'O'Brian' in it, and they can't figure out why it's broken. But once I show them that they should have used 'O''Brian' or 'O\'Brian', it all makes sense to them and they memorise the technique.
Yes. I always found it odd, especially in mathematical textbooks, but to some degree also other areas, when a field is explained top down from a theory that is the end result of hundreds of years of discovery, fiddling and trial and error. As if that whole theory was god given and just happened without motivation or process. Besides making it harder to understand by going abstract idea first, it also makes it harder to develop an understanding for how people come up with and improve ideas over time.
About 20 years ago I read a book on spread spectrum radio. Unlike all the others each chapter was in three parts. The first part explained the problem. The things people tried to solve it. Problems with those solutions. And then second part explained the canonical solution, how it solved issues. The third was a formal description and analysis
That book was totally great. Even if you got lost in the math reading the last formal part you understood what was going on.
It makes complete sense for mathematics. Few of the mathematicians I know have any interest in applying math to much of anything besides math research. The whole business is entirely abstract.
I dont see how it is easier. Maybe it is motivating for someone, but I never found it easier to deal with complex problems first and only then moving to simple one. For me, it was easier to learn simple things first. And "do simple thing first" also seems to work much better at my kids, no matter what I am teaching them.
I find it motivating to have the story of how someone uses the skill to solve a complex real-world problem. I think you are right that it is overwhelming to start out by solving that complex large-scope problem first.
Absolutely, but that's a framing device/motivational aspect, rather than the mechanics of the actual learning.
"Here's what we're aiming for, and here's why it matters" should be the introduction, setting the scene and establishing the flow, but then you introduce the various blocks-that-will-be-built and start working up to them in the stepped fashion.
I think the missing link is going from a real world application to a practical teaching problem. A topic that motivates an audience would also depend on the audience.
Trying to think of a good example reminds me of a puzzle game; and how sometimes the contrived puzzles in such games can be obtuse or phrased poorly because they really don't want to give away the answer.
The example should start with an unsolvable problem, then simplify aspects to make it more of an estimation model; which is a useful skill as well.
That requires for the person to actually care about the complex problem, otherwise they'll ignore it and focus on the the individual building blocks in isolation.
Oh man, I have some vitriolic opinions on the sate of modern teaching -- especially vis-à-vis textbooks and written "pedagogy" that go crazy with this "isolation," "abstraction," and "distillation" of the concept: I hate it, please stop doing this.
I feel even more strongly about this for mathematics and computer science: you cannot strip away the context of a technique/idea/concept, and hope to have people understand why it's useful. For example, I'm currently self-teaching myself mathematics. Calculus and its techniques (integration, differentiation, solving PDEs/ODEs, whatever) are easy -- when you understand the context: physical mechanics. Strip that away and what do you get? Symbols and equations that have zero meaning in the real world. It's effectively indistinguishable from GPT-3 text -- it's utter nonsense that doesn't make any sense unless you've already learned the concepts somewhere else, and can piece together what the hell the author is trying to get across (sometimes, the author doesn't even know, but pretends to know!).
Same with probability and statistics. I cannot understand the sheer myopia needed to completely strip away probability from its gambling context: how does this benefit learners? I wasn't able to teach myself these things from regular stats & prob books, because it's schizophrenic gibberish without any context -- without even a single example of a practical application, much less "why is this useful? Why was this brought into the world? Why are you using Brownian Motion for actions of living things???" And then I picked up some theory of gambling books, and lo and behold everything makes sense. There is no cruft. There are no "gotchas" where you need to slam your head against the desk, and force yourself through the problems for it to "click"; everything just clicks because you understand why a certain technique or concept exists, and where it's applicable.
In short, the original context that lead to the creation of a certain technique/concept is enough of a "stage" to teach it; anything more abstract and you're cutting through bone.
Yes; a lot of tech (and other subjects, but especially tech) education is sadly low-quality, being either way too surface-level (learn to make a Twitter clone in 20 minutes by coping & pasting) or far too arcane and assuming a lot of prior knowledge.
I think we're making progress though - we know how to be more effective, but it's a slow process to get there. Mastery of a subject does not necessarily include mastery of how to effectively teach it, and we need to start treating the 'education' bit of 'tech education' as an important and separate element requiring expertise.
When you're teaching something new, you want to be able to isolate that concept/technique and focus in on it. A simplified example, or a question with strict parameters, both allow the student(s) to concentrate on the key idea.
If you want to teach someone about SELECT in SQL, for example, it's useful to abstract away the database setup for that particular lesson. It's also useful to use a simplified database concerned with familiar entities, so that SELECT remains the focus rather than one new element of many.
Of course, these simplified examples shouldn't be used in isolation. Instead, you should have a number of them, eaching illustrating/assessing some small point or idea. Once the students have absorbed those ideas, then you start combining the initial building blocks into more complex ideas, just as you'd take a tiered approach when testing software; start with unit tests, then build up.
Effective education moves in steps.