Volume 30 Number 13
Don't Get Me Started - Refactoring Higher Education
By David Platt | December 2015
I’ve been teaching software development to students for a quarter of a century now, starting in 1991 with the 16-bit Windows SDK in C. The subject matter has evolved continuously over the years—Win32, COM, Microsoft .NET Framework, Microsoft Azure and so on. But my teaching methods, and those of my colleagues, remained mostly unchanged until the Great Recession seven years ago, when training was the first item cut from development budgets. That economic squeeze forced us to reevaluate not only our existing methods, but our entire role in the industry.
Teaching software development to programmers originally centered on transmitting specific facts in a certain order: first call this function, then call that one. RegisterWindowClass. CreateWindow. And my all-time favorite, CoMarshalInterThreadInterfaceInStream. My students were happy for a live instructor to pick those nuggets out of the 1,000-page manual, because the alternative was reading the whole thing themselves.
But because this data transfer is almost entirely one-way, technology advanced to the point that students didn’t need a live human being to impart it. Videos, such as those from Microsoft Virtual Academy or Pluralsight, could fulfill much of this function at a far lower cost. That approach scaled better than live instruction, as movies scale better than live theater.
Good, effective education still needs live instructors, but in different places doing different things. We aren’t broadcasting “what” or “how” we used to. Instead, we’re reserving our expensive contact hours for “why,” or, “how does this relate to other things,” or, “where do we go from here,” along with the ever-popular, “WTF was that?”
So I’ve changed my instruction process for live classes. It’s less about spewing a one-size-fits-all set of function calls into the void. It’s more about helping my students splice the new technology into their business logic—hmm, let’s look at your code, where should the module boundaries be and why? What sorts of tests should we have? How should we figure out who our users are and what they need? It’s an entirely different type of teaching and learning.
I have good company in making this shift. Harvard Medical School is making similar adjustments to its curriculum, starting with this year’s freshman class. Today’s future doctors aren’t subject to the “sage-on-a-stage” spouting, “Gentlemen, here are the 12 cranial nerves: Olfactory, Optic, Oculomotor … [and so on].” Instead, students memorize these basic facts from instructional videos outside of class. Professors then spend their contact time working through real-life problem analysis, such as: “A patient’s left eyebrow is up, like Mr. Spock expressing doubt, and it won’t come down. Which cranial nerve would you look at first, and why? How would you start doing that? What else would you look for, and why? Mr. Smith, you look confused. Surely you haven’t forgotten your cranial nerves, have you? Ms. Jones, please help him out.” You can read the whole story at bit.ly/1S7UR2G.
By the way, that article states that the “videos are between five and eight minutes … because students’ attention spans don’t last much longer.” Does that scare you as much as it does me? I wonder if we geeks today have longer or shorter attention spans.
I use the hands-on model in my User eXperience class. It’s not about implementing this feature or that one (a color gradient, say). It’s about deciding what ought to be implemented in order to make users happier and more productive. I rarely teach an in-house class unless the client has an actual design project to work on during the course labs. I encourage the students in my public classes to bring their own projects, and if they don’t, I assign them one.
As I wrote in my very first Don’t Get Me Started column (msdn.com/magazine/ee309884), a bad computer program demands that its users become more like a computer. But the very best programs use computers to do what computers do well, clearing the track for humans to do what only humans can.
Education needs to evolve in a similar way, and the best human instructors are starting to realize this. It’s one thing to put a specific fact into a student’s head. It’s an entirely different thing, a much more satisfying thing, to help them put that fact to work.
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.