First, lest someone accuse me of misleading you, I am not yet technically teaching anyone. I’m shadowing the existing teacher this month, then have a month break to rework the curriculum, and will get my first official class in September.
I may not be the one up at the podium, but that doesn’t mean I’m silent in class, and it doesn’t mean that I’m not teaching. Already, I’ve learned what I think will be the most important lesson for me to remember:
Teaching the what and how of ColdFusion isn’t good enough. It isn’t even ColdFusion at that point. Teaching ColdFusion should be all about the why of things.
I’ve worked with ColdFusion for more than a decade now. With that kind of history, I’m so used to the rote of it that I’ve forgotten to remember why I’m doing it. If I just teach the CFML tags and methodologies (the what and how) then my students will graduate being able to read and write ColdFusion, but frankly they won’t be very good at it.
this CF structure/function is like this other structure/function in this other language.
This transliterational approach to teaching and learning ColdFusion is harmful.
You can code CF like you code PHP or ASP or Perl, but you’ll be missing out on everything that makes ColdFusion what it is. ColdFusion stands apart because it is application-oriented, and because it excels at rapid prototyping. That’s a serious combination that few other languages can boast. Other large platforms (JSP, ASP.NET) can boast of being application-oriented, but neither can remotely claim to be good for rapid prototyping. Similarly, the platforms meant for rapid prototyping (Ruby comes to mind) can’t also scale to large applications.
I think, come September, my first class isn’t going to get a look at CFML until the second lecture. The first will be all about the ColdFusion platform and the ColdFusion headspace—how the rules have changed, and how to think like a ColdFusion developer, not just a generic web developer.