Computer Science Teacher
Computer Science Teacher - Thoughts and Information from Alfred Thompson

January, 2007

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    The Computer Teacher is Overworked


    For the non-teachers reading let me give you some vocabulary and some background. Those of you who are teachers please correct me if you have different experiences and if you've had the same stick around to give advice in the comments.

    OK then. Teachers generally teach a number of sections (groups of students during one period of the school day) of one or more courses (different levels of a subject or different subjects) during the semester/year. Each course that one teaches is referred to as a "prep" and is something one prepares to teach. In most high schools some teachers may teach only one prep. For example, some teacher or teachers may only teach freshmen English or freshmen History. They may teach 3 to 5 sections depending on what sort of schedule the school runs (traditional or block) but they only have to prepare one lesson a day, one test for all students, etc.

    Some teachers will teach several preps (French I and French II for example) and maybe that will mean two or three different, though related, courses. Most of the time schools try to keep three preps as the maximum goal. Four preps usually means a small department with a situation everyone hopes will be temporary. The more preps one has the more overhead work they have to do. That means more lesson plans, more different tests to write, more different projects to think up and assign, and on and on. In an ideal world (in my opinion) one would only assign three or more preps to very experienced teachers who had already taught some of those courses before. That would make it the least painful.

    How many of you think that is how it works in practice? OK those of you with your hands up have never worked in K-12 education. Some times it works that way and when it does things usually go ok. But all too often the multiple preps go to the new teacher, fresh out of school because they lack the seniority to say "No!" It also happens a lot to computer teachers (and other specialties as well but I know the computer teacher bit best.) for reasons that are painfully true.

    The reasons it happens are multiple. For the most part there are few real computer teachers in a given high school. Also computer courses tend to be singletons. That means that there are only enough students signing up for the course to offer one section as semester or maybe a year. So if you have five courses a semester and one section of each course the math works out to one teacher with five preps. (And an ulcer, sleep deprivation, and a real need for summers off - really!) It's a tough gig. Oh and by the way, if you don't have five different computer courses maybe you get to teach one or two of your preps for a completely different department. Can you say "context switches are memory intensive and occasionally difficult?" I knew you could.

    But it is not just the teacher who pays a price here. The students pay a price as well. Chris Higgins recently wrote a bit about what he is going through on his blog. He's got five preps. He teaches Math as well as computer courses. He's a first year teacher. He cares deeply about doing a good job for his kids. I have the utmost respect for him. I've been there. Let's not talk about the year I worked part time in two elementary schools and had 12 preps. That didn't count because I only saw each section once a week. My time in high school was more like Higgy's for a while. I've run into a good number of teachers in similar situations though. It's not easy but he is doing all that is humanly possible to provide the best education he can. He's looking for advice from other teachers who have been there. Drop by his blog if you have suggestions for him or even if you just want to understand what he is doing and cheer him on.

    How did I cope? Each semester I did the best I could on each course but I really focused hard on one or two. I felt bad about doing the minimum (though never below where I thought that minimum was) for a couple of the courses but really worked hard at developing the best curriculum, best examples, best presentations, and best assessment tools for one or two courses. With semester courses this is easier than with year long courses because at least you know you can focus on a different one the next semester. If I had one section of a course in semester one and a second section in semester two I prioritized my time there BTW. I kept good records. I did all my work on the computer so I could reuse it again and again.

    The second semester I picked a different emphasis. I also started looking for summer opportunities to learn new material and new techniques. I was very fortunate to get to go to a week long workshop at Carnegie Mellon that not only taught me about teaching for the AP CS exam (content) but had sessions on teaching to female students to prevent them from getting turned off to computers. For someone without real teacher training (I was not an education major) that week was a life saver. In fact if you are a computer science teacher I highly recommend keeping an eye out for any high school computer science workshops at Carnegie Mellon. They are the best around. And they attract some of the best HS CS teachers in the world. Yes, I mean the world.

    The other thing I did was try to network with more computer science teachers. This is not as easy as it sounds. Remember that unlike most subjects there is often (usually) only one computer teacher in the building. So you have to find other teachers in other buildings. I found the AP Computer Science list a real help in those early years. As time went on I met teachers face to face at workshops, summer training events and conferences. I would suggest that these events are very valuable for CS teachers as both a chance to learn and a chance to network. One year I got to help grade the AP CS exam. That was like taking a graduate course in test design and grading. A wonderful experience I highly recommend - though is is not for beginners. Talking to other teachers over the years really helped me out. I continue to learn a lot from teachers I meet where ever I go. And from the HS CS teacher blogs I read.

    (As an aside - I will be at SIGCSE again this year and hope to see some of my readers there. I will also be at TCEA - come say howdy!)

    CSTA looks like it is developing into a great support organization as well. They continue to develop training events that are very helpful. We've long needed a support organization like this for high school computer science teachers and the people involved in this one are top notch. BTW several states have state-wide organizations - most are parts of the local ISTE Affiliate. ISTE has affiliates in several other countries besides the US BTW. ISTE has a special interest group for Computing Teachers called SIGCT that has meetings at NECC (yet another conference I plan to attend this year. and other resources. SO one can find others but it takes some work. Work that is not always easy to fit in with a schedule already crowded with multiple preps and a chance at a life outside of work.

    There are some dedicated teachers out there doing amazing things with limited resources. The most limited resource though is time and that is a hard one to fix.


  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Pocket PC Programming and that is just the beginning


    Brian Scarbeau is one of my favorite high school computer science teachers for two specific reasons. One is that he is always trying new things and teaching them to his students. The other is that he blogs about it. Sharing his ideas and experiences with other teachers is a huge thing.

    Right now he is getting his students excited about programming by having them program for the Pocket PC. Did I mention that this is only the second week of classes? The thing I like about using Pocket PCs is that it is unexpected. Students all expect that they will be asked to program on big clunky, and there for easier, desktop computers. Something like pocket device would appear to be more difficult. In some ways, of course, it is. But that is pretty much just when you want to do something large and complicated where memory size and CPU performance are issues. Not too many students run into programs like that in their first programming course though.

    So when students find out that they can write a real program in Visual Basic .NET for a Pocket PC they start to realize that programming is within their grasp. A little early success goes a long way. 

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Programming Proverbs


    A recent blog post by Josh Ledgard reminded me of a book that had a great influence in my early programming days. The books was Programming Proverbs by Henry Ledgard and I still have my copy. It's one of the few computer books I bought in the mid 1970's that still has some relevance.  The code examples are in ALGOL, FORTRAN and BASIC but the ideas apply to most all programming languages. Dr. Ledgard also wrote related books specifically for C, COBOL (I have that one), FORTRAN (I used to have that one but I can't find it) and PASCAL. It was quite the series.

    I've been re-reading the book since last week and I am thinking about writing a series of posts about each proverb. I'm interested in seeing some discussion about how each one holds up over time. The book is over 30 years old and there is a lot we have learned about programming in that time. Or is there? Other than Object Oriented Programming what's new? Are programs today less buggy than they were thirty years ago? Actually I think they are worse many times. Perhaps we should bring more of these proverbs to people's attention? Of course many of them are being brought up but are people really paying attention? Let's discuss it.

    What is the list you ask? Well here it is.

    1. Define the problem completely
    2. Think first, Program later
    3. Use the top-down approach
    4. Beware other approaches
    5. Construct the program in logical units
    6. Use procedures {methods}
    7. Avoid unnecessary GOTO's
    8. Avoid side effects
    9. Get the syntax correct now, not later
    10. Use good mnemonic names
    11. Use intermediate variables properly
    12. Leave loop variables alone
    13. Do not recompute constants within a loop
    14. Avoid implementation-dependent features
    15. Avoid tricks
    16. Build in debugging techniques
    17. Never assume the computer assumes anything
    18. Use comments
    19. Prettyprint - format your code so that it looks nice
    20. Provide good documentation
    21. Hand-check the program before running it
    22. Get the program correct before trying to provide good output
    23. When the program is correct, produce good output
    24. Re-read the manual
    25. Consider another language
    26. Don't be afraid to start over

    What do you think of this list? Anything you would add or drop?

Page 3 of 9 (26 items) 12345»