As you might know, one of the most popular posts ever on this blog was on an unlikely topic—silicone bakeware. Indeed, six years later it continues to get new comments every couple months, and for most of that time it's been on the front page of Google hits for "silicone cookware" and related queries. Amazing.
Anyway, I have an update on yet another way in which silicone bakeware sucks. I'm cleaning out my kitchen, and way in the back of a cupboard I found the red silicone bundt pan that had been the proximate motivation for my prior negative review. I'm not sure why I didn't throw it out then (well, I am—I resist throwing out anything that might possibly be useful later) but I figured I'd toss it in a bag of stuff I'm bringing to the Salvation Army tomorrow.
Only... it was sticky. Really sticky. All over the entire thing. It wasn't I-missed-a-spot sticky, like a food remnant I hadn't quite washed off well enough. And it wasn't top-of-the-fridge sticky, where airborne stovetop grease has embarrassingly accumulated but can be wiped off with a bit of warm soapy water. This was existentially sticky, and no scrubbing could get it off. It was flypaper sticky, transferring the sticky to my hands and remaining even after washing them (with more soap and water). In point of fact, it was really gross.
I've certainly never had that problem with glass and metal bakeware.
"If I were not an atheist, I would believe in a God who would choose to save people on the basis of the totality of their lives and not the pattern of their words. I think he would prefer an honest and righteous atheist to a TV preacher whose every word is God, God, God, and whose every deed is foul, foul, foul." --Isaac Asimov
(Adapted from a response to the HN thread "What happened to all the female developers?")
A frustratingly small number of people are aware of the 1984(ish) peak in females in the field. My mom taught computer programming (Fortran) in a Chicago high school from 1967 until 1984, and was actually kind of surprised when I first asked her about gender balance issues in the field—they just weren't an issue then, and her classes were always more or less balanced. But what they also were was everyone's very first exposure to a computer. Without exception, her students had never written any sort of program before, and they were recruited from good students in the math and physics classes, coming to programming with an open mind and no preconceptions. (A lot of them, girls and boys both, went into technical computer-related fields.)
The change, as has been noted elsewhere, surely has to do with the introduction of computers, but my hypothesis is that it wasn't just home PCs (not in the 80s) but classroom PCs that were the problem: in a lot of places, computers in the classroom were a fad and showed up with no training of the teachers, so they sat in the back or the side, mostly unused... unless one or two of the students pestered the teacher to play with the computer, and then used the manual and/or trial and error to figure it out. Guess which students were doing that more?
But that, I think, wouldn't be enough. The knowledge should equalise after one or maybe two terms of college CS, right? But I'm pretty sure the real problem was that professors inadvertently reinforced and magnified the difference between students who'd had previous computer experience (primarily boys) and students who hadn't (of both genders). It turns out that as a teacher, it's very, very easy to look around the classroom, see that X% of the students seem to be getting something, and decide to move on. (You can't wait for 100%, usually, so it's always a judgement call.) That's fine if it's something you've taught well and only the weak students are struggling, but what if it's something you absentmindedly glossed over? Half the class understands it, so you must have covered it, right? This is very insidious, and even being aware of it is not always enough to combat it; and if the divide of "has experience" vs "no experience" partially reflects a gender divide, that divide will only get reinforced.
"A popular implementation technique of hash tables is, rather than doubling (or halving) in size during resize, to just add or remove some constant number of buckets. And then still claim its O(1) cost for insert et al. It's a hash table, after all. At times like this, I understand why the zen masters tended to simply hit their students upside the head with a stick when they said something stupid." --Brian Hurt