Jump to content
  • Advertisement
  • entries
  • comments
  • views

An Argument Against Tutorials

Sign in to follow this  


It seems like every time someone requests help, they are looking for a tutorial on the subject. Are tutorials really the solution to their problems? Do they really learn what they need to know through tutorials? Are tutorials appropriate for beginners?

Often enough you will find yourself in a situation where you need to use something that you've never encountered before. More often than not, when someone requests my help with such situations, they are looking for a tutorial on the subject. The problem with tutorials is that they are incomplete. They do not cover the material to a sufficient extend to be considered a replacement for documentation. Tutorials also have a relatively short TTD (Time to Death), as APIs usually change faster than the tutorials can. This makes tutorials a relatively poor choice when you need to garner experience in an unfamiliar situation.

Tutorials are usually a hodgepodge collection of partially correct information, deceptive simplifications, and relaxed correctness. The idea of a tutorial is to quickly demonstrate a concept such that the concerned parties can use the information. However, due to the generally terse and incomplete information presented, one who uses such a tutorial cannot effectively utilize the information without turning to other resources first. A good example is that of the standard containers. Most tutorials will not tell you about the performance constraints placed upon the various containers; hence you do not know when it would be best to apply each. When should you apply a list vs. a vector? If all your tutorial has shown is how to interact with the interface (about 90% of the ones I've seen), then you won't know when it would be appropriate to use a list vs. a vector. A further problem crops up when you start looking at APIs like OpenGL. The majority of OpenGL tutorials will start by teaching you the glVertex* functions, and their friends. This is fundamentally flawed as those functions are NOT what you should use. You should be using the glPointer* functions, and should be taught those first. People who learn the glVertex* functions tend to take longer in adopting the glPointer* functions, and often find other APIs like Direct3D (which has no immediate mode functions) hard to learn, even though it is an extremely simple API.

The people who most commonly are looking for tutorials aren't professionals. They aren't people with experience. They are the beginners, those looking for a quick and easy solution. Since the tutorials appear to be the fastest way to get from point A to point B. However, they do not learn the theory behind what they are doing, hence they cannot appropriately apply what they "learn" from the tutorial to different problems that can be solved the same way. This industry isn't one of innovation, but one of adaptation. When you learn from a tutorial you cannot adapt to new situations, because the tutorial cannot adequately prepare you for those situations. A common example of this is a tutorial demonstrating a matrix class. How often have I seen a simple matrix shown, with all the usual operations, but none of the theory behind the mathematics involved. Oh yes, you'll see a brief mention that matrix multiplication is not commutative (This is technically false. A true statement would be: "Matrix multiplication is not commutative in the general case.") Even when they do include the mathematics, is usually on the most basic of concepts. This doesn't help the person who ends up needing to calculate the determinant of a matrix.

This is not to say that there aren't good tutorials out there, but by the very nature of a tutorial, it is extremely limited in its focus. As such a tutorial cannot teach one who does not have experience. The only thing that will be produced from a union is a copy-and-paste coder, which we already see all too often on these forums. A tutorial in the right hands can point someone with the appropriate experience in the correct direction towards solving their problem. Furthermore, someone with the appropriate experience will have the ability to take the solutions laid forth in the tutorial and turn them into solutions for new problems.
Sign in to follow this  


Recommended Comments

Interesting timing.

As I've been journaling about recently, I'm working on learning C# and Managed DirectX. I haven't touched rasterization technology in years, and it's come a long way. C# has a totally different design philosophy than both C++ and the KC scripting language I use at work. Altogether this makes for a lot of me-not-knowing-things.

One thing that's annoyed me a lot during the experience is the "tutorial" craze. Frankly most of the tutorials out there only make sense to me because I've been doing Windows and 3D-theory for years, and so I already know the concepts. Where I'm fuzzy, though, is on stuff like high-level overviews of how the rendering pipeline operates in current-gen video hardware. Tutorials don't cover it, and reference documentation like MSDN suffers from a common problem of not knowing how to find a concept.

I'm dealing with things right now that I don't know how to name or describe, which means that the typical methods of searching (keywords and navigating a hierarchy) just don't work. The tutorials have no useful detail, and the references don't make the information easily accessible to an uninitiate.

I think really this comes down to a problem of knowledge organization and presentation; if I had a person sitting here I could easily use natural language to describe the sorts of questions I have. But I have Google and MSDN search instead, and they frankly suck at understanding natural-language questions. If you don't know the magic keywords, you can't find what you want.

I've thought about this problem before, once or twice at great length, but so far all I've really concluded is that it is a very hard problem. I'm not even certain that a solution exists, although intuitively it feels like there should be one. What annoys me is that we see all manner of research going into more terse methods of describing things (tagging, etc.) to fit the keyword craze, and more effective models for building hierarchies - where both models suck for educating people. There doesn't seem to be any widely discussed investigation into other ways of providing such information.

Share this comment

Link to comment
I've been hating on tutorials for years for these exact reasons. I've never written one, never started writing one, and - gasp! - never used one. Never will.

RTFM is not an insult. It is a compassionate and accurate piece of advice. Understanding the system, or the concept, is critical to successfully using it, and the only way to truly understand is to read the documentation. And read all of it.

Bravo, Washu.

Share this comment

Link to comment
I agree as well.

It can be a lot quicker to work with tutorials when you just want to get something done. Yes, in the long run it'd be better to read something more comprehensive but if X wants to meet their deadline this evening they'll happily go with "monkey see, monkey do" and copy-n-paste from a tutorial that does something close to what they want.


Share this comment

Link to comment
Guest Anonymous Poster


Tutorials should only be used to jumpstart on a topic. After that one should dive into the manuals. Reading tons of pages on the topic before one could write any code could be very hard to some.

Manuals give full importance to every tidbit and that becomes information overload if you are new to a system as you do not know which parts are relavant. It probably comes down to how different people think and store information. Take gl extensions specification for example, for someone reading an extension spec for the first time its very hard to digest it and extract the useful info out of it quickly. You need a tutorial so you can use the API, and you don't need a spec as that also convers things for OpenGL implementation. But once you get the things working then you can read the whole spec and understand the finer details. Probably some can gobble the interface and the operations its abstracts at once in parallel, wheras others might prefer to learn the interface first and the rest later.

Teachers face similar problems too, *cough* feynman *cough*, how should he approach a subject? Different students have different ways of thinking and there is no way to grab all of their attention and satisfy them all.

The solution to this atleast in case of tutorials and the net is simple. You provide multiple sections of the tutorial, one for usage of the interface and focusing on what can be done with it, and one for explaining why such an interface is needed and what operations are abstracted by the interface. Maybe if the guy is clever enough he can interlace the two using some "web magic" and
produce a third version for the people who can take both at once.

While I agree with the fact that most of the tutorials suck, its because the manuals/specs suck at providing a simple overview and instead dig down to the system right away. Or the simple usage examples are buried deep inside the manuals/documentation.

But who has the time and patience to write such multi-way documentation anyway?

Share this comment

Link to comment

This is not to say that there aren’t good tutorials out there, but by the very nature of a tutorial, it is extremely limited in its focus. As such a tutorial cannot teach one who does not have experience.

I see your point about the copy/paste coder, but I don't agree with the general statement quoted above. I myself started opengl by coding along with the nehe tutorials and I find it hard to believe that no one here has ever relied on a tutorial during their gamedev experience. Lets face it, game development is a daunting task, and it's hard for beginners to even have a clue where to start. Tutorials can support hands on learning if used properly, especially for those with little to no experience. Sometimes, a beginner truely needs to get the big picture of how to solve a problem one way in order to get a feel (and some hands on experience) with the concept at hand.

I guess the point i'm trying to make is that there are different types of learners out there, so there is no right or wrong way for people to learn how to program.

Share this comment

Link to comment
So what's the alternative? It's not as though Documentation is much better in many cases, being incomplete or using terminology without defining it.

Share this comment

Link to comment
Right on Washu! I "learned" C++ from a tutorial. Then I picked up a book on the subject, and found out how little I knew (I was still using char*'s for crying out loud!). I "learned" DirectX from a tutorial. Then I picked up the DX documentation, and again was shown that tutorials are not the end-all be-all of learning. I try to direct beginner's away from tutorials and towards books and documentation, but it appears this is something you must learn from experience.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!