[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 20366



File: 1479916968633.png (26.53 KB, 300x218, images.duckduckgo.com.png)

No.20366

The firm I work at has decided that I am to teach a course. Mainly I am supposed to teach some guys how to access a database using SQL and R. (I know, I know, SQL is not programming, but I hope you get my point).

I am a self taught programmer. So I tried to replicate my learning experience: This is, once you get a problem to work solve, read the documentation until I figure out a way. Since its a course, I thought I would give them little pices of information about SQL, and then give them a problem they can solve with that pice of information. Then start building up their knowledge by increasing the problems they need to solve, until I finally introduce them into the real work their are going to have to execute.

First thing I did was show them some regular expressions, and made the participants match 8 digits using \d (just type \d 8 times). They just could not do it, I did not even see them try. Obviosly, I gave up in my aproach about let them work out the stuff, and just spoonfed them all the info I wanted them to get out for the session.

How do you guys teach programming to other people? Mainly, how do you engage them to make them think about the problem? Do you approach the transfer of information in a different way?

Maybe I am to caught up in the socratic method of teaching: I wanted them to discuss the problems, while I led this discussion towards a solution. Maybe there is a better way to do it. Any opinions on this?

  No.20367

>>20366

I am also well aware that all these problems I am having might be due to the fact that I am not explaining myself, or I completely suck at teaching. But for the sake of argument, maybe we it could be assumed that this is not the case.

  No.20368

>>20366
the only way to learn to program is to do it, if they are interested they will do what you did and teach them self and use you as a resource when it is more convenient than searching the wired.
Other wise they will only do what you explicitly force them to do. basically you need to come up with a list of programs for them to write that lead into each other covering all the info you need to give them. then spend each lesson walking them through the programs and at the end when they don't get it you can say "look I covered everything and gave all the help I could not my fault".
Also don't forget to ask for feed back, they will give you a bunch of bullsoykaf excuses as to why they don't get it. (ie "explain in more detail" "do more examples on the board" anything but "I never practice") so just do what ever they say and cover your self that way.

  No.20375

You could look for pre-existing courses to get ideas from. No need to reinvent the wheel.

  No.20383

>First thing I did was show them some regular expressions, and made the participants match 8 digits using \d (just type \d 8 times). They just could not do it, I did not even see them try.
How much did you tell them the rules of the game? To someone who's been programming, the concept of appending more \ds onto the first one to mean "more digits" is intuitive, because such chaining shows up in virtually every language we use. To a beginner, it might be too difficult.

My only suggestion here is to run through more than one example problem, then start them off on a problem that's essentially just copypasting one of your old solutions. Let consult your examples as much as they want so they can study and internalize what it means.

And give them lots of positive feedback when they do well. Programming is really disheartening and unintuitive for beginners. Your task is hard because you have to teach very domain specific tools. Good luck, I like helping students but I'm not a great teacher so I don't have much advice other than start with a really gradual learning curve and don't forget to praise their work.

  No.20388

>>20383

>How much did you tell them the rules of the game? To someone who's been programming, the concept of appending more \ds onto the first one to mean "more digits" is intuitive, because such chaining shows up in virtually every language we use. To a beginner, it might be too difficult.


I think you might be right. I did a couple of examples, matching "hello world", extracting "hell" and what not, but I might have been overly informal with such "rules".

Thanks to everyone that gave some input!

  No.20395

read the preface of the first sicp edition.
read the preface of the second htdp edition.

  No.20399

>>20366
First: know you enemies, or in this case, your audience.
What do they care about? What do they do every day?
From this create examples to teach your course.
Are they mostly accountants? Teach them how to manipulate/check accounting statements automatically.
Are they marketing people: Show them a simple automailer with personalized introduction and maybe also personalized reduction offer based on how much the client bought during the last year.

SQL is particularly useful for that since it was originally developed for nonprogrammers.
R too, although it was developed for scientists so the bar may be higher.

I taught a bright 10 year old some basic programming concepts like loops, ifs and variables using games (scratch, then pygame, then Game Maker studio) because thats what he cared about.

Then instead of preaching, try teaching using as many questions as possible. This is called the socratic method (look it up and google it). If done well (difficult) it is very effective because the students "teach themselves", the knowledge is retained easier since it is knowledge they found/created themselves, not something they read in a book.

Do not overload your audience either. 1-3 concepts at a time or less. Try to have a red string through your course: the lessons should build upon each other.

Source: I have been a private tutor since 2008

  No.20520

Assuming the course is meant to be simple and informal (no heavy relational DB theory or statistics involved), consider following along the W3C tutorial: http://www.w3schools.com/sql/default.asp

Unfortunately, it probably is the case that these people don't care too much about learning and they're just there because they have to. A self-teaching approach only works when the individual is motivated, curious and critical. It's very disheartening, but if your audience can't ultimately be made to care about the topic, straight up telling them the essentials of what they have to do might be all you can do. Especially since you're not an experienced teacher, so it can't be expected that you can pull of some incredible stunts of pedagogy.

But if you're feeling adventurous, an approach you might want to use (dunno how much time you have available though) is to start by trying and teaching them programming without actually writing code, to get into the right mindset.
Programming is ultimately about putting together a plan to solve a problem. Present them with an intuitive, real life scenario with a set of very basic tools to solve it: cooking might work well, recipes are basically code already. Take an onion, peel, rinse, cut it; heat oil in a pan, sauté UNTIL brown (you've got a loop already). Many cakes require preparing custard for filling: like most cooking books do, show how to make it once, then wrap it in functional abstraction and call CUSTARD(eggs, milk, sugar) whenever its needed afterwards. Hell, advanced recipes even require multitasking.

You do this drawing a flowchart at the whiteboard from their input a few times, then start replacing onions with integers.

Regardless of the fluff you put around them, flowchart-based applications are often used to introduce children to programming because they give a visual representation of what you'd otherwise put in code, which is usually less intuitive.

Godspeed, lain.

  No.20904

https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1
Read the first section of this, the part before 1.1.1. I think this is the best way to teach, explaining the structure of the language. Regex is small so this shouldn't be hard. You should first explain the primitives (a matches a, . matches a single character, \d matches digits, etc.), then the ways to combine them (concatenation, repetition, etc.), and abstractions (groupings).