An issue I've noticed is that, with technology in particular, students are taught the wrong way to do things before they are taught the right way. Then they are expected to do things "the right way" and never do it the wrong way again.

That, unfortunately, is not how things work. If you practice like you play, you'll play like you practice.

First, a little background. I have recently been taking some Coursera courses on responsive web development. The courses uses Meteor and MongoDB, with some introductory work in basic HTML/CSS and Bootstrap.

In both the Coursera lectures and the Meteor tutorials, there is a tendency to do things *"quick and dirty"*, to get the student to "jump into the pool". Make JavaScript variables global, stick all your CSS in the same file, put your Meteor client and server code in the same directory, etc.

By the end of the lesson, you've made something that "works", but you haven't learned good practices, workflows, etc. that would allow you to create. It wasn't until the end of the third of five Coursera courses that we talked about how to organize and "clean up" the messy code we'd been working on. Oh, and forget about documentation! No tutorial would bother covering that!

I certainly don't think that lessons should be bogged down in minutiae, but if good practices are not learned early, bad habits will form that will be extremely difficult to break later.

On the flip side, good habits are also hard to break. Ever met a developer who drags his feet at writing documentation? Now imagine if he'd been forced to write (good) documentation for all of his CS course projects. I'd bet that he'd still be writing documentation at work out of sheer inertia.

Does it really matter that much? Documentation, by definition, does not change program behavior, right? Well, not at any given instant in time, but it strongly shapes the way that software evolves. This video on literate programming by Timothy Daly explains it well.

Even if that still does not convince you, consider another topic that is rarely covered in early tutorials: security.

Why is so much software insecure? It's not just that security is hard; it's that people don't think about it–are not taught to think about it–until they've already formed non-secure habits.

New Meteor apps include two insecure packages, autopublish and insecure, by default. They're intended for "rapid prototyping", but I'll bet my last dollar there are Meteor apps out there with sensitive information exposed because the developer didn't know to, or simply forgot to, remove these packages! My StackOverflow post criticizing this behavior was not well-received.

I'll end with a quote:

We are what we repeatedly do. Excellence, then, is not an act, but a habit.

Given that we constantly learn and practice doing things the wrong way, is it any wonder that we do it the wrong way when it really matters that we don't?