This presentation explains the process, and some of the tough decisions you have to make, to teach PHP and Web development. First given at Northeast PHP 2013, in Boston.
articles ▪ Extension Instructor for the University of California at Berkeley ▪ Taught many live courses ▪ Maker of awesome cheesecakes 2 In case you’re not familiar with me, here are some of my bona fides. [[WALK THROUGH]] What this means is that I have plenty of experience in teaching PHP and Web development, as I’ve done that in lots of ways over the past 12 years. Also, I make a good cheesecake, but that’s less relevant today. Not only have I done PHP & Web development instruction for many years, and in many formats, but I’m actually pretty good at it, from what I’ve heard. But before this presentation, I’ve never really thought about the instruction process holistically. So let’s see what I’ve come up with. Mostly, I just wing it, with experience.
Make Tough Decisions ▪ Implement the Plan 3 I have four general topics to get you from just starting out to having completed your instruction materials to actually doing the instruction. Those are [[WALK THROUGH]]. Along the way I’ll also make plenty of recommendations and best practices for completing a smooth and successful instructional program. The most important part will be the making tough decisions. You can ask questions at any point in time, or you can grab me wherever, whenever after this session.
do is identify the constraints under which you’re working. You should note that I’m not starting with the goals. The goals are beholden to the constraints, not the other way around. I can’t, for example, teach everything there is to now about PHP in 200 pages or 2 hours. You have to identify the constraints in order to come up with appropriate goals.
are first dictated by the medium in which you’re teaching. Different mediums have different constraints. If the medium is a written format, like a book or article, you have the constraint of space. How many pages do you have? How many words do you get? I’m particularly wordy, and the space constraints of a book is the biggest hurdle I face. If it’s a live environment, your constraint is time. There’s a limit to how much time you’ll have with your students which impacts how much you can hope to cover. With live teaching, there’s also an issue of how much time you have over how long. Having 20 hours over 10 weeks means you can do more than 20 hours over 3 days. If it’s an online video, you kind of have time and space constraints. There’s only so much you can expect people to listen to.
from your students or readers or audience or whatever you want to call them. What requirements do you have of your students in advance? What assumptions are you making? What do you expect them to know already? If you’re teaching PHP, can you assume complete comfort with HTML, or do you need to allot some time and space to discuss HTML? Can you assume comfort with HTML5? Later on, when you’re tailoring your content to these constraints, you’ll need to begin slightly before where you expect the audience’s knowledge to be. This will give your students a little buffer and make sure you’re all on the same page. Also keep in mind that people doesn’t always actually know as much as they think or say they do.
time, space, and student requirements constraints, you can define the goals of the experience. Your goals should be defined by your constraints. Materials intended for beginners won’t have as lofty goals as those intended for more advanced users. The same goes for shorter material--pages, words, or hours--vs. longer material. In short, you just can’t cover as much when you have less time or space, or a less experienced audience. For example, my “PHP for the Web” books covers some stuff about HTML forms, and just gets into working with a database in over 400 pages. By comparison, my more intermediate level “PHP and MySQL” book doesn’t touch upon HTML much at all, and is knee deep in database interactions by 300 pages, with 300 more pages of content to follow. Some students will learn a lot more from it, but others will be overwhelmed and will have a hard time learning anything at all. Setting the right goals is going to make a world of difference as to how successful the teaching will be. I’m of the opinion that your more advanced students will forgive you if you start off too basic, so long as you get far enough with the good stuff. Whereas your beginning students won’t forgive you, and won’t learn anything, if you start off too advanced.
big picture ▪ Make the students/readers feel encouraged ▪ Give them the resources to continue afterwards There are three goals that I believe almost every instructional experience should include: The big picture provides the audience with context, which makes it easier for them to learn and for them to continue learning later on. You should present the big picture early and often, reinforcing it by indicating how new material fits into that picture. Encouragement is a key component of any teaching, but is especially critical in highly frustrating subjects such as programming and development. How do you encourage students? By acknowledging what’s hard and what’s confusing. The trick is to remember what frustrated you when you were learning this for the first time. Finally, you have to acknowledge that no matter how good you are, the student is going to leave not understanding some aspects of what you covered. Teach them how to fish. Show them how to use manuals and documentation, how to debug, and where to turn for help. In fact...
9 I would argue that the overriding goal of the class shouldn’t be to teach whatever subject, but to teach the students how to learn that subject. It’s a semantic but important difference. Some students will absorb most of what you teach right away. Others will have to go back after the fact to really grasp what was covered. In any case, you need to give the students what they’ll need to finish learning the subject in his or her own way.
constraints, and laid out clear goals, you can begin creating the content. You’ve got four key pieces of information at this point: - The time and space constraints - The expected starting point for your audience - The desired ending point - The additional goals that should always be there Now you just need to shovel the right amount of information into that gap, and in the right order.
Organization ▪ Examples When selecting the content, I like to start on the most macro level: the biggest topics. You want to cover maintaining state, SQL, defining functions, MySQL, creating templates, etc. These topics go into that end goal: where the student ought to theoretically be at the end of the material. Then you start organizing those big topics. This is where you start hitting your first tough decisions. Obviously SQL needs to be explained before MySQL, and those both need to be explained before you do PHP and MySQL. But where do you discuss sessions? Well, that kind of doesn’t matter. Do you discuss arrays before control structures or vice versa? I’ll return to this subject later. The organization of the material makes it easier to learn or not. But you also need to structure it into properly-sized chunks. 50 page chapters are a no-no (as a general rule), as are 2 hours of live instruction without breaks. On the other hand, just explaining dates and times ends up being a really short chapter or lesson, so where should you put that material? Next, you need to get into specifics. You’ll discuss for and while loops, but not do...while. You’ll explain running normal queries but not prepared statements. You’ll do procedural code, but not OOP. The specifics are the most concrete knowledge the student will go away with and dictates how happy they are with the experience. It’s easy to come up with general topics that everyone agrees on. And you won’t normally get in trouble for your organization, unless it’s wildly unconventional. Then you need to structure the specifics within the topics. This can also be tricky. For loops or while loops first? All of these decisions are impacted by the examples you use. Good examples make all the difference. Your examples need to be as real-world as possible. Avoid the “here’s something you could do but never will” examples. It’s a waste of time. If you organize your material well, sometimes you can build up examples over time, introducing new concepts by adding bits to existing ideas. This makes the learning easier for the students, and saves you time and space. It’s best if you can think of the examples during the outlining stage. If not, you’ll end up changing the outline during the development stage when you struggle with certain examples. For live classes, I think it’s best to use real-world examples that your students come up with. This is not easy, but it makes the material more applicable. And you can cheat a bit to implement their example within some additional constraints.
courses 12 Once I have a strong sense of the topics I plan to cover, the specifics, and my examples, I normally try to do some additional research. Even if you’re an expert on the subject, you should take some time to see how others are teaching the same material. It’s far, far better to consider and reject an idea than to never consider it in the first place. So see what others are covering that you don’t plan to and then think about whether you should. Try not to steal specific examples from other people unless you’re teaching a live course based upon a book. To me, good writing and good teaching is about making decisions. What do I cover, what don’t I cover. Get as much input as you can so that you can make the best decisions. I don’t care how good you are in the classroom, or as a writer, if you’re not making the right decisions, it’ll be a problem.
you need to select the supporting materials you’ll use. The most important of these are online resources: web sites the students can continue to refer to after the class. Here’s another tough decision: do you recommend the most authoritative resource or the most approachable? Rarely are they the same. For example, W3 Schools will come up first for lots of searches, but their content is always correct. On the other hand, php.net is the authority on PHP but not always user friendly. Try to choose the best authority. If necessary, teach your students how to use that resource. Everyone knows how to search Google, but how do you use the PHP manual? Show them. Additional support materials is most important with live teaching so that the students walk away with a physical thing. It’s a reminder that they took the course, it’s a place to take notes during the course, and it can be a reference guide when you’re no longer there. As for books, if you’re looking for a good book to use as a reference material, I have a couple of recommendations for you.
point, you’re also going to need to make decisions about the tools used by the students for the instruction. There are two categories: the students’s development tools and the server. Let’s look at the latter first. If it’s a book, you probably want the students to install an *AMP stack on their computer, you just need to recommend which one. If you’re doing a live course, downloading and installing an *AMP stack can take too much time and require too much tech support on your end. In a live environment, it’s best to have a networked server that everyone can use. This will also result in everyone having the same settings, which can make it easier. For the development tools, do you choose one common tool that everyone should use, or let students use whatever they prefer? If you’re forcing a consistent choice, do you use a text editor or an IDE? The development tools are vitally important, and your decision here can make their learning much easier or much harder. Let’s look at that issue, along with the other tough decisions...
the tough decisions you have to make while creating the content. Let’s look at some of these in more detail. Of course, being tough decisions, there are rarely clear answers, but I can explain some of the pros and cons and my thought process when I go to make these tough decisions for books and classes.
the students what they want? Okay, that’s not a tough decision. But let me give you the specific example. If you create an outline of a book or a course and there’s no chapter on security, the students will wonder why security isn’t being covered. Even though the entire course is going to stress security at the right times, if there’s no topic that says “SECURITY”, some students will think less of what you have planned. That may also mean fewer sales of books or fewer attendees of courses. My opinion is that you give them what they think they want: a dedicated chapter on security. You can’t explain in the introduction why a dedicated chapter unnecessary, because some students will have made up their mind before then. Your outline must have all the key buzzwords students will be looking for. Then you make the content fit.
things about teaching any kind of development and programming is that there’s the way things are done in the real-world, and there’s what beginners should be told. Depending upon the subject, there may be a pretty big gap there. For example, handling an uploaded file is complicated enough. Handling an uploaded file in the most secure manner as you would in the real-world is even more complicated. If you try to demonstrate the full real-world implementation from the get-go, your beginners will never get it. What I normally do is teach the fundamental concept AND let the student know if it’s an incomplete solution. I’m of the opinion that you can demonstrate suboptimal processes if you make it clear they are suboptimal. This also works well because it gives you an example you can build upon later. Frankly, it helps if you understand that there are very few perfect, ideal bits of code. Everything can be improved, or at least changed. Give them what they need to know to understand that concept being taught, but let them know if there’s more to be learned about that subject later.
like blasphemy, but there’s a delicate balance you have to walk when aiming for 100% technical accuracy. I think of O’Reilly books as being technically strong, but often rather hard to learn from, particularly for beginners. 100% technical accuracy can be an impediment to learning. On the other hand, there’s no point in teaching something that’s inaccurate. So let me give you an example: the fact is that strings as a variable type don’t exist in C. Strings are represented as an array of characters terminated with a null. But when explaining variable types, the term “string” is commonly understood by students. So do you only use the phrase “array of null-terminated characters” or is it okay to use “string”? I would argue that when you’re playing a little loose with the technical accuracy, you tip your hand to it: you say “string”, but a couple of times you add a parenthetical saying that it’s not actually a string and you’ll learn more later. Strike a balance between flawless, but confusing, accuracy and accessibility.
in that it can be used both procedurally and using object-oriented syntax. So which do you teach? Realistically, you probably can’t teach both. It may take 200 pages or a full day to teach OOP in PHP. Considering your time and space constraints, what aren’t you going to cover because you’re covering both procedural and OOP? What I normally do is this: I think of PHP as an approachable language, so I normally start with procedural code for beginners and intermediate level students. I reserve full coverage of OOP to advanced instruction. There is a middle ground here, however: you can demonstrate using OOP pretty easily and in a small amount of space and time. It’s the OOP theory that takes a lot of effort.
creating the content is how you order your material. In part because this impacts the examples you can do. For example, loops are often used with arrays. If you cover arrays before loops, you can discuss all the array stuff but not the arrays AND loops stuff, saving that for the loops material. If you cover loops before arrays, you need to come up with examples that demonstrate loops WITHOUT using arrays. In these situations, you have to find the lesser of two evils, and sometimes fake the examples a bit: make them less real-world than you’d prefer.
to how much you can teach. In order to fit the most in, you need to avoid redundancies. A lot of programming and web development is doing the same thing over and over again. If you can create processes that limit redundancies, you’ll save space and time, which in turn will let you cover more. And you’ll teach valuable development lessons in the process. [[EXAMPLE WITH TEMPLATES]]
content, and made tough decisions: now it’s time to implement the plan. Whether this is actually writing the book or actually teaching the class, here’s what you do and don’t do.
teaching a class, revisit your outline before you begin the actual writing or teaching. Try to mentally walk through what you’ll say and do for as much of the outline as you can. The specific examples you’ll use will help you see whether you’re on the right track or not. Make sure you’re presenting a sense of the big picture early and often.
specifically the development tools. I mentioned this earlier. If you have a specific tool that you think is great, that makes learning easier, you could require that. But it’s a delicate balance. For beginners, if you spend the time to introduce an IDE, that takes extra effort, but it could make programming easier, faster, and more bug-free. On the other hand, seeing and fixing bugs is extremely valuable. If you have a class of students, especially at a company, you can often insist on using one tool. This gives the class more cohesion and makes them better prepared to do their job. If it’s a book, or a video, where time is less important but space matters, avoid focusing too much on the tools. Regardless of the environment, the one thing you can’t do is ask established programmers to change tools. Big no-no. For the server tools, choose wisely there, too, and make sure that everyone will be able to get going immediately.
▪ Make it practical ▪ Re-enforce what they’ve already learned ▪ Acknowledge that it’s hard ▪ Breaks Your students are not going to learn well when they’re frustrated, and being frustrated is a huge part of being a programmer. While you’re teaching, do things to help manage the students’s emotions. There are five things that really help in this regard. [[WALK THROUGH]]
hardest things to do but is one of the absolutely most important skills. Unfortunately, the only way to really learn how to debug is by doing. This is where a live class excels, particularly if you’re using on-the-fly examples. When you do live examples, no matter how good you are, you’ll make mistakes and create errors. Doing so serves two really useful purposes. First, it shows the students that you’re human, that you make mistakes, too. Second, it shows the students how a pro approaches debugging. When I first started doing live teaching with live examples, I made plenty of mistakes, by accident. It turns out that was a pretty good idea.
into a great outline, created top-notch content with smart examples, and then you go to teach the class and not all goes to plan. Some students don’t know as much as you thought. There are some technical difficulties. You needed to get to point X by the end of the day, and now you’re behind schedule. Roll with the punches. Change it up. Realize that forcing all that content that you had planned into that situation means the students will learn even less. It’s okay to cut back. In fact, it’s best to adapt to your students.
sure that you give your students a sense of what’s next. What specific topics they should look into next. How they should expand their skills. What resources they should turn to. What examples they could try. A couple of years ago I started adding “Review and Pursue” sections to the ends of my chapters. The review was to hammer points home. The pursue was to get the readers to try out certain things. It turned out to be really beneficial. The pursue prompts gave the readers a sense of what they should be capable of doing. It also allowed me to suggest other examples, or improvements on existing ones. More than anything, it gave the readers a sense of what’s next: where they are, and where they’re going.
29 As I said earlier, despite all the types of teaching I’ve done, I’ve never formally thought about the process. No doubt I’ve internalized a lot, but it’s been a fun experiment to actively think about it, to identify what matters. When all is said and done, I think it comes down to this: teaching PHP and Web development, regardless of the format, shouldn’t be thought of as a whole thing, as a complete solution. Be it a class or a book or a video, you’re not taking your students on a journey, you’re helping the students begin their journey.
larryullman
qsona
oztick139
hamadakoji
yu4u
macloud
osyoyu
doradora09
tetsuyaooooo
lycorptech_jp
kaz29
itkq
lmi
scottboms
geeforr
bcantrill
pedronauck
kneath
robhawkes
chrisshort
brettharned
marcduiker
tmm1
holman
thoeni
