Printable View
Hey everyone, I've just launched a new channel to help people out who are just starting programming, but at the same time go at a swift pace to avoid boring videos that drag. Check it out here:
quickcoding - YouTube
Any tips/suggestions on my teaching style? Can I improve anything? Honest feedback would be appreciated!
O_oQuote:
They are useful when you want to access other values without modifying the original value.
What? You want to teach people about pointers and you start with that rubbish?
What is the purpose of a video that is literally nothing but a text dump? There is no voice so you keep switching between text and source. There is not any real effort to highlight relevant portions of the source that the text references!
There is no purpose in making tutorials like this into a video. These are bad, and you should feel bad.
Soma
I appreciate your tips. I disagree that I should feel bad though. I actually feel better than ever that I have received honest criticism and I can improve :) You are the type of person I like, quick, honest and to the point.
He is correct, even if I don't agree with his style.Quote:
Originally Posted by quickcoding
Passing a pointer allows you to modify the original because it's passing the location of where the value is stored.
I think you need to spend about another 5 years learning C/C++ before you start making tuts.
:devil: Sorry if this seems a little nasty, but you hit two of my pet peeves here, lol.
I can't stand coding videos; they have to be one of the DUMBEST ideas ever. It is not pottery or skateboarding. Recipes are generally better in text too (you can refer to them as you work), although sometimes a cooking video gives you insight a text recipe does not (but when it comes time to make tish, you still want it written down).
The logic of cooking does not apply at all to programming. Programming is not, in any significant way, a physical or real time activity. The only justification for doing it on video is if it is a taped presentation someone did, or a tool demo (which has important real time aspects). Otherwise, there are ZERO advantages to a video, and quite a few disadvantages. I watched about half of the pointer flick, until some code appeared, which I had enough time to glance at and get the gist of. I am a fast reader with a good knowledge of C, meaning someone who was actually trying to learn something just saw some mumbo-jumbo with "int main" and an ampersand somewhere.
Of course, you can always pause! Then you can continue, then you can pause and rewind to look at the code again! ...ad infinitum. Ridiculous. Totally bass akward stupid. How about a simple page with a paragraph, some code, another paragraph?
Just my opinion, but if you disagree, you need your head checked. Honestly. And please don't spout any tripe about how "different people learn different ways"; it does not extend this far. In context: there is learning, and there is running around like a chicken with its head cut off. Coding videos are in the later category.
Yes, you should, because you are posing as someone qualified to teach others about C, but if you are explicitly wrong about very basic and fundamental concepts, the content of the constructive criticism is: before you try to teach, please try to learn. An analogy: if you fail your driver's license exam, you will receive some constructive criticism about why you are not qualified to drive yet. It does not mean: your driving could improve quite a bit, but don't let that stop you from hitting the streets alone.Quote:
Originally Posted by quickcoding
I totally believe in the value of learning through teaching, lol, and the desire to clarify things for yourself by preparing material to present to others. But I think you would be better off developing a set of examples with notes for yourself, keep them clear, organized, and explanatory as if they were for someone else (which you'll appreciate in a few months) and hold off a while before you make them public ;).
And please please save the video medium for content to which it is appropriate, NOT TEXT, and, especially, NOT CODE. Even performing a pop song about pointers in C would be an improvement. At least then you could introduce rhyming couplets as a mimetic aid. :p
This idea would not be so bad if you were a professor giving a lecture to a classroom, at the very least. From the video list, it looks like you've decided to cover the least difficult things, which are frankly the worst topics.
In addition to what everyone else said, I think your videos would be a ton better if you actually demonstrated the concepts you explain. The point of a video is to convey information in a different way, but only using scrolling text is no better than a tutorial of which you cannot copy and paste from.
For example, in your pointers video, it would have been helpful to use a debugger and show how the memory works. If you had a char pointer, for example, you could demonstrate it using a format similar to this:
- In memory address 0xFFFFABCD, you have an four-byte pointer. The video should then show your debugger examining the four bytes, showing 34 12 00 00. You start with the code
Code:char *ptr = malloc(6);
- Finding the address 0x00001234 at those bytes, you could visually show how the address is stored (endianness) using the debugger, and then examine that memory address's contents, let's say 26 26 26 26 26. This would be representing the code (which you would also show)
Code:memset(ptr, '&', 5);
- You could then add another pointer to the same address, with something like this:
and then print out the contents, showing the same string as before.Code:volatile char *newptr = (volatile char *)0x00001234;
- You could then show how pointer arithmetic works, and provide a visual diagram of how incrementing the pointer's location will point to another part of memory, while incrementing a dereferenced pointer will increment what it points to. A disassembly could aid this as well.
Are you teaching people to program on one of these?
Attachment 11572
The last time I saw a green screen, I was in my high school programming class, on a Tandy T1000, swapping my DOS 3.0 floppy for my Turbo Pascal 3.0 floppy. Yep, back when DOS fit on a single 320K floppy. Seriously, it would help the user a lot if you bothered to indent your code and use some syntax highlighting. Show them something that looks like modern programming, at least vim or emacs with syntax highlighting.
Frankly, I'd rather you don't show them anything at all. I applaud your effort, but you're no where near qualified yet to be teaching the masses (see the list below for issues). I must agree with Cynic and MK7, you need a lot, lot, lot more learning and experience before you start creating tutorials and teaching people. Misinforming lots of people is worse than not informing them at all (except perhaps if you're in the espionage business). I also must agree with the others, video is a horrible medium for teaching programming. The lack of copy-paste ability and the pause-rewind-pause crap is annoying.
Your tutorials are far too superficial and leave out lots of important information. They fail to explain a lot of concepts that a noob is probably not familiar with yet. Lastly, some of your explanations contain unnecessary filler. It sounds unprofessional, i.e. not the way a teacher would speak, so you don't sound credible. You sound like a high school kid cobbling together a project for his CS class at the last minute. When teaching, be clear and direct. Some examples of filler you use: "A pointer is basically..." and "able to hold say 3 elements".
Issues I have with your tutorials (not exhaustive):
- You don't show the output of most of your programs. The user will have no idea if what they did was correct.
- You don't need <stdlib.h> for printf stuff. Don't tell the noobs it's necessary when it's not.
- You ought to return 0; (or EXIT_SUCCESS) at the end of main. You did (correctly) declare it to return an int after all. Technically this is not required by the standard, but it helps, especially when learning, to be clear and explicit. It's a good habit to form too, returning values when you say you will, since functions other than main aren't so forgiving.
- You tell the user to change int to float or double, but you don't tell them the printf format specifiers for those types. They'll just get garbage, get frustrated, curse you and quit programming. Not only that, but float and double are completely inappropriate types for movies. Nobody owns 109.3478 movies. Pick an appropriate value to represent with floats/doubles. They ought to be learning what types are appropriate for what purposes too.
- Teach them how to manipulate variables, addition, subtraction, etc. Teach them what happens when you do 3 / 4 with integer division (a very common point of confusion for noobs). Teach them modulus. If you introduce floats and double, teach them how they differ from integers.
- Why are your arrays of numbers declared as chars? What is a char? What is it used for? You haven't even introduced a char yet, and you say nothing about it. You don't introduce character literals. Yes, a char is like a tiny int, but you don't say that. You're just confusing the noob.
- WTF is an array? What is it used for? Explain!
- Also, you're showing printing chars elements with %d. This is confusing, since they wont understand what %d is for (ints, char arrays, wtf?). It works due to type promotion, but that's not a concept that should be thrown at noobs, and it's very atypical to see chars printed with %d. An array of ints would make more sense, since you're simply assigning numbers anyway.
- Explain what makes a comment a comment. Can it span multiple lines? Explain good commenting practice.
- Explain the magic number problem. Explain why magic numbers are bad and why using named constants is good.
- Your example only covers the 0th element. It would help if you covered accessing other elements, out of bounds problems, etc.
- It seems utterly ridiculous to teach arrays without teaching loops in very close proximity.
- You don't cover what happens when you leave variables uninitialized. You must drill this point home with noobs. Uninitialized stack variables are among the most common errors I see, both on this site and in the professional world.
- You "explanation" of pointers is crude and unclear*.
- You print your pointer value with %d, which is wrong. It's wrong because an int and a pointer are not required to be the same size, thus using %d for a pointer to cause printf to output incorrect data. Not only is %p the correct format specifier, it outputs the address in hex, which is the conventional way to deal with computer addresses. Teaching noobs the typical or conventional way first is usually best, since that's what most of the literature, examples, etc they come across will use.
- You aren't clear on what the & does. Is it a requirement for assigning to a pointer, or does it give the address of the variable it's adjacent to. Since you didn't mention that pointers store addresses, or even that variables are store at addresses, this might be quite confusing.
- You aren't printing "the address of" your pointer, you're printing the address contained in your pointer. Why tell the noob it's weird? At least explain that it's arbitrary, and the actual value is largely only useful to the computer itself, and not the programmer.
- Why are we looking at "proper" uses some other time? Were these examples improper? It turns out they were, but that wasn't your intention, nor should you go telling the user "I just showed you a bunch of improper crap." How about showing them simply "other" or "further" uses. Why didn't you cover any of them now?
* What I mean by this is the following:
Links? Like a linked list (which you mention)? What is this link. You ought to mention the word address somewhere in there. But for that to make sense, you must explain to the user that programs store data at different memory addresses. Can it only link to values? What about variables, irregardless of value? What about NULL? What happens if they point somewhere they shouldn't?Quote:
A pointer is basically a value which links to another value.
That's a bit narrow, and confusing. What "other values"? Can a char * access a double value? Can an int * access a literal value? The last 5 words imply that you can't access a variable normally (i.e. through it's name) without modifying the value, which is not true. It also may be interpreted that changing the value via the pointer won't modify the original value/variable, which is not true. It would be good to show how changing the value through the pointer changes the original value too, i.e. that they are inextricably linked. I think somewhere in my "pointer tutorial", I would use the word indirect/indirectly/indirection.Quote:
They are useful when you want to access other values without modifying the original value.
Well anduril462, I think you wasted your time, but I have to say "well done" all the same.
Soma
Probably did, and thanks. Hopefully the OP takes all our advice to heart and really learns from it. There's lots of information he can use to improve his knowledge and skills before he tries to teach again. If he's so inclined to help people learn, I think that should be fostered, and I'm all for helping him. He's just got to realize it's not time for him to teach yet. Plus, it's Friday, and I'm not terribly motivated to sit at my desk and code furiously all day. My mind is fixed on that delicious home brew I have waiting for me after work.Quote:
Originally Posted by phantomotap