Tuesday, February 10, 2015

Teachers Don't Work To Rule When Working To Rule

I was talking with an educator for a school district in PA who was being accused of "not getting grades posted on <an online grade tracker> in time."

That got me thinking about what is expected of a teacher, especially since this district, like many others, has been in a continuing fight to actually get a contract negotiated but administrators and the board still demand teachers get everything graded in a timely manner (and any disputes result in consultation with existing contracts that have expired or policies that are woefully, or deliberately, vague.)

It's been pretty much shrugged off as expected standard operating procedure that teachers are expected to work beyond normal hours. But during drawn out negotiations, teachers will sometimes "work to rule," meaning they do what is in their contracts and nothing more. You want more coverage? No volunteering. You want after school activities? Better hope it's specified in the previous contract they're stuck working under. They're not supposed to be working extra hours, staying late, or sacrificing extra for their administrator overlords.

This was especially troubling given that school boards would release press releases implying the teachers are greedy and overpaid compared to the hours administrators put into their jobs for their pay.

Yeah, that's horseshit when it comes to actually getting work done, though. I decided to do some simple math to get a rough idea of whether this was horseshit or just assumed to be.

The teacher I talked to has a 7.5 hour day by contract, with 6 classes per day and a study hall to watch and a tutorial period to proctor. Between classes there are 4 minutes of designated "hall time" for students to get to classes (although usually the teachers have some responsibility in that period for watching the halls and managing students while also trying to set up for the next class.)

The lunch and prep times are self-directed times where they're paid to not directly teach students. So I added up the other times when they're expected to be "on clock," and it came to 346 minutes per day out of a workday of 450 minutes; subtracting lunch leaves 74 minutes of non-student contracted time.

Over the course of a week, that's 370 minutes of "banked time" on contract (or 6 hours 10 minutes.)

This teacher is required to give a quiz every week to each class. A 15 question quiz...an average quiz...takes half an hour to grade per class. Six classes means 3 hours of grading. That leaves 3 hours and 10 minutes "in the bank" per week.

This teacher is also required to give 3 tests within 9 weeks. So I'll take the 190 minutes "in the bank" and multiply it out by 9, giving 1710 minutes every 9 weeks of "in the bank" grading time (28 hours, 30 minutes.)

Six classes with three tests gives 18 tests within that period. "How long does it take you to grade the test?"

"About an hour per class."

Each test takes an hour. That's 18 hours, leaving 10.5 hours "in the bank" for nine weeks.

Now let us average it back to a per-week. That's 630 minutes divided by 9, giving 70 minutes per week, or one hour and ten minutes.

This means that teacher has roughly one hour and ten minutes, on average, under contract, in which to get other things done. Like, homework. If it takes half an hour to correct one class's 15 question quiz, then it's not unreasonable, using the spherical cow method of estimation, to say that a homework assignment for one class will take half an hour to correct. With one hour and ten minutes per week left to actually fit such grading in, under contract, that means that assigning homework to HALF this teacher's classes will already spill over that person's contracted working hours.

How often does this teacher assign homework?

"About two or three times a week."

Two assignments to six classes is twelve assignments per week, or 6 hours of grading, or four hours fifty minutes over the contracted time to work per week.

This was using rough estimates. But really, how far do these numbers fudge the teacher's actual workload? Would the school board and administrators prefer the hard numbers, and risk seeing how far off...in a not positive fashion...the rough estimates are?

Perhaps they would, since they're confident enough to discuss pay based on contracted hours to make teachers look like greedy descendants of Scrooge. And this is just contracted time obligated to the district, not including pay lost when they have to pay for their own classroom supplies and their own background checks  (teachers in PA, mostly fallout from a certain coach abusing players thing you might have heard about, teachers will be required to get background checks every 3 years and pay out of pocket; it's the most hilarious demonstration of the state telling administrators they're incompetent that I've ever seen since this means that an employee would be arrested, tried, and found guilty, without the employer...the school district...ever knowing about it. How else would they fail a background check while continuously employed? New employees should be required to get checked, not continually employed staff!)

Perhaps more numbers should be figured. Maybe if teachers actually calculated the worktime they're contracted to work, and stuck within that time period before going off clock with the single finger salute sailing in the breeze from an open car window as the vehicle burns out of the parking lot, there'd be more angry frowns from people who insist on holding them to every other stipulation in the negotiated contract, since it's just expected they put in whatever hours it takes to "get the work done." I don't even know why they get a "vacation" or "break", since if they don't grade work over that time administrators can hold that against them.

Any problems with the math? Corrections? Maybe you have some of your own, as a teacher, to throw in here? I'd be interested in comments on this...

Monday, February 2, 2015

Gimme the Answer! (It's What Business Wants)

Moving from the world of a student to the job-holding world can be jarring. You spend many years learning how things are supposed to work in theory, only to have those ideas demolished when you enter the working world where business, humans, and theory collide in an attempt to achieve "results."

In a way this is a natural side effect of the progression of technology. Manufacturers want their products to get cheaper and easier to use so more people, usually technology illiterate, will buy their products. Computers today are several factors faster and more reliable than computers ten or fifteen years ago. They are also priced several factors less than those computer from a decade ago.

Computers used to cost enough that when they broke down, it made sense to take them to a repair shop to replace parts and diagnose issues. Today the cost of repair can cost about as much as buying a new computer, with the added bonus of usually acquiring a faster system in the process.

As time passed, more utilities were released to help manage fleets of computers in business. Operating systems started including more helpful systems to accommodate imaging and system deployment. They're far from perfect (oh, so far, in some cases...) but they exist, and system management has significantly advanced to try to meet the needs of large businesses.

"Surely, these are good things! Companies need these features so system administrators can focus on getting work done instead of spending all their time troubleshooting user problems on their desktops!"

On one hand these features are great. They cut down on time that might have been wasted with repetitive tasks, and rolling out simple changes to a hundred desktops through automation really adds up.

The other hand, though, is the one in which exploring problems and creating solutions fosters understanding. Why is this computer failing to install this application? What do I do to find a key to delete in the registry? How can I replace a file on a system that won't finish booting?

Sometimes you can learn very interesting things through what your manager would have deemed a waste of time; I learned about visibility of various Windows timers while trying to troubleshoot an application that was supposed to schedule a reboot from the time a user had logged in (spoiler: it's not as simple as you'd think), for example. Working with Visual Basic was like a lesson in spotting people who were actually vampires hiding among normal people; I didn't realize how many applications, written by professional programmers, with a large price tag attached, were actually written in a language that is the object of so many jokes by other professional programmers.

But now there is often pressure to not explore the problem but instead just re-image the system, or reinstall the operating system. We don't take the time to try to figure out what is causing the problem or poke at internals. That's a waste of time. The efficient, responsible thing to do is just wipe it and that should probably most likely fix the problem.

In fairness it usually does.

Then a month later you find other sysadmins or support people complaining about how kids today don't have any comprehension of how things work. They don't know about registry editing, or have any intuition in tracing an application failure when the antivirus program is supposed to be talking to the clients but isn't.

It might very well have to do with the fact that they never had to, and were actually discouraged from taking the time to discovering how things work in favor of the quick re-image. It may have to do with the fact that people who did benefit from having no possible choice but recompile the Linux kernel to get a feature or device to work properly won't take the time to mentor new people for comprehension of a problem rather than just fixing a problem and moving on.

Cheaper technology, simpler solutions. Reimage it. Reinstall it. You don't understand it because you don't have to.

Eventually it's all just magic.

We'll remember the days when stuff cost so much you had to learn to troubleshoot it and keep it going rather than swapping out cheap parts from Walmart. We'll remember learning how things worked because we were forced to poke at parts until the spot where data was getting stuck could be unstuck, instead of reinstalling and hoping the corrupted entry or random file was overwritten with a working version.

And then continue bitching that people today don't understand what the hell they're doing.

Because...y'know...they don't have to.