Please start with Part 1, below.
Now that I've made my own default views somewhat clear, I can talk about what radical honesty is, and the implications. Ed's words to me were that he defines the central imperative of radical honesty as, "Be as open as humanly possible, and then minimize harm." (That's a loose paraphrase, not a direct quote. Feel free to correct me in the comments, Ed.)
I would break it down into two imperatives: never lie, and always share relevant information. To me, it's akin to a monastic discipline like abstinence or silence. I had a lover with whom I practiced radical honesty, a long time ago, and it was a real challenge, and led to a lot of insights, but it was very difficult and made our relationship pretty dramatic at times. I think it's a good thing to try at least once, assuming you have a partner willing to try it with you.
There are two related things that I'm really enjoying about Ed, and one is directly this matter of honesty. Sometimes he says exactly the wrong thing, and other times he says something so great you can't believe you're hearing it; you believe him in the latter cases because of the former. And because he (compulsively? by choice?) brings up problems almost immediately (which I know partly from tracking his relationship with Mel on their blogs, and hearing about it from him), you really can know that "no news is good news" - it's really not likely that he's saving up things to gripe about later. And if you ask him a question, you'll get a (sometimes painfully) true answer. All of this has a way of being comforting even while it is challenging.
I'm experiencing this as a relief from Mosch's more strategic approach to honesty, but, as I have told both of them, I could just as easily experience Mosch's tact and care as a relief from Ed's bluntness.
I know from the past that I am capable of radical honesty when I choose, so I am trying this with Ed as well. I had an opportunity recently to reassure him in a way that was so cost-free and so ultimately meaningless, and yet so potentially painful to withhold, that only an idiot or a total jackass would have withheld it, and yet I did so because answering the question that way was not quite truthful. And when I told him later that I would have answered differently for anyone else, he thanked me sincerely for the honesty. The guy knows what he wants, and so far he can take it as well as dish it out.
His wanting it doesn't make it the best strategy for me. Probably my best strategy given his preferences would be to do enough to give the appearance of radical honesty, while still being strategic the rest of the time. But I am willing to risk harm to my interests - and to his - in order to actually give him what he wants in this way.
Or at least to try.
Wednesday, June 06, 2007
Radical Honesty, Part 1
This is something that Ed believes in, and Sally asked in the comments if I would explain it, because it sounded to her like something that is not a very good idea. I suspect what it sounds to her like it means is exactly what it does mean, but it's a fairly fertile topic.
I think most people's approach to honesty is fairly unexamined, and mostly consists in claiming to be honest, and then telling the truth or lying according to what seems like a good idea at the time. Most people are honest enough, but people who claim not to lie at all are, IMO, either self-delusional or untrustworthy. Everyone lies sometimes, as well they should.
My general view of communication is a strategic one. I really want to be understood, and to understand others, so I'm a big proponent of openness where it's possible (i.e., not always with one's parents) and appropriate (i.e., usually not at work). Honesty greatly aids in openness, in addition to its other benefits (it's easier, it lets people trust you, and it's more ethical in its own right).
But in general, I think it's important to maintain your sense of ownership of the privacy of your own mind. If you see openness as an obligation, you may (my sense is) start lying to yourself just so that you won't have to tell difficult truths to others. I really have no qualms at all about people lying about things that are not the asker's business anyway. And I have very few qualms about another class of lying - where the purpose is not to deceive, but to withhold information that would be counterproductive (to mutual goals) to share.
At the same time, my desire to understand other people makes me behave in certain ways that encourage honesty. I resolved early in life not to be possessive, for the simple reason that it makes people lie to you. This is also behind a lot of my acceptance of others. Where it isn't safe to tell the truth, almost everyone is prudent enough to lie. I try not to make people lie to me. (I often refrain from asking questions that would likely tempt someone to lie, for instance.)
I should continue this in another post.
I think most people's approach to honesty is fairly unexamined, and mostly consists in claiming to be honest, and then telling the truth or lying according to what seems like a good idea at the time. Most people are honest enough, but people who claim not to lie at all are, IMO, either self-delusional or untrustworthy. Everyone lies sometimes, as well they should.
My general view of communication is a strategic one. I really want to be understood, and to understand others, so I'm a big proponent of openness where it's possible (i.e., not always with one's parents) and appropriate (i.e., usually not at work). Honesty greatly aids in openness, in addition to its other benefits (it's easier, it lets people trust you, and it's more ethical in its own right).
But in general, I think it's important to maintain your sense of ownership of the privacy of your own mind. If you see openness as an obligation, you may (my sense is) start lying to yourself just so that you won't have to tell difficult truths to others. I really have no qualms at all about people lying about things that are not the asker's business anyway. And I have very few qualms about another class of lying - where the purpose is not to deceive, but to withhold information that would be counterproductive (to mutual goals) to share.
At the same time, my desire to understand other people makes me behave in certain ways that encourage honesty. I resolved early in life not to be possessive, for the simple reason that it makes people lie to you. This is also behind a lot of my acceptance of others. Where it isn't safe to tell the truth, almost everyone is prudent enough to lie. I try not to make people lie to me. (I often refrain from asking questions that would likely tempt someone to lie, for instance.)
I should continue this in another post.
Kayak Lesson
Last night from 8:00 to 10:30 PM, I took a kayaking lesson, the first in a series that I could take. The company that offers these (Confluence Kayaks) does them on lakes and (for the more advanced classes) in rivers, but you can also take them in the pool at the University of Denver, and that's where I was.
The first thing they taught us was the "wet exit," which is how you get out of an overturned kayak if you need to. When you get into a kayak, you are wearing something they call a "skirt," which is made of wetsuit material, and fits around your torso, with a flaring part (like a skirt) with a rubber lip at the bottom. You use it to create a seal between yourself and the opening in the kayak.
Wet exits seem scary because they really wedge you into a kayak (so you can control it with your body) and you wonder if you'll actually be able to get out. We were taught to execute the wet exit using these steps.
The first thing they taught us was the "wet exit," which is how you get out of an overturned kayak if you need to. When you get into a kayak, you are wearing something they call a "skirt," which is made of wetsuit material, and fits around your torso, with a flaring part (like a skirt) with a rubber lip at the bottom. You use it to create a seal between yourself and the opening in the kayak.Wet exits seem scary because they really wedge you into a kayak (so you can control it with your body) and you wonder if you'll actually be able to get out. We were taught to execute the wet exit using these steps.
- Lean forward until your face is against the skirt. In a real situation, you'd be wearing a helmet, so this is to protect your face from rocks or other things in the water.
- Bang three times on the sides of your kayak. This is to let people know you're trapped upside down.
- Rub the sides of your kayak with your fists. (This is useless for a wet exit, but practice for the bow rescue.)
- Reach to the front of your skirt, where you hopefully left the tab at the front facing out, and pull the skirt right off the boat.
- Put your hands on the kayak near your hips, push it off like pants, and do a forward somersault out.
If you're not intrinsically afraid of being trapped underwater, which I'm not, this doesn't sound so scary until the first time you try to do it. (It's not difficult, but it is a bit panic-inducing.) There were 7 students in our class, and we each practiced one at a time (taking turns) until we were comfortable. Everyone went twice, and one woman went three times. I wasn't completely sure I was comfortable after doing it twice, but I didn't feel like doing it again.
Next we learned a few basic kayaking strokes, with time to practice them. As with paddling a canoe, you want to paddle by rotating your torso rather than by pulling the paddle with your arms. (I feel like this is even more possible and necessary in a kayak, but I'm a beginner at both.) Our teacher seemed legitimately impressed by how fast we learned all of the strokes.
I tipped over by mistake while doing the forward stroke, so I got to practice another wet exit, this time under slightly more realistic conditions (i.e., while surprised).
The next thing we learned was the "bow rescue" or "eskimo rescue" - a way to get righted in your upside-down kayak without having to do a wet exit. We practiced this in stages and, frankly, I was fearful of each stage (I was very very tired by this point, especially because of my accidental wet exit and the ensuing exercise of getting the kayak out of the water, getting myself back in, etc.)
But the basic way this rescue works is that, after you flip over, you signal for help by banging three times (as above), and then you wait patiently while rubbing your fists or arms along the sides of your kayak. The reason for the rubbing (so mysterious earlier) is so that you can feel the other kayak when it comes to you.
Your rescuer approaches you at a right angle, and when you feel the bow of their boat, you put your hands on top of it (he showed us how, if you accidentally wrap your arms around it instead, your head will be under their bow, which is unworkable) and pull your head out. He had us rest our head right on their bow.
Your kayak itself is still upside-down at this point (though dry inside because of the skirt), and even though you feel like you want to just pull yourself up, that's not possible with an upside-down boat on top of you. You have to use your hips to flip your boat back upright, which is actually pretty easy. (In other words, you want to push your boat beneath you, not try to push yourself up over the boat.) It's hard to remember that this is what you want to do, but fortunately your head is out of the water, so you know you have until your arms give out to think about it, so it's not too hard not to panic.
We practiced this in five distinct stages, so we really eased into it. By the final stage, my partner would be off across the pool and I'd flip over, bang, wait (trying not to worry, because of course I could do a wet exit if I got desperate), and then when she hit my boat with hers (never on the side I expected, because flipping over is so disorienting), frantically dig my head out, think/struggle, then flip over. Whew, upright again.
The lesson was exhausting, but great fun. The feeling of being in a kayak is somewhat magical - the way your hips can rock the boat side to side so easily (and you don't capsize as long as you keep your body separate and over the boat - exactly opposite to how you do a bike). And all that time upside-down in the water was pretty special too. I felt the sensations of it all as I was falling asleep.
In the second class, they teach you how to roll.
Next we learned a few basic kayaking strokes, with time to practice them. As with paddling a canoe, you want to paddle by rotating your torso rather than by pulling the paddle with your arms. (I feel like this is even more possible and necessary in a kayak, but I'm a beginner at both.) Our teacher seemed legitimately impressed by how fast we learned all of the strokes.
I tipped over by mistake while doing the forward stroke, so I got to practice another wet exit, this time under slightly more realistic conditions (i.e., while surprised).
The next thing we learned was the "bow rescue" or "eskimo rescue" - a way to get righted in your upside-down kayak without having to do a wet exit. We practiced this in stages and, frankly, I was fearful of each stage (I was very very tired by this point, especially because of my accidental wet exit and the ensuing exercise of getting the kayak out of the water, getting myself back in, etc.)
But the basic way this rescue works is that, after you flip over, you signal for help by banging three times (as above), and then you wait patiently while rubbing your fists or arms along the sides of your kayak. The reason for the rubbing (so mysterious earlier) is so that you can feel the other kayak when it comes to you.
Your rescuer approaches you at a right angle, and when you feel the bow of their boat, you put your hands on top of it (he showed us how, if you accidentally wrap your arms around it instead, your head will be under their bow, which is unworkable) and pull your head out. He had us rest our head right on their bow.
Your kayak itself is still upside-down at this point (though dry inside because of the skirt), and even though you feel like you want to just pull yourself up, that's not possible with an upside-down boat on top of you. You have to use your hips to flip your boat back upright, which is actually pretty easy. (In other words, you want to push your boat beneath you, not try to push yourself up over the boat.) It's hard to remember that this is what you want to do, but fortunately your head is out of the water, so you know you have until your arms give out to think about it, so it's not too hard not to panic.
We practiced this in five distinct stages, so we really eased into it. By the final stage, my partner would be off across the pool and I'd flip over, bang, wait (trying not to worry, because of course I could do a wet exit if I got desperate), and then when she hit my boat with hers (never on the side I expected, because flipping over is so disorienting), frantically dig my head out, think/struggle, then flip over. Whew, upright again.
The lesson was exhausting, but great fun. The feeling of being in a kayak is somewhat magical - the way your hips can rock the boat side to side so easily (and you don't capsize as long as you keep your body separate and over the boat - exactly opposite to how you do a bike). And all that time upside-down in the water was pretty special too. I felt the sensations of it all as I was falling asleep.
In the second class, they teach you how to roll.
Tuesday, June 05, 2007
Misheard Lyrics
For all the Pearl Jam fans and haters among my readership, this is too perfect not to post.
(Found via Andrew Sullivan.)
(Found via Andrew Sullivan.)
Deal-Breakers, Non-Negotiables, etc.
Recently, Ed and I have been talking about things that are critical to have in a partner. (A couple of his are "radical honesty" and "sympathetic interpretation.") Neither of us keeps an explicit list, but for me, the things that come to mind are more like deal breakers - the things I can't tolerate in a partner.
Just as a mental exercise, I'll list a few of each kind. These lists are definitely not meant to be exhaustive.
Deal-Breakers
- Substance abuse. I can handle moderate drinking, but nothing approaching alcoholism. I could handle occasional pot-smoking, but I'd rather not. Anything beyond that is right out.
- Possessiveness. It's hard to know what to write about this, exactly, and obviously "possessiveness" is a matter of degree. I'm not very possessive myself, and the path that leads from "Where were you? I thought you got off work at 5:30, but I called you at 6:15 and you weren't home" to cutting you off from your friends to beating you up is a scary thing, and even lesser forms of possessiveness or controllingness are not too cool with me.
- Excessive woo. By "woo" I mean new-agey or pseudoscientific things like crystals, tarot, chakras, etc. I can only handle so much of this before my head starts to want to explode. (See also "reality-based thinking" below.)
- Intentional hurtfulness. Some people, in a fight, will say the most hurtful things they can think of. I would have a conversation with someone about this before breaking up over it. But only one.
Non-Negotiables
- Feminism-compatibility. He doesn't have to call himself a feminist (though it would be nice), but I need his basic ideas and attitudes to be compatible with feminism.
- Reality-based thinking. I need for most of my partner's ideas to be based on empirical attempts to understand how the world works. I don't need my partner to be as empirical as, say, Sally, but a basic respect for and practice of empiricism is something I can't live without.
- Social liberalism. On the economic front, I can handle a fairly broad range of ideas - anything from "almost libertarian" to "Swedish-style socialist." But if you've got a problem with homosexuality or the legality of abortion, it's not going to work out.
Those are the ones that come to mind right now, anyway.
Friday, June 01, 2007
Thursday, May 31, 2007
Boyfriendly
Well, for the first time in a pretty damn long while, I have a boyfriend, pictured at left.His name is Ed, he's 23, and he's a computer science grad student at the School of Mines.
What? 23?!?
I wish I could say he's extra mature for his age or something, but he seems just kinda regular for his age. (Sorry Ed!)
So what is he like? Pretty much a bit geekier than I am, a certifiable math genius, shy (he claims, though I have seen no evidence of this), argumentative (naturally), and kind of a smartass. In other words, basically what you'd expect.
How did we meet? Funny you should ask. The actual origins of our mutual acquaintance shall remain shrouded in mystery, but the official, CIA-approved answer is "We met at a party."
Life is good :-)
Friday, May 04, 2007
Hiding Assumption Lists & Parnas Partitioning
I'm posting about this both because I think it is interesting and because "hiding assumption lists" is a really poor name, such that I can never remember what it refers to. I don't think you have to know anything about programming to get the gist of this post.
When designing software, one idea that everyone basically subscribes to is making the software "modular." That means instead of having one giant clump of code, you have many smaller clumps. Ideally, each clump kind of does one thing, and doesn't contain too much code. The smallest level of clumps can clump together to form larger modules.
This modularity can mean a lot of specific things in terms of how code is organized, because it takes place on a number of levels and partly depends on what type of programming language you're using, but the more important general question is, how do you decide what things to lump together (or, alternately, what things to separate out)?
A general design principle is that you want to have high cohesion and low coupling. "High cohesion" means that each module handles one thing and not several things. "Low coupling" means that the modules are not interweaved together.
For instance, if we compare the modules of a program to a group of people making dinner, it would be like this. Cohesion (which is good) would be something like one person making the salad, one person making the stir-fry, and another person making the bread. You might get even higher cohesion if you had one person doing all of the vegetable prep (cutting things up), one person running the stove, and another person managing the oven: this way each person's taks would be quite specific. Coupling (which is bad) means, how much do the people have to interact? It's OK if the vegetable prep person interacts once with each person - taking orders for vegetables and filling the orders. But it would be annoying if two people were working on different aspects of the same dish at the same time, so that they constantly had to interact with each other, passing information and ingredients back and forth. What you want is for each person to have a single, coherent task (high cohesion) and also for each person to interact with the others a minimum amount (low coupling).
But "hiding assumption lists" give you a different way to think about design. What you do here is think about what might need to be changed about your program later. Might it be ported to a different type of machine? Might the type of database it uses change? Might the user interface be improved? Your ideas about what changes might occur are the "hiding assumptions" (you assume such-and-such might need to change).
You then divide up your modules (this is the "Parnas Partitioning") such that the changes you assume might be needed will be as easy as possible. For instance, if you think that the form of output might change (maybe right now your program puts information on the monitor, but you think later it might just print everything out to a printer), you might respond by making sure all of your output functions are grouped together, rather than interleaved into all of the other code. That way you'd only have to go to one place to make those changes.
Going back to our dinner-makers, let's guess that we might want to change what type of salad is made. If we originally had the salad-making functions divided up between the veggie-prep person and the salad-maker, it could be annoying to have to tell them both that we now want a caesar salad. (This isn't so bad with humans, because they program themselves, but with code you have to write out - and thus later modify - exact instructions.)
We might have originally had a "make salad" function in both our veggie-prep person (it could say "chop up a head of iceberg lettuce, three tomatoes, and an avocado") and our salad-chef ("when veggie-prep gets you the vegetables, put the lettuce on the bottom, tomatoes and avocado layered on top like so"), and then we'd have to change both in order to change the type of salad. It would make more sense to have the veggie-prep person simply take orders ("5 cups of chopped romaine") and deliver the prepared veggies. That way we'd only have to change our instructions to the salad maker ("order romaine from veggie-prep", etc.), and the salad maker would just give a different order. We'd never have to worry about the veggie-prep person at all in making the change.
The design change I described also results in lower coupling, but the idea is that by thinking in terms of future changes, it's easier to see where the problems are in the design and which ones are most important to fix.
When we first learned about this, I realized that I think about my own code this way all the time. I've hardly done any design ever - I tend to design by coding, which works fine for tiny projects but very poorly for larger ones - but I do think about how easy it will be to change certain things without messing everything else up. I'm always pleased when a formal technique turns out to correspond to something I instinctively do, though it would make more sense to be pleased at the opposite - a new technique that gives a perspective I never thought about.
(Yes I realize the way I talked about people making dinner together is kind of an idiotic way to think about people - "you want a minimum of interaction", etc. - but I only meant it as a highly imperfect metaphor. I am really not like the Borg or anything. "Number 8, slice 2 carrots.")
When designing software, one idea that everyone basically subscribes to is making the software "modular." That means instead of having one giant clump of code, you have many smaller clumps. Ideally, each clump kind of does one thing, and doesn't contain too much code. The smallest level of clumps can clump together to form larger modules.
This modularity can mean a lot of specific things in terms of how code is organized, because it takes place on a number of levels and partly depends on what type of programming language you're using, but the more important general question is, how do you decide what things to lump together (or, alternately, what things to separate out)?
A general design principle is that you want to have high cohesion and low coupling. "High cohesion" means that each module handles one thing and not several things. "Low coupling" means that the modules are not interweaved together.
For instance, if we compare the modules of a program to a group of people making dinner, it would be like this. Cohesion (which is good) would be something like one person making the salad, one person making the stir-fry, and another person making the bread. You might get even higher cohesion if you had one person doing all of the vegetable prep (cutting things up), one person running the stove, and another person managing the oven: this way each person's taks would be quite specific. Coupling (which is bad) means, how much do the people have to interact? It's OK if the vegetable prep person interacts once with each person - taking orders for vegetables and filling the orders. But it would be annoying if two people were working on different aspects of the same dish at the same time, so that they constantly had to interact with each other, passing information and ingredients back and forth. What you want is for each person to have a single, coherent task (high cohesion) and also for each person to interact with the others a minimum amount (low coupling).
But "hiding assumption lists" give you a different way to think about design. What you do here is think about what might need to be changed about your program later. Might it be ported to a different type of machine? Might the type of database it uses change? Might the user interface be improved? Your ideas about what changes might occur are the "hiding assumptions" (you assume such-and-such might need to change).
You then divide up your modules (this is the "Parnas Partitioning") such that the changes you assume might be needed will be as easy as possible. For instance, if you think that the form of output might change (maybe right now your program puts information on the monitor, but you think later it might just print everything out to a printer), you might respond by making sure all of your output functions are grouped together, rather than interleaved into all of the other code. That way you'd only have to go to one place to make those changes.
Going back to our dinner-makers, let's guess that we might want to change what type of salad is made. If we originally had the salad-making functions divided up between the veggie-prep person and the salad-maker, it could be annoying to have to tell them both that we now want a caesar salad. (This isn't so bad with humans, because they program themselves, but with code you have to write out - and thus later modify - exact instructions.)
We might have originally had a "make salad" function in both our veggie-prep person (it could say "chop up a head of iceberg lettuce, three tomatoes, and an avocado") and our salad-chef ("when veggie-prep gets you the vegetables, put the lettuce on the bottom, tomatoes and avocado layered on top like so"), and then we'd have to change both in order to change the type of salad. It would make more sense to have the veggie-prep person simply take orders ("5 cups of chopped romaine") and deliver the prepared veggies. That way we'd only have to change our instructions to the salad maker ("order romaine from veggie-prep", etc.), and the salad maker would just give a different order. We'd never have to worry about the veggie-prep person at all in making the change.
The design change I described also results in lower coupling, but the idea is that by thinking in terms of future changes, it's easier to see where the problems are in the design and which ones are most important to fix.
When we first learned about this, I realized that I think about my own code this way all the time. I've hardly done any design ever - I tend to design by coding, which works fine for tiny projects but very poorly for larger ones - but I do think about how easy it will be to change certain things without messing everything else up. I'm always pleased when a formal technique turns out to correspond to something I instinctively do, though it would make more sense to be pleased at the opposite - a new technique that gives a perspective I never thought about.
(Yes I realize the way I talked about people making dinner together is kind of an idiotic way to think about people - "you want a minimum of interaction", etc. - but I only meant it as a highly imperfect metaphor. I am really not like the Borg or anything. "Number 8, slice 2 carrots.")
Wednesday, May 02, 2007
End of Semester Nearing
Yep, it's another boring post about (mostly) school.
This is the last week of classes; next week is Finals. I'll have a final next Tuesday in Software Engineering Principles (swep), and tomorrow I'll get our take-home final for Geometry, which will be due the following Thursday.
I have a pretty decent A average in Geometry so far. According to my calculations, if Dr. T is calculating grades the way he says he is, I need an 80 on the final in order to have an A. Even on the super-hard test that took me a whole week of stress (story here), I got a 97, so that should be easily doable. But I have to admit, I'm hoping it's more like our recent exam, which was pretty easy.
Geometry was an interesting class in the beginning, but as we near the end I've gotten really fatigued with it. Every class is just going through theorems and proofs, and it's just a long slog - the parts of the material that are interesting are spaced too far apart by the parts that are both difficult and boring at the same time. But I only have one more lecture to sit through, so I'll survive.
I anticipated that Geometry would be pretty easy, and it sure hasn't felt that way, though in the end it looks like I'll have a high A, so it must not have been too hard. I did put in some real effort, at least early on. I also hoped this course would make me smarter (not by teaching me geometry, but by working my brain) and it has definitely done that. As a side benefit, it caused me to buy and learn to use Mathematica, which is a huge good thing.
I went into Software Engineering Principles with some dread. I liked the professor, but a friend who's taken him for the next course in this sequence told me it was a ton of work, and basically, my underlying feeling was that I did not actually want to get involved with the "yucky" parts of software engineering - the planning, project management, design diagrams, etc. (as opposed to the "fun" part, the coding). In fact, on the first day of class, Dr. P asked us to state our primary concern about the class, and that was mine ("I think I hate this material").
Well, either I was wrong or I've become a convert, because I've actually loved the material of this class. We started with five students (six if you count the guy who only showed up one time) and are ending up with four, so it's been like a seminar, but it isn't just the format that's been fun - the material has absolutely rocked.
Am I coming out of this feeling equipped to run a software project? Hell, no. But I feel like I have a good idea of what is required to do it, how it might be done fairly well or poorly, and basically what the desired characteristics are. I could certainly run a software project now better than I could before taking the class (though it would likely still be a failure).
And, of course, we've had this fun project. I'm still working on that, and plan to keep working through at least this weekend.
So, speaking of that class, I currently have a low A average. I suspect I'll get an A almost regardless of what I do, since nobody else currently has above a D average, and I've done extremely well on everything other than the midterm, but it would help to get at least a high B on the final exam next Tuesday. I don't have any plans about making that happen, but I've actually been reading the material the second half of the course, so I should be OK.
I'm a bit sad about swep coming to an end - it really has been a lot of fun - but it's satisfying to complete a course, and in general I'm really looking forward to having a relaxed and empty head for at least a few weeks. (I have two easy online courses this summer.)
In those few weeks, Sally is visiting me for a whole week! That's very cool also, especially to consider that she'll be visiting during my relaxed, between-semesters period.
Life is good.
This is the last week of classes; next week is Finals. I'll have a final next Tuesday in Software Engineering Principles (swep), and tomorrow I'll get our take-home final for Geometry, which will be due the following Thursday.
I have a pretty decent A average in Geometry so far. According to my calculations, if Dr. T is calculating grades the way he says he is, I need an 80 on the final in order to have an A. Even on the super-hard test that took me a whole week of stress (story here), I got a 97, so that should be easily doable. But I have to admit, I'm hoping it's more like our recent exam, which was pretty easy.
Geometry was an interesting class in the beginning, but as we near the end I've gotten really fatigued with it. Every class is just going through theorems and proofs, and it's just a long slog - the parts of the material that are interesting are spaced too far apart by the parts that are both difficult and boring at the same time. But I only have one more lecture to sit through, so I'll survive.
I anticipated that Geometry would be pretty easy, and it sure hasn't felt that way, though in the end it looks like I'll have a high A, so it must not have been too hard. I did put in some real effort, at least early on. I also hoped this course would make me smarter (not by teaching me geometry, but by working my brain) and it has definitely done that. As a side benefit, it caused me to buy and learn to use Mathematica, which is a huge good thing.
I went into Software Engineering Principles with some dread. I liked the professor, but a friend who's taken him for the next course in this sequence told me it was a ton of work, and basically, my underlying feeling was that I did not actually want to get involved with the "yucky" parts of software engineering - the planning, project management, design diagrams, etc. (as opposed to the "fun" part, the coding). In fact, on the first day of class, Dr. P asked us to state our primary concern about the class, and that was mine ("I think I hate this material").
Well, either I was wrong or I've become a convert, because I've actually loved the material of this class. We started with five students (six if you count the guy who only showed up one time) and are ending up with four, so it's been like a seminar, but it isn't just the format that's been fun - the material has absolutely rocked.
Am I coming out of this feeling equipped to run a software project? Hell, no. But I feel like I have a good idea of what is required to do it, how it might be done fairly well or poorly, and basically what the desired characteristics are. I could certainly run a software project now better than I could before taking the class (though it would likely still be a failure).
And, of course, we've had this fun project. I'm still working on that, and plan to keep working through at least this weekend.
So, speaking of that class, I currently have a low A average. I suspect I'll get an A almost regardless of what I do, since nobody else currently has above a D average, and I've done extremely well on everything other than the midterm, but it would help to get at least a high B on the final exam next Tuesday. I don't have any plans about making that happen, but I've actually been reading the material the second half of the course, so I should be OK.
I'm a bit sad about swep coming to an end - it really has been a lot of fun - but it's satisfying to complete a course, and in general I'm really looking forward to having a relaxed and empty head for at least a few weeks. (I have two easy online courses this summer.)
In those few weeks, Sally is visiting me for a whole week! That's very cool also, especially to consider that she'll be visiting during my relaxed, between-semesters period.
Life is good.
Monday, April 30, 2007
Review for the Quiz
Via Sally, in case you've been goofing off, and not reading my blog with the proper level of detail, here is a tag cloud via TagCrowd of the last ~40 days of my blog postings:
Guess I've been a bit focused on school lately, eh?
algebra anything asked best better bugs class course date design doing done dr either enough estimate ever feeling finish given going group guess homework hours idea likely lot math mathematica paper pretty probably problem project really risk software someone something stuff sure taking test totally useful usually week weekend whole
created at TagCrowd.com
Guess I've been a bit focused on school lately, eh?
Thursday, April 26, 2007
Group Work
The Software Engineering Principles course I'm currently taking is meant to prepare us for Software Engineering Practices, the "Senior Experience" course for CS majors (and for my made-up degree). The Practices course involves working on a big group project for the entire semester, doing all phases of the software development cycle (requirements, design, coding, testing, etc.). So to help us prepare for that, we've been doing a small group project in our current class.
It hasn't been very good. Our class only had five students, and one dropped out fairly early in the project after having an argument with me (a very civil argument over a mild question; I'm not sure why he got as angry as he appeared to, and I'm not at all sure this is why he dropped out).
Of the four we have left, there is me (smart, moderately diligent), W (smart, moderately diligent, extremely busy and with almost no time to put into school right now), H (smart, a total fuck-off), and B (learning-disabled, may have skills that have not yet been revealed, has not done any work to date). And Dr. P has been contributing to the project himself.
Nevertheless, it's been my best group project for school ever. When we talk about design issues in class, and really hammer them out, it's incredibly fun and feels really productive. I never thought working on a team could be like this. (I can only imagine what it would be like if I had teammates who ever did any work.)
Our project itself currently resides in a file repository managed by cvs. Basically cvs manages it so that multiple people can work on various files, sort of checking them out and then back in with changes. It stores all of the previous version of files, so if you need to revert to one that you didn't yet screw up, you can. When people make changes, they upload their changed files with a comment about what they did.
It's fun checking the repository every day for new stuff, and reading the history logs (the comments people made when they checked things in) on the rare occasions that someone has done something. (Actually, Dr. P does something fairly often, and I usually do some work a couple of times a week, but otherwise, almost nothing ever happens.)
Here are a few things I have learned about doing this kind of group work using a repository.
Donut offenses - Don't break stuff that other people need to do their work. In some workplaces, doing so is known is a "donut offense" and you owe one donut to each person whose work you interrupted.
Submit early - You shouldn't wait until you get your stuff (whatever you're working on) completely finished to put it on the repository. Just because you created a file doesn't mean it's "yours" - it's better to go ahead and upload it when you're at a stopping point so other people can work on it in the meantime. Relinquish ownership.
Group decisions - Design issues need to be ratified by the group. It's fine to go implement stuff on your own, or make mock-ups or prototypes of anything you think might be interesting, but you can't change the project design without consulting with your teammates. For instance, we have a database schema that has been fairly well hammered out in a lot of group discussions. I've written all of the code for the schema, but I can't just go adding stuff without discussing the design with the group.
No ego - A lot of the above relies on not having a lot of ego-attachment to your work. One way you can be productive, as I mentioned, is to make mock-ups or prototypes of things you think might be neat. But this only works if you understand that your prototype is probably not going to become the product, and your mock-ups may be totally trashed (gently) by your teammates. You have to do everything from the perspective of trying to be useful to the collective effort, rather than with the idea that your stuff is the best and will naturally be adopted. Or you have to at least fake it pretty well.
Avoid parallel play - Some people in our group always just do their own stuff without seeming to even check the repository or message boards first. Sometimes what they do has already been done by someone else, or someone else has made remarks that might influence the decisions you make. So even though it's OK to do some stuff totally on your own and then submit it to the group, it's good if you keep in the loop about what's going on in the project as a whole rather than just totally doing your own thing. ("Parallel play" is what they call it when tiny children, who aren't old enough for social interactions, play together. They basically just play alongside each other.)
Groups aren't useless - A few times now, we've had a design task (mostly around the database our product is based around), and I've spent time in advance thinking about it a lot, and have been pretty sure I had it nailed down. One time I wrote up a whole document with two approaches to something, and arguments about why one approach was superior. In that case, trying to explain it to the group, and discussing why one design or the other might be better, yielded a third design that was better than either of my original two. In every case, group discussion has resulted in better designs than anyone had come up with on their own. (A note about design: it's best IME to do design on your own and then hash it out in a group. You can't really design things "on the fly" - you get much better ideas if you think about it for a couple of days by yourself. So I'm talking about refining the design or choosing between alternatives.) This kind of goes against our common sense that groups just muddle things up and accomplish nothing.
Be a self-starter - Sometimes people in the group don't do anything because they feel like nobody told them what they were supposed to do. When you're working in a group of peers, you can't expect someone to tell you what to do. You know what's going on with the project - see what's needed and go do some of it. If you can't think of any defined tasks you can do, go do something you think might be helpful (remember: no ego attachment!) even if you're not sure it's "wanted."
It's sad that this crummy group has been my best group work experience ever, but the parts that have gone well (and even badly) have been real eye-openers.
It hasn't been very good. Our class only had five students, and one dropped out fairly early in the project after having an argument with me (a very civil argument over a mild question; I'm not sure why he got as angry as he appeared to, and I'm not at all sure this is why he dropped out).
Of the four we have left, there is me (smart, moderately diligent), W (smart, moderately diligent, extremely busy and with almost no time to put into school right now), H (smart, a total fuck-off), and B (learning-disabled, may have skills that have not yet been revealed, has not done any work to date). And Dr. P has been contributing to the project himself.
Nevertheless, it's been my best group project for school ever. When we talk about design issues in class, and really hammer them out, it's incredibly fun and feels really productive. I never thought working on a team could be like this. (I can only imagine what it would be like if I had teammates who ever did any work.)
Our project itself currently resides in a file repository managed by cvs. Basically cvs manages it so that multiple people can work on various files, sort of checking them out and then back in with changes. It stores all of the previous version of files, so if you need to revert to one that you didn't yet screw up, you can. When people make changes, they upload their changed files with a comment about what they did.
It's fun checking the repository every day for new stuff, and reading the history logs (the comments people made when they checked things in) on the rare occasions that someone has done something. (Actually, Dr. P does something fairly often, and I usually do some work a couple of times a week, but otherwise, almost nothing ever happens.)
Here are a few things I have learned about doing this kind of group work using a repository.
Donut offenses - Don't break stuff that other people need to do their work. In some workplaces, doing so is known is a "donut offense" and you owe one donut to each person whose work you interrupted.
Submit early - You shouldn't wait until you get your stuff (whatever you're working on) completely finished to put it on the repository. Just because you created a file doesn't mean it's "yours" - it's better to go ahead and upload it when you're at a stopping point so other people can work on it in the meantime. Relinquish ownership.
Group decisions - Design issues need to be ratified by the group. It's fine to go implement stuff on your own, or make mock-ups or prototypes of anything you think might be interesting, but you can't change the project design without consulting with your teammates. For instance, we have a database schema that has been fairly well hammered out in a lot of group discussions. I've written all of the code for the schema, but I can't just go adding stuff without discussing the design with the group.
No ego - A lot of the above relies on not having a lot of ego-attachment to your work. One way you can be productive, as I mentioned, is to make mock-ups or prototypes of things you think might be neat. But this only works if you understand that your prototype is probably not going to become the product, and your mock-ups may be totally trashed (gently) by your teammates. You have to do everything from the perspective of trying to be useful to the collective effort, rather than with the idea that your stuff is the best and will naturally be adopted. Or you have to at least fake it pretty well.
Avoid parallel play - Some people in our group always just do their own stuff without seeming to even check the repository or message boards first. Sometimes what they do has already been done by someone else, or someone else has made remarks that might influence the decisions you make. So even though it's OK to do some stuff totally on your own and then submit it to the group, it's good if you keep in the loop about what's going on in the project as a whole rather than just totally doing your own thing. ("Parallel play" is what they call it when tiny children, who aren't old enough for social interactions, play together. They basically just play alongside each other.)
Groups aren't useless - A few times now, we've had a design task (mostly around the database our product is based around), and I've spent time in advance thinking about it a lot, and have been pretty sure I had it nailed down. One time I wrote up a whole document with two approaches to something, and arguments about why one approach was superior. In that case, trying to explain it to the group, and discussing why one design or the other might be better, yielded a third design that was better than either of my original two. In every case, group discussion has resulted in better designs than anyone had come up with on their own. (A note about design: it's best IME to do design on your own and then hash it out in a group. You can't really design things "on the fly" - you get much better ideas if you think about it for a couple of days by yourself. So I'm talking about refining the design or choosing between alternatives.) This kind of goes against our common sense that groups just muddle things up and accomplish nothing.
Be a self-starter - Sometimes people in the group don't do anything because they feel like nobody told them what they were supposed to do. When you're working in a group of peers, you can't expect someone to tell you what to do. You know what's going on with the project - see what's needed and go do some of it. If you can't think of any defined tasks you can do, go do something you think might be helpful (remember: no ego attachment!) even if you're not sure it's "wanted."
It's sad that this crummy group has been my best group work experience ever, but the parts that have gone well (and even badly) have been real eye-openers.
Thursday, April 19, 2007
The Nano-Date
In our software engineering class, we've been reading Waltzing with Bears (by DeMarco and Lister), a book about risk management. It's geared towards software development, but a lot of the ideas would be the same no matter what kind of project you're running.
The basic idea about risk management is that the odds of nothing "unexpected" occurring to delay your (non-trivial) project are very small, and by not acknowledging that, you are lying to yourself and other stakeholders and unjustifiably relying on luck to let you finish within the time and budget you've allotted.
When most people are given a project to accomplish, and asked how long it will take, they either guess (this is bad) or estimate (this is better) using an assumption that nothing will go wrong. In the software industry, there are tools like COCOMO for estimating how long a project should take. In your own life of doing projects, you probably have a sense of how long things should take you under normal circumstances. This is the date most people report as their answer.
DeMarco and Lister call this "the nano-date" because, given that it's basically the earliest date you might finish, so that the odds of finishing before that date are nil, the odds of finishing on that date are very very small. According to their research, the distribution of completion dates looks like this:
I wasn't able to label the vertical axis, but it represents the probability of finishing on a particular date. The area under the curve adds up to 100% - you're certain to finish overall, but the exact date is uncertain. N is the nano-date, and from the graph you can see why the odds of finishing on that date are so small. The right skew (the way it's higher on the left side and then slopes more gently on the right) is because projects that finish before their "most likely date" (the top of the hump) are likely to finish only a little before, while late projects can drag out forever.
According to their research, the range of very likely completion dates goes from about 250% to 300% of N. That is to say, if your "best case" says your project will take 10 months, it will probably in reality take 25 to 30 months.
That sounds terrible! But if you turn it around, it means that, given a realistic estimate of when your project will probably be done, it might be done in as little as 1/2 - 1/3 of that time. Your project could be way early if you do a good job estimating the probable effects of things that might go wrong and use that estimate to pad your original distribution curve properly. And if you apply proper risk management, you can also avoid, mitigate, or contain your risks, but that's for another post.
Meanwhile, here are the top five risks DeMarco and Lister have identified for software projects, in order from worst to uh...best? (They studied how much harm these factors usually do to a project, and this is based on that average damage.)
schedule flaw: the original estimate of the schedule (from whence N and the rest of the unrisked distribution should derive) was totally bankrupt to begin with, and not because other things went wrong later, but because it was just an incompetent estimate of how long a project should take in your organization.
requirements creep: the client (internal or external) keeps adding new things they want the product to do. The U.S. Department of Defense did a study in which they estimated that the size of a software project grows by about 1% per month.
turnover: important people leave your organization & this messes up your schedule
specification breakdown: negotiations with your client totally break down, and the whole project is cancelled. DeMarco and Lister have found this happens to about 1 in 7 projects. Obviously this isn't an incremental risk like the others - it's just a flat risk. Once you get past a certain point - where everything important has been absolutely nailed down and signed by all parties - this risk disappears.
underperformance: the people working on your project don't work as effectively as they reasonably would be expected to. This risk actually breaks even - sometimes you get overperformance instead (as you'd expect, given the nature of estimation).
The two takeaway ideas I have from this so far are...
1. Don't give the nano-date as your estimate of when a project will finish, no matter what the size of the project is. Recognize that there is a distribution of when you might finish, and use a more likely point in that distribution as your commit date. (A useful heuristic: given your estimate, is there a good chance you'll finish early? If not, your estimate is a lie.)
2. You can get a list of risks (perhaps from problems encountered on previous projects) and use estimation of their average effects to pad your estimates.
Soon I'll try to post about strategies for dealing with the risks themselves.
The basic idea about risk management is that the odds of nothing "unexpected" occurring to delay your (non-trivial) project are very small, and by not acknowledging that, you are lying to yourself and other stakeholders and unjustifiably relying on luck to let you finish within the time and budget you've allotted.
When most people are given a project to accomplish, and asked how long it will take, they either guess (this is bad) or estimate (this is better) using an assumption that nothing will go wrong. In the software industry, there are tools like COCOMO for estimating how long a project should take. In your own life of doing projects, you probably have a sense of how long things should take you under normal circumstances. This is the date most people report as their answer.
DeMarco and Lister call this "the nano-date" because, given that it's basically the earliest date you might finish, so that the odds of finishing before that date are nil, the odds of finishing on that date are very very small. According to their research, the distribution of completion dates looks like this:
I wasn't able to label the vertical axis, but it represents the probability of finishing on a particular date. The area under the curve adds up to 100% - you're certain to finish overall, but the exact date is uncertain. N is the nano-date, and from the graph you can see why the odds of finishing on that date are so small. The right skew (the way it's higher on the left side and then slopes more gently on the right) is because projects that finish before their "most likely date" (the top of the hump) are likely to finish only a little before, while late projects can drag out forever.
According to their research, the range of very likely completion dates goes from about 250% to 300% of N. That is to say, if your "best case" says your project will take 10 months, it will probably in reality take 25 to 30 months.
That sounds terrible! But if you turn it around, it means that, given a realistic estimate of when your project will probably be done, it might be done in as little as 1/2 - 1/3 of that time. Your project could be way early if you do a good job estimating the probable effects of things that might go wrong and use that estimate to pad your original distribution curve properly. And if you apply proper risk management, you can also avoid, mitigate, or contain your risks, but that's for another post.
Meanwhile, here are the top five risks DeMarco and Lister have identified for software projects, in order from worst to uh...best? (They studied how much harm these factors usually do to a project, and this is based on that average damage.)
schedule flaw: the original estimate of the schedule (from whence N and the rest of the unrisked distribution should derive) was totally bankrupt to begin with, and not because other things went wrong later, but because it was just an incompetent estimate of how long a project should take in your organization.
requirements creep: the client (internal or external) keeps adding new things they want the product to do. The U.S. Department of Defense did a study in which they estimated that the size of a software project grows by about 1% per month.
turnover: important people leave your organization & this messes up your schedule
specification breakdown: negotiations with your client totally break down, and the whole project is cancelled. DeMarco and Lister have found this happens to about 1 in 7 projects. Obviously this isn't an incremental risk like the others - it's just a flat risk. Once you get past a certain point - where everything important has been absolutely nailed down and signed by all parties - this risk disappears.
underperformance: the people working on your project don't work as effectively as they reasonably would be expected to. This risk actually breaks even - sometimes you get overperformance instead (as you'd expect, given the nature of estimation).
The two takeaway ideas I have from this so far are...
1. Don't give the nano-date as your estimate of when a project will finish, no matter what the size of the project is. Recognize that there is a distribution of when you might finish, and use a more likely point in that distribution as your commit date. (A useful heuristic: given your estimate, is there a good chance you'll finish early? If not, your estimate is a lie.)
2. You can get a list of risks (perhaps from problems encountered on previous projects) and use estimation of their average effects to pad your estimates.
Soon I'll try to post about strategies for dealing with the risks themselves.
Wednesday, April 04, 2007
Good Teacher, Bad Teacher
Sometimes they are the same teacher.
Last week we got an assignment in Geometry that has been taking everyone hours and hours. First of all, some of the algebra is taking an extremely long time. The first problem out of seven took me about 5 pages of (not very densely written) algebra to get through, though I left the vast majority of it off of my homework paper because I know he doesn't care that we show that we can do a bunch of dumb algebra. And second of all, the concepts behind the homework are a bit challenging and require thought.
The way Dr. T gives homework is that it never includes solving problems of a type we have been shown in class or anything like that - it's always an extension or a related sidebar. This is appropriate but makes the homework and tests (which are the same way) pretty challenging.
Anyway, when he asked for questions at the beginning of class, I asked if the homework due date could be pushed back because it was taking a really long time for me and, I imagined, for others people too. Instead of hanging me out to dry, the class agreed. So he agreed to move the due date to Tuesday. Good teacher!
Then he told us we shouldn't be doing all this algebra by hand, but should be using Mathematica. I was already planning to do this, but a lot of the class was astonished to find out that it would be OK and not cheating. My take on it (having known for a few weeks that it was OK) is that using Mathematica to do algebra in this class is like using a calculator for arithmetic in a Calculus class - kind of a no-brainer. (It's assumed that we know algebra.)
You could, of course, program Mathematica to solve the whole problem, rather than just using it for fill-in algebra, but you'd be demonstrating total mastery of the problem in so doing, so it ought to be fine.
Anyway, then it came up that most of us don't know how to use Mathematica. So he actually spent about 10 minutes showing us how (writing the commands on the board). That was neat since I had just taught myself the same stuff earlier in the day.
This led to more questions about the homework, and I got into a little argument with Dr. T over a point I had misunderstood, and some other folks argued over different things, and he eventually said, "The concepts in this course are not difficult. If you think they are, you might be barking up the wrong tree."
Well, fuck you too. (Bad teacher!)
There are times when it's appropriate to suggest that having unusual difficulty with the material of a course might suggest an ill-chosen field of study, but this wasn't one of them. For one thing, every student in this class besides me is a secondary math education major. You need to know a lot of math to pass the tests to get certified, and of course you should know a lot of math to teach high school math, but (a) none of the material for this course is needed for teaching, and (b) you don't need to be a math genius for it either.
And for another thing, even a person good enough to potentially pursue a Math PhD will probably occasionally have conceptual difficulty with a math topic, and it's impossible for someone very familiar with the math to judge how hard it is. I'm not a math genius, but I'm not unfit for advanced study either, and I find this material pretty challenging at times.
Anyway, I got Mathematica in the mail yesterday (joy!) and I've decided to do my entire homework in it - write-up, graphs, drawings, and all. I've been working on that all day (I took the day off work) and it's going to take me hours and hours but be incredibly fun and result in a beautiful paper to turn in. What could be better?
My wall now sports a banner-shaped poster that proclaims "MATHEMATICA SPOKEN HERE" and I hope that will soon be true.
Last week we got an assignment in Geometry that has been taking everyone hours and hours. First of all, some of the algebra is taking an extremely long time. The first problem out of seven took me about 5 pages of (not very densely written) algebra to get through, though I left the vast majority of it off of my homework paper because I know he doesn't care that we show that we can do a bunch of dumb algebra. And second of all, the concepts behind the homework are a bit challenging and require thought.
The way Dr. T gives homework is that it never includes solving problems of a type we have been shown in class or anything like that - it's always an extension or a related sidebar. This is appropriate but makes the homework and tests (which are the same way) pretty challenging.
Anyway, when he asked for questions at the beginning of class, I asked if the homework due date could be pushed back because it was taking a really long time for me and, I imagined, for others people too. Instead of hanging me out to dry, the class agreed. So he agreed to move the due date to Tuesday. Good teacher!
Then he told us we shouldn't be doing all this algebra by hand, but should be using Mathematica. I was already planning to do this, but a lot of the class was astonished to find out that it would be OK and not cheating. My take on it (having known for a few weeks that it was OK) is that using Mathematica to do algebra in this class is like using a calculator for arithmetic in a Calculus class - kind of a no-brainer. (It's assumed that we know algebra.)
You could, of course, program Mathematica to solve the whole problem, rather than just using it for fill-in algebra, but you'd be demonstrating total mastery of the problem in so doing, so it ought to be fine.
Anyway, then it came up that most of us don't know how to use Mathematica. So he actually spent about 10 minutes showing us how (writing the commands on the board). That was neat since I had just taught myself the same stuff earlier in the day.
This led to more questions about the homework, and I got into a little argument with Dr. T over a point I had misunderstood, and some other folks argued over different things, and he eventually said, "The concepts in this course are not difficult. If you think they are, you might be barking up the wrong tree."
Well, fuck you too. (Bad teacher!)
There are times when it's appropriate to suggest that having unusual difficulty with the material of a course might suggest an ill-chosen field of study, but this wasn't one of them. For one thing, every student in this class besides me is a secondary math education major. You need to know a lot of math to pass the tests to get certified, and of course you should know a lot of math to teach high school math, but (a) none of the material for this course is needed for teaching, and (b) you don't need to be a math genius for it either.
And for another thing, even a person good enough to potentially pursue a Math PhD will probably occasionally have conceptual difficulty with a math topic, and it's impossible for someone very familiar with the math to judge how hard it is. I'm not a math genius, but I'm not unfit for advanced study either, and I find this material pretty challenging at times.
Anyway, I got Mathematica in the mail yesterday (joy!) and I've decided to do my entire homework in it - write-up, graphs, drawings, and all. I've been working on that all day (I took the day off work) and it's going to take me hours and hours but be incredibly fun and result in a beautiful paper to turn in. What could be better?
My wall now sports a banner-shaped poster that proclaims "MATHEMATICA SPOKEN HERE" and I hope that will soon be true.
Friday, March 30, 2007
Strange Energy
This morning on my drive to work, I felt a kind of weird energy, like a slight charge of anticipation and excitement. It's the kind of feeling you might have after a promising first date. I'm not sure what it's about, but let's speculate.
"Wet bus stop, it's raining, his car is warm and dry"
I got a ride downtown from my professor last night after class, since it was snowing. (It's been very warm lately and then blam! spring snow!) It wasn't that exciting, but I couldn't pass up the opportunity to quote Sting.
Project
My software engineering principles class is working on a project, and it hasn't been going that well for a couple of weeks, but last night we really sat down to design our database schema. I love designing databases, so it was right up my alley. But what was more salient was another thing, which is that the one other smart, diligent person in my class (out of the five of us), Warren, was the main one arguing with me about all of the decisions. (Only three of us even showed up - me, Warren, and a guy who isn't too bright.) So Warren, Dr. Paul, and I spent basically two hours hammering out a lot of this database design, and it was wonderful how it worked, the way that Warren and I were able to argue cogently with each other and bring up all kinds of possible situations in which one design or the other might be superior. It's rare that I've had this kind of experience in any group, much less a school project. I've respected Warren for a while, so this was just like a little capper.
Weekend Plans
Near the end of that class, we each committed to "deliverables" for Tuesday. I volunteered to write the code (PHP) to create the database that we hammered out. (Our design of it is not completely finished, but we did complete a lot of the schema.) This is a big deliverable (to judge by the reactions to my suggestion that I would do it), and it should take me a while, but it feels very doable - I know how to do it, and it's just a matter of actually doing it.
Meanwhile, in my Geometry class, we got another problem set. It's due next Thursday, and I'll probably need to spend a fair number of hours on it. Like the exam, the problem sets usually take a lot of both working time and non-working time where my brain can just mull on the difficult problems, so I need to work on this early and often. (If you're curious, you can see the problem set here.)
Meanwhile, our grant project will be winding to a close soon (there are about six weeks left in the semester), and we haven't accomplished much this semester, though overall we've accomplished what seems (from the outside) like a fair amount. Dr. Paul, who is also the advisor for that, wants us to write a small paper for a conference he thinks we can get into, and we need an abstract for that paper next week. So the idea at this point is to figure out what the paper should say (we actually do have enough material/ideas to write a small paper), write the abstract, and then figure out, based on what the paper should say, what we absolutely have to finish to be able to write the paper. (In other words, if the paper should contain a screen shot of a particular thing, we need to make the thing that will create the screen shot.) This is as good a way to organize our remaining work as anything, and a bonus of writing the paper (besides possibly getting into the conference, which publishes a journal of its proceedings) is that we should be able to fairly easily rework it into our final report for the funding agency.
This all adds up to a lot of work I need to do this weekend. Unlike what you might think, I feel pretty energized thinking about getting up tomorrow morning and tackling this stuff.
Friday!
It's Friday! In addition to the usual Fridayness that everyone can appreciate, Friday night is when I have my date with Mosch. Mosch and I don't get to spend enough time together lately, and he was in Houston all last week, so I'm especially looking forward to hanging out tonight.
Not-Quite-Date
I'm meeting another friend (Ed) for dinner Saturday night. It's not quite a date, but should be fun anyway.
My iPod, which plays random stuff from my entire music collection on my desk at work all day, has been choosing mostly Bob Dylan, Leonard Cohen, and Tom Waits all morning. It seems like it's trying to tell me something, but I'm not sure what. (Be more cynical?)
"Wet bus stop, it's raining, his car is warm and dry"
I got a ride downtown from my professor last night after class, since it was snowing. (It's been very warm lately and then blam! spring snow!) It wasn't that exciting, but I couldn't pass up the opportunity to quote Sting.
Project
My software engineering principles class is working on a project, and it hasn't been going that well for a couple of weeks, but last night we really sat down to design our database schema. I love designing databases, so it was right up my alley. But what was more salient was another thing, which is that the one other smart, diligent person in my class (out of the five of us), Warren, was the main one arguing with me about all of the decisions. (Only three of us even showed up - me, Warren, and a guy who isn't too bright.) So Warren, Dr. Paul, and I spent basically two hours hammering out a lot of this database design, and it was wonderful how it worked, the way that Warren and I were able to argue cogently with each other and bring up all kinds of possible situations in which one design or the other might be superior. It's rare that I've had this kind of experience in any group, much less a school project. I've respected Warren for a while, so this was just like a little capper.
Weekend Plans
Near the end of that class, we each committed to "deliverables" for Tuesday. I volunteered to write the code (PHP) to create the database that we hammered out. (Our design of it is not completely finished, but we did complete a lot of the schema.) This is a big deliverable (to judge by the reactions to my suggestion that I would do it), and it should take me a while, but it feels very doable - I know how to do it, and it's just a matter of actually doing it.
Meanwhile, in my Geometry class, we got another problem set. It's due next Thursday, and I'll probably need to spend a fair number of hours on it. Like the exam, the problem sets usually take a lot of both working time and non-working time where my brain can just mull on the difficult problems, so I need to work on this early and often. (If you're curious, you can see the problem set here.)
Meanwhile, our grant project will be winding to a close soon (there are about six weeks left in the semester), and we haven't accomplished much this semester, though overall we've accomplished what seems (from the outside) like a fair amount. Dr. Paul, who is also the advisor for that, wants us to write a small paper for a conference he thinks we can get into, and we need an abstract for that paper next week. So the idea at this point is to figure out what the paper should say (we actually do have enough material/ideas to write a small paper), write the abstract, and then figure out, based on what the paper should say, what we absolutely have to finish to be able to write the paper. (In other words, if the paper should contain a screen shot of a particular thing, we need to make the thing that will create the screen shot.) This is as good a way to organize our remaining work as anything, and a bonus of writing the paper (besides possibly getting into the conference, which publishes a journal of its proceedings) is that we should be able to fairly easily rework it into our final report for the funding agency.
This all adds up to a lot of work I need to do this weekend. Unlike what you might think, I feel pretty energized thinking about getting up tomorrow morning and tackling this stuff.
Friday!
It's Friday! In addition to the usual Fridayness that everyone can appreciate, Friday night is when I have my date with Mosch. Mosch and I don't get to spend enough time together lately, and he was in Houston all last week, so I'm especially looking forward to hanging out tonight.
Not-Quite-Date
I'm meeting another friend (Ed) for dinner Saturday night. It's not quite a date, but should be fun anyway.
My iPod, which plays random stuff from my entire music collection on my desk at work all day, has been choosing mostly Bob Dylan, Leonard Cohen, and Tom Waits all morning. It seems like it's trying to tell me something, but I'm not sure what. (Be more cynical?)
Thursday, March 29, 2007
Mathematica
After years - or at least a few semesters - of lusting for it, I finally gave in and bought Mathematica. I purchased the Student Edition, which is just like the regular addition but cheaper, for $130; the regular edition is about $900.Mathematica does so much cool stuff, I can't begin to understand or describe it all. It graphs stuff in 2 or 3 (and probably more) dimensions. It solves everything I've ever heard of and way more stuff I've never even heard of, not just numerically but algebraically. You can write animations, you can use it as a programming language, you can make fondue with it! (OK, maybe not that last one.)
Sally was curious whether Mathematica would prove useful or merely cool, and this is something I have thought about. In my dream life plan where I always take a math course, I can't see how Mathematica wouldn't be useful - it certainly would have helped me in most of the math courses I've ever taken, including the Geometry course I'm taking now. And in the even dreamier life where I become a math teacher, well, all the math teachers I've had recently have used Mathematica to make cool handouts, display animations to the class, and for assorted other nifty purposes. And I just really want this as a tool in my general arsenal of life.
Wednesday, March 28, 2007
My Geometry Test
Don't worry, this post is not about math. Honest. (Alternately: don't get excited, this post is not about math.)
Three weeks ago, we were given a take-home test in my Foundations of Geometry course. We had one week to complete the test, and were allowed to use any sources available to us, including friends and classmates, as long as we cited them, and as long as the work we submitted was in our own handwriting and based on our own understanding. (In other words, you could have someone explain to you how to work the problem, but then you should work it.) If the professor was in doubt about your understanding of what you submitted, he might ask you to solve it in front of him with no sources, for instance.
I got this test on a Thursday. It had 6 problems, some with two parts, and I worked on it all weekend. (By "all weekend" I mean I spent about 10 hours on it over the weekend.) I had been to every class session and felt I understood the material as well as anyone in the class, but the test asked us to do things we had never been shown. By Sunday night, I had completed 3.5 of the 6 questions, or 58%. That's an F.
I was feeling pretty bad about my chances, but forced myself to work on the test consistently during the week. I had known already that some of the questions would likely take a lot of "brain processing time," so I was sure to attempt every question over the weekend, just so my brain would have the material to work on while I wasn't doing anything.
Over the week, as a result of my work and thinking, ways of solving these problems eventually came to me. Wednesday night, I had finished 5.5 out of 6 problems, correctly I thought, and had an idea about how to approach the last 1/2 problem. I figured this would be enough to get me an A, even if I didn't quite correctly solve the last 1/2 problem. I ended up taking what I thought was a good stab at that problem though I wasn't at all sure my answer was correct.
I ended up with a 97 on the test, which was higher than I'd hoped for, and obviously a very pleasing grade. I have no idea how the class as a whole did. (I felt a bit pessimistic because some people were saying things like "That test took me 8 hours!" and I was like "8 hours?? You did that all that in 8 hours?!")
This story is pretty boring, perhaps even self-aggrandizing, until you consider that this type of experience - consistent applied effort towards something originally impossible-seeming leading to success - is very rare for me. Usually I either succeed at something pretty easily or I give up. Usually I put off assignments until the last minute, which in this case would have resulted in an F (considering that the entire weekend was only enough to get me 58% finished).
I didn't really enjoy the anxiety I had to go through with this test, but I'm really pleased that this course - which I chose for my degree plan partly because I thought it would force me to work hard to think through problems - is providing an experience where effort correlates to results so closely. It should help me move away from the model where I am either smart or stupid at something, and towards a belief that I can succeed at even difficult things if I keep working at them.
I reserve the right to change my mind if I end up with a C in the course.
Three weeks ago, we were given a take-home test in my Foundations of Geometry course. We had one week to complete the test, and were allowed to use any sources available to us, including friends and classmates, as long as we cited them, and as long as the work we submitted was in our own handwriting and based on our own understanding. (In other words, you could have someone explain to you how to work the problem, but then you should work it.) If the professor was in doubt about your understanding of what you submitted, he might ask you to solve it in front of him with no sources, for instance.
I got this test on a Thursday. It had 6 problems, some with two parts, and I worked on it all weekend. (By "all weekend" I mean I spent about 10 hours on it over the weekend.) I had been to every class session and felt I understood the material as well as anyone in the class, but the test asked us to do things we had never been shown. By Sunday night, I had completed 3.5 of the 6 questions, or 58%. That's an F.
I was feeling pretty bad about my chances, but forced myself to work on the test consistently during the week. I had known already that some of the questions would likely take a lot of "brain processing time," so I was sure to attempt every question over the weekend, just so my brain would have the material to work on while I wasn't doing anything.
Over the week, as a result of my work and thinking, ways of solving these problems eventually came to me. Wednesday night, I had finished 5.5 out of 6 problems, correctly I thought, and had an idea about how to approach the last 1/2 problem. I figured this would be enough to get me an A, even if I didn't quite correctly solve the last 1/2 problem. I ended up taking what I thought was a good stab at that problem though I wasn't at all sure my answer was correct.
I ended up with a 97 on the test, which was higher than I'd hoped for, and obviously a very pleasing grade. I have no idea how the class as a whole did. (I felt a bit pessimistic because some people were saying things like "That test took me 8 hours!" and I was like "8 hours?? You did that all that in 8 hours?!")
This story is pretty boring, perhaps even self-aggrandizing, until you consider that this type of experience - consistent applied effort towards something originally impossible-seeming leading to success - is very rare for me. Usually I either succeed at something pretty easily or I give up. Usually I put off assignments until the last minute, which in this case would have resulted in an F (considering that the entire weekend was only enough to get me 58% finished).
I didn't really enjoy the anxiety I had to go through with this test, but I'm really pleased that this course - which I chose for my degree plan partly because I thought it would force me to work hard to think through problems - is providing an experience where effort correlates to results so closely. It should help me move away from the model where I am either smart or stupid at something, and towards a belief that I can succeed at even difficult things if I keep working at them.
I reserve the right to change my mind if I end up with a C in the course.
Friday, March 23, 2007
Estimation vs. Guessing
When I was a kid, some book I had contained an exercise like this. Try to guess how big around your waist is, it said. It probably had a space to write down your guess. Then it recommended a technique for getting an estimate. Put your hands at your sides and use them to estimate how wide you are at the waist. Now assume your body is pretty circular. If you multiply your estimated width by 3, which is approximately pi, you can get an estimate of the circumference (diameter * pi = circumference of a circle). If you write down that estimate and then actually measure around your waist, it's probably much closer than your original guess.
I don't know if this book was trying to make a point about estimation or one about geometry, but lately the idea of estimation has come up a lot in my life. I think current school curricula for kids put more emphasis on this than when I was a kid too.
In any case, recently in our Software Engineering Principles class, Dr. Paul asked us to discuss amongst ourselves how we would set up a software testing program, how we would estimate the time that the testing would take, and how we would decide when testing was finished. So we talked about this for a few minutes, sharing what we'd learned from various readings, until the conversation ground to a halt.
"Are you done?" he asked us. We nodded, more or less.
"What did you decide?" he asked.
Our general answer was along the lines of, "Nobody knows, you can't really estimate it, and anything you come up with is just going to be kind of a way to justify your gut, so you just kind of release the software when you think it's ready."
He became theatrically angry with us. His general point was that any method of estimation would be better than a guess or "gut feeling" and that if he would accept a guess or gut feeling from anyone, it would be people with years of experience running successful projects, not a bunch of college seniors. Oops.
Let me give you a sense of how hard it is to estimate "how long testing will take." You could do it like this:
Nevertheless, if you instead just "guess" how long testing will take, you'll most likely be off by as much as an order of magnitude (so you might guess 2 months when it will really take 20 months). Any intelligent estimation technique will get you much closer than that.
The other advantage of estimation over guessing is that you can learn from mistakes. If I made the estimate above for an actual project, and the testing instead took 80 weeks, I could see places where the model was wrong - were there way more bugs than we thought? did people find a lot fewer per week than we guessed they would? were we still finding really critical bugs even when we were no longer finding very many bugs in general? This would allow me to make a better estimate for the next project. It is much harder to adjust your gut; you can only use very crude adjustments like "I'm always too optimistic" or "things take twice as long as I tend to think."
Sometimes time estimation can brighten your day too. If you have a stack of 200 forms to process, it might feel like you'll never finish, but if you time yourself while you do 5 and find that 3 minutes have elapsed, you know you can finish in two hours, not counting breaks. So really, if you're starting in the morning, you'll easily be done by lunch.
Budgeting is another example of estimation's superiority over guessing, but that's a whole topic of its own.
I don't know if this book was trying to make a point about estimation or one about geometry, but lately the idea of estimation has come up a lot in my life. I think current school curricula for kids put more emphasis on this than when I was a kid too.
In any case, recently in our Software Engineering Principles class, Dr. Paul asked us to discuss amongst ourselves how we would set up a software testing program, how we would estimate the time that the testing would take, and how we would decide when testing was finished. So we talked about this for a few minutes, sharing what we'd learned from various readings, until the conversation ground to a halt.
"Are you done?" he asked us. We nodded, more or less.
"What did you decide?" he asked.
Our general answer was along the lines of, "Nobody knows, you can't really estimate it, and anything you come up with is just going to be kind of a way to justify your gut, so you just kind of release the software when you think it's ready."
He became theatrically angry with us. His general point was that any method of estimation would be better than a guess or "gut feeling" and that if he would accept a guess or gut feeling from anyone, it would be people with years of experience running successful projects, not a bunch of college seniors. Oops.
Let me give you a sense of how hard it is to estimate "how long testing will take." You could do it like this:
- Our software has 100,000 line of code.
- We know from the literature that very good programmers usually introduce about 4 bugs per line of code if the code is not too complex.
- That means our software has about 400,000 bugs.
- Except we had some really good reviews while we wrote this, so we bet we found half of 'em already, so there might be 200,000 bugs left.
- Our software isn't that important (it's not for a cancer radiation machine or the Mars rover or whatever), so we can release it when 85% of the bugs are gone.
- This means we need to find and fix 170,000 bugs in order to release our software.
- We have a team of 20 people and we think each person can find 15 bugs per week. We think we can fix them at about that rate too.
- So we estimate it will take about 57 weeks to test and debug this software.
Nevertheless, if you instead just "guess" how long testing will take, you'll most likely be off by as much as an order of magnitude (so you might guess 2 months when it will really take 20 months). Any intelligent estimation technique will get you much closer than that.
The other advantage of estimation over guessing is that you can learn from mistakes. If I made the estimate above for an actual project, and the testing instead took 80 weeks, I could see places where the model was wrong - were there way more bugs than we thought? did people find a lot fewer per week than we guessed they would? were we still finding really critical bugs even when we were no longer finding very many bugs in general? This would allow me to make a better estimate for the next project. It is much harder to adjust your gut; you can only use very crude adjustments like "I'm always too optimistic" or "things take twice as long as I tend to think."
Sometimes time estimation can brighten your day too. If you have a stack of 200 forms to process, it might feel like you'll never finish, but if you time yourself while you do 5 and find that 3 minutes have elapsed, you know you can finish in two hours, not counting breaks. So really, if you're starting in the morning, you'll easily be done by lunch.
Budgeting is another example of estimation's superiority over guessing, but that's a whole topic of its own.
Stand Back!
After resisting buying any more nerdy t-shirts for months - months, I tell you - I finally let myself buy two. This one, from xkcd, came in the mail yesterday. It's gorgeous - even better than I hoped. The design is very large on the shirt and very detailed (you can see the buttons on the calculator).
Friday, March 16, 2007
A Geek's Story
I continue to read I Blame the Patriarchy despite its excessive anti-patriarchalism (aka too-radical feminism). But this entry "A Geek's Story" is just delightful, and you don't even have to be a feminist to enjoy it. Try it and see!
Thursday, March 08, 2007
Blog Against Sexism Day
According to Amanda Marcotte on Pandagon, today is Blog Against Sexism Day. (It is also International Women's Day.) This is something I feel pretty strongly about, so I'll try to put together a semi-coherent post. Marcotte's is better and I highly recommend it.
One question she asks is
This is a tricky one for me. As a very young child, I already had some feminist instincts, which I can only assume came from my mom. I remember my grandmother telling me, "Act like a little lady," and how much it rankled me. Being anti-feminine, as I have been as long as I can remember, is not identical to being feminist, but the two are related insofar as one agrees that femininity is a social construct to keep women down, or, alternately, a coping mechanism that allows women to survive under patriarchy.
At the same time, there were always giant gaps in my feminist understanding. I remember one time at church (First Unitarian in Houston), I visited the women's group because Houston's mayor (Kathy Whitmire) was giving a speech there. After the speech, a woman from the group cornered me (as I perceived it) and demanded to know whether I was a feminist. I think I probably stammered that I was a humanist. My view of this incident is different now, but I remember complaining to Mosch about it later. I had a resistance - one I think is typical to people my age - to describing myself as a feminist. Didn't it imply valuing women above men? Wouldn't it be wrong to consider oneself a masculinist? etc.
A more important area in which I was wrong was that my sexuality had too strong an emphasis on pleasing men. I believed that being "good in bed" (by which I meant "able to please a man") was important - far more important than getting pleasure myself. (I would have described this differently at the time, probably explaining that giving pleasure to another was how I got off.) Because of this and because I am slightly tricky to bring to orgasm, it took many years for me to learn as much as I now know about my own body.
In general, I had the view that men will not stick around, or will suffer unduly, if they don't have orgasms whenever they want them. I had an early boyfriend who definitely encouraged this view. There were many other ways in which I failed to be adequately selfish in that early relationship, especially sexually.
I remember learning that a friend of mine would, if she got tired of having intercourse (during the act, I mean), actually just stop (say "I'm done" or whatever). That kind of blew my mind at the time - wasn't it your obligation as a decent human being to continue until the guy came? Wasn't the decision to fuck basically a contract?
Well, no. I don't mean to portray myself as a totally selfish jerk - I am actually a pretty generous lover, all things considered - but I have gotten over my early ideas that (a) a man will die or be harmed by not having an orgasm, and, more importantly, that (b) a woman's duty is to be a receptacle for male pleasure. (Of course, I would never have said otherwise, but I think that was the basic idea underlying my attitudes.)
There is lots of stuff at the Pandagon post I linked earlier that is more germane to global feminist aims, so I won't address that here, but just leave this as a report of (some of) my personal experiences. Of course sexuality is not the only area in which I think feminism is important, even on a personal level - but it's one thing.
One question she asks is
When did you become a feminist? Either when you embraced the word or when you realized that sexism is still a problem and that feminism is still necessary?
This is a tricky one for me. As a very young child, I already had some feminist instincts, which I can only assume came from my mom. I remember my grandmother telling me, "Act like a little lady," and how much it rankled me. Being anti-feminine, as I have been as long as I can remember, is not identical to being feminist, but the two are related insofar as one agrees that femininity is a social construct to keep women down, or, alternately, a coping mechanism that allows women to survive under patriarchy.
At the same time, there were always giant gaps in my feminist understanding. I remember one time at church (First Unitarian in Houston), I visited the women's group because Houston's mayor (Kathy Whitmire) was giving a speech there. After the speech, a woman from the group cornered me (as I perceived it) and demanded to know whether I was a feminist. I think I probably stammered that I was a humanist. My view of this incident is different now, but I remember complaining to Mosch about it later. I had a resistance - one I think is typical to people my age - to describing myself as a feminist. Didn't it imply valuing women above men? Wouldn't it be wrong to consider oneself a masculinist? etc.
A more important area in which I was wrong was that my sexuality had too strong an emphasis on pleasing men. I believed that being "good in bed" (by which I meant "able to please a man") was important - far more important than getting pleasure myself. (I would have described this differently at the time, probably explaining that giving pleasure to another was how I got off.) Because of this and because I am slightly tricky to bring to orgasm, it took many years for me to learn as much as I now know about my own body.
In general, I had the view that men will not stick around, or will suffer unduly, if they don't have orgasms whenever they want them. I had an early boyfriend who definitely encouraged this view. There were many other ways in which I failed to be adequately selfish in that early relationship, especially sexually.
I remember learning that a friend of mine would, if she got tired of having intercourse (during the act, I mean), actually just stop (say "I'm done" or whatever). That kind of blew my mind at the time - wasn't it your obligation as a decent human being to continue until the guy came? Wasn't the decision to fuck basically a contract?
Well, no. I don't mean to portray myself as a totally selfish jerk - I am actually a pretty generous lover, all things considered - but I have gotten over my early ideas that (a) a man will die or be harmed by not having an orgasm, and, more importantly, that (b) a woman's duty is to be a receptacle for male pleasure. (Of course, I would never have said otherwise, but I think that was the basic idea underlying my attitudes.)
There is lots of stuff at the Pandagon post I linked earlier that is more germane to global feminist aims, so I won't address that here, but just leave this as a report of (some of) my personal experiences. Of course sexuality is not the only area in which I think feminism is important, even on a personal level - but it's one thing.
Friday, March 02, 2007
Doctor Visit
Today I visited "Dr. Lisa," the family practice physician currently being seen by my entire household. (Sweet, isn't it?) This was my first time to see her, and my first time in about three years to go in for my physical and whatnot. (I did visit the Health Fair last spring and get my bloodwork done.)
As I'd been told beforehand, Dr. Lisa was great - she took plenty of time to ask me lots of questions, and to listen to my concerns. (When I told her my maternal grandmother died of ovarian cancer, after telling her my dad and his parents all have Type II diabetes - from which my dad died last year at the age of 53 - she said, "You have a sucky family history!" Heh.)
Her other comment, later, was, "Boy, you really do not like to have your cervix touched." This is very true, but I survived, as usual.
[Note: Anyone with blood phobias - hello, Sally - should stop reading now. I'm inserting a pleasing graphic to ensure total isolation.]
When she was done with me, she sent me to get my blood drawn by one of her assistants. I used to have a lot of trouble getting blood drawn, but lately I've been fine. I basically got over my blood-draw phobia by donating blood a few times. This had the negative effect of making some of my veins no good, but I also got much calmer about having blood taken. The last time I got tested for stuff - at the Health Fair - I had no trouble at all.
As I'd been told beforehand, Dr. Lisa was great - she took plenty of time to ask me lots of questions, and to listen to my concerns. (When I told her my maternal grandmother died of ovarian cancer, after telling her my dad and his parents all have Type II diabetes - from which my dad died last year at the age of 53 - she said, "You have a sucky family history!" Heh.)
Her other comment, later, was, "Boy, you really do not like to have your cervix touched." This is very true, but I survived, as usual.
[Note: Anyone with blood phobias - hello, Sally - should stop reading now. I'm inserting a pleasing graphic to ensure total isolation.]
When she was done with me, she sent me to get my blood drawn by one of her assistants. I used to have a lot of trouble getting blood drawn, but lately I've been fine. I basically got over my blood-draw phobia by donating blood a few times. This had the negative effect of making some of my veins no good, but I also got much calmer about having blood taken. The last time I got tested for stuff - at the Health Fair - I had no trouble at all.
Unfortunately, today was difficult. The first time the woman stuck me, it didn't hurt at all. The bad news was that it also did not pierce a vein at all. She worked in that area for a while, with increasing amounts of pain, but got nowhere, and gave up to find a different spot (nearby, as it turned out). The second attempt was very painful but successful.
I didn't like how it felt, but I was fine - after all, I am a trooper about this stuff now. I told her how they sometimes have to take it from the back of my hand, and how one person once took it from my wrist. (They use tiny needles for this and it takes forever.) I told her how the next person, after the wrist person, said, "Don't ever let them take it from your wrist! Have them do the back of your hand!"
Then I said, "We have to stop talking about this," because I was starting to feel faint. She started asking me questions about where I work, and I was answering for a bit, but then I just started feeling worse and worse and couldn't answer. I tried desperately to think of other things. Blood was rushing in my ears and I leaned over to put my head on my hand. She called in another nurse who put a cold compress on my forehead. I just felt worse and worse until I felt I could not take much more.
Eventually I managed to mutter, "Are you almost done?" and the other woman who had come in said, "She's already done, honey," and I said, "...oh, I didn't know she was done..." and she said, "That's because you were out." Oh.
I could have sworn the needle was still in, but sure enough it was gone, a band-aid was there, and the rubber-bandy tourniquet was also off my arm. After a minute, they walked me very cautiously to an exam room where I lay on a table for a few minutes and drank some Hi-C before gradually sitting up and being allowed to leave (with an admonition to eat something on the way to work; I'd been fasting for the blood tests, though I didn't feel hungry at all, even before passing out).
They made a note on my chart and will have me lie down in the future. I know this isn't uncommon but I was surprised that it happened to me, especially since lately I have not been phobic about this at all. I am also surprised how terrible it feels to pass out.
Thursday, March 01, 2007
More on Self-Efficacy and Praising Kids
(Update: Sally over at Empirical Question has a great, longer commentary on this article.)
Via Uncertain Principles, I discovered this New York Magazine article ("How Not to Talk to Your Kids" by Po Bronson, 2/19/07) about exactly what I was writing about the other day - praising kids for their efforts versus their intelligence.
The article is about a study by Carol Dweck and others from Columbia University, where they took a group of fifth graders and gave them an easy puzzle task (easy enough that everyone would do pretty well). After the test, each child was praised either for their smarts or for their effort, with a one-line remark. Being praised for smarts vs. effort had a variety of surprising negative effects on subsequent performance in the experiment. (Read the whole article if this is up your alley; it's pretty interesting.)
This type of research feels very meaningful to me, because I grew up as a smart kid who almost never worked hard at anything. ("Grew up as?" Try "still am.") I have, or used to have, a seemingly instinctive feeling of slight contempt for people who work hard, especially in an academic setting. (As the article says, "Expending effort becomes stigmatized—it’s public proof that you can’t cut it on your natural gifts.") Every bad effect described in that article (giving up on difficult tasks too soon; feeling unreasonably insecure about my abilities; unwillingness to work hard at something) is one I have observed in myself.
Contempt for effort is a really wrong value to hold. From a kind of touchy-feely moral perspective, people can't control their innate talents, while they can control how hard they work, so working hard is morally preferable to being talented. And, more importantly, working hard is what determines your results relative to your talent, and to some extent regardless of your talent. And out here in the "real world", almost anyone would (rightly) prefer to work with a diligent person of ordinary talents than with a lazy smarty-pants.
Via Uncertain Principles, I discovered this New York Magazine article ("How Not to Talk to Your Kids" by Po Bronson, 2/19/07) about exactly what I was writing about the other day - praising kids for their efforts versus their intelligence.
The article is about a study by Carol Dweck and others from Columbia University, where they took a group of fifth graders and gave them an easy puzzle task (easy enough that everyone would do pretty well). After the test, each child was praised either for their smarts or for their effort, with a one-line remark. Being praised for smarts vs. effort had a variety of surprising negative effects on subsequent performance in the experiment. (Read the whole article if this is up your alley; it's pretty interesting.)
This type of research feels very meaningful to me, because I grew up as a smart kid who almost never worked hard at anything. ("Grew up as?" Try "still am.") I have, or used to have, a seemingly instinctive feeling of slight contempt for people who work hard, especially in an academic setting. (As the article says, "Expending effort becomes stigmatized—it’s public proof that you can’t cut it on your natural gifts.") Every bad effect described in that article (giving up on difficult tasks too soon; feeling unreasonably insecure about my abilities; unwillingness to work hard at something) is one I have observed in myself.
Contempt for effort is a really wrong value to hold. From a kind of touchy-feely moral perspective, people can't control their innate talents, while they can control how hard they work, so working hard is morally preferable to being talented. And, more importantly, working hard is what determines your results relative to your talent, and to some extent regardless of your talent. And out here in the "real world", almost anyone would (rightly) prefer to work with a diligent person of ordinary talents than with a lazy smarty-pants.
Wednesday, February 28, 2007
Snowing Up
I would like to report that, right now, outside my office window and for as far as the eye can see (which isn't too far), it is snowing UP. I take it this means that the snow that has accumulated on the ground will fly away to Kansas or somewhere. Bonus!
Tuesday, February 27, 2007
Finished My Round-Trip Project
My project for my software engineering class for the past five days was to use three technologies (Apache, PHP, and MySQL) to make a webpage that would take data from a form, store it in a database, and another webpage that would read it from the database and display it. This "round trip" is a part of the technical backbone for our group project.
I worked hard on this all weekend, got most of it done by Sunday night, and finished up the rest last night. It took me a lot of work and many parts of it were pretty fiddly, so I feel like a super stud for getting it to work.
Since the purpose of my work was to make this process faster and easier for the rest of the group (which consists of the entire class; there are only 5 of us), I also wrote up a 9-page document with installation instructions, tips, the code that I used, and screenshots of the web pages. I'll bring copies of that to class tonight.
I worked hard on this all weekend, got most of it done by Sunday night, and finished up the rest last night. It took me a lot of work and many parts of it were pretty fiddly, so I feel like a super stud for getting it to work.
Since the purpose of my work was to make this process faster and easier for the rest of the group (which consists of the entire class; there are only 5 of us), I also wrote up a 9-page document with installation instructions, tips, the code that I used, and screenshots of the web pages. I'll bring copies of that to class tonight.
A Cure for Nearsightedness?
Today's Medical Examiner in Slate is partly about a potential cure or treatment to keep nearsightedness from progressing in children. It was a strange read for me, because the cure sounds so much worse than the disease. Apparently by putting eye-dilation drops in your children's eyes every night, which forces them to wear glasses that change color in light (so their eyes aren't damaged by being dilated) and possibly to wear bifocals for reading (since you can't focus close-up when your eyes are dilated), you can keep their nearsightedness from progressing.
I started needing glasses when I was around 7, and I hated them at first, and my eyes got rapidly worse in those first few years, and continued to get worse for a while after that. I have to wear glasses to do pretty much anything (even read a book). But I think I would have hated nightly eyedrops and wearing light-sensitive bifocals for years way more than I hated just wearing glasses.
In fact, if you told me right now that by doing that for five years, I could have perfect vision restored to me, I wouldn't take the deal. And I'm an adult.
I wore contacts for a while in high school. I was so happy to not have to wear glasses - mainly for reasons of vanity. At some point I got a little eye infection and had to wear my glasses again for a while, and it made me realize how wonderfully convenient and easy glasses are compared to something you wear on your eye. (Sorry, Sally!) Truly they are just not a big deal.
I know some people have really terrible eyesight, and maybe the results of this research can become something useful, but for now, it doesn't sound like a useful finding to me (even assuming it is confirmed in subsequent research). I feel so strongly about it that I'm not even sure about the ethics of carrying out the research. What am I missing?
I started needing glasses when I was around 7, and I hated them at first, and my eyes got rapidly worse in those first few years, and continued to get worse for a while after that. I have to wear glasses to do pretty much anything (even read a book). But I think I would have hated nightly eyedrops and wearing light-sensitive bifocals for years way more than I hated just wearing glasses.
In fact, if you told me right now that by doing that for five years, I could have perfect vision restored to me, I wouldn't take the deal. And I'm an adult.
I wore contacts for a while in high school. I was so happy to not have to wear glasses - mainly for reasons of vanity. At some point I got a little eye infection and had to wear my glasses again for a while, and it made me realize how wonderfully convenient and easy glasses are compared to something you wear on your eye. (Sorry, Sally!) Truly they are just not a big deal.
I know some people have really terrible eyesight, and maybe the results of this research can become something useful, but for now, it doesn't sound like a useful finding to me (even assuming it is confirmed in subsequent research). I feel so strongly about it that I'm not even sure about the ethics of carrying out the research. What am I missing?
Monday, February 26, 2007
"Fourthmeal"?
I have visited Taco Bell a couple of times lately (which is unusual for me) and both times noticed prominent advertisements for "Fourthmeal," Taco Bell's name for a meal that putatively exists between dinner and breakfast. (In other words, that meal that teenagers and adults-who-live-like-teenagers get late at night from Taco Bell.)
I happen to think this is a potentially brilliant marketing concept. If you can legitimize late-night snacking as a meal, and eventually convince people that they have to eat this new fake meal every day, it could work.
But "Fourthmeal"? I can't think of any name less likely to stick or become widely used. Couldn't they get someone to come up with a catchy name that they could promote the hell out of?
(By the way, if you go to the Fourthmeal site linked above, you will have to choose your gender in order to enter. Is that creepy to anyone besides me?)
I happen to think this is a potentially brilliant marketing concept. If you can legitimize late-night snacking as a meal, and eventually convince people that they have to eat this new fake meal every day, it could work.
But "Fourthmeal"? I can't think of any name less likely to stick or become widely used. Couldn't they get someone to come up with a catchy name that they could promote the hell out of?
(By the way, if you go to the Fourthmeal site linked above, you will have to choose your gender in order to enter. Is that creepy to anyone besides me?)
Friday, February 23, 2007
Software Project
My Software Engineering Principles class has so far been rather like a seminar. There are only five students, and typically we just meet, and everyone should have read up on the topic we're going to discuss, and then we discuss the topic and what we've read. Sometimes we have to write a little reflection or some "nuggets" (pithy statements on a topic), but pretty much it's just been reading & talking. I like it!
But, since the follow-up class to this (Software Engineering Practices, my "senior experience" course) is all about working on a big software project, we're going to have a miniature software project for this class, and we started on that Tuesday.
Dr. Paul's idea, which nobody vetoed, is that we should write a requirements management tool. (Requirements are very precise statements about what a piece of software is meant to do and not do. They essentially form the contract between developers and customers/clients. Requirement engineering is what you do before you start working on design or actual coding, in theory.) The most commonly used requirements management tool is probably, alas, Microsoft Word.
I am not one of those anti-MS people, but the problem with keeping requirements in Word (or any word processing software) is that it limits them to being a flat document. What you really want is for requirements to be "live", to facilitate tracking changes over time, to allow for dependency relationships between different requirement statements, and to be able to link requirements to specific parts of the design and the actual code. And of course you also want to be able to produce them as a document.
What Dr. Paul would like is for our application to be open source, web-based, and backed by a database, and for it to support the Volere shell and template. (Volere is basically a style of requirements - sort like how APA or MLA are styles for writing papers.) He suggested (though this is up to us, ultimately) that we could use CSS (cascading style sheets, into which you feed HTML files that it then formats in a consistent way, so that you can take the same HTML pages and show them different ways), PHP (a scripting language that generates HTML pages), and mySQL (an open source database) to solve our technology needs.
Of course, in our first meeting on this (the day he told us about it), we all started jumping in talking about coding the thing, and he sort of interrupted us to say, essentially, "Uh, how about using proper software engineering practices since that's what this class is about, dummies." So we discussed our software lifecycle model (settling on a risk-based iterative model, for now), and started working on requirements. (Too bad we don't have a web-based, open source requirements management tool! Oh yeah.)
So as of this moment we have a pretty good list of proto-requirements. Near the end of class last night we discussed deliverables for Tuesday, so that everyone would have something to work on. Warren is going to get our proto-requirements partly into the Volere template (which has the dual purpose of making our requirements nicer while increasing familiarity with the Volere template) and think about a database schema. Nobody else volunteered for a specific responsibility (despite the suggestion from Dr. Paul that we do so) besides me.
My job is to download PHP, mySQL, set up an Apache server on my own machine, and figure out how basically to make the round trip from a web page where you enter something, to a database, and back out to a display page. I should have this done by Tuesday and be ready to show the class the code and process for how this is done.
(What I mean by "make the round trip" is to code up a page that has blanks where you type stuff in, and then it takes the typed in stuff and stores it in the database, and then you can go to another page to see what is in the database.)
I've never worked with PHP or mySQL before, or really done any web-based stuff at all, so this should be a fun challenge to put together by Tuesday.
But, since the follow-up class to this (Software Engineering Practices, my "senior experience" course) is all about working on a big software project, we're going to have a miniature software project for this class, and we started on that Tuesday.
Dr. Paul's idea, which nobody vetoed, is that we should write a requirements management tool. (Requirements are very precise statements about what a piece of software is meant to do and not do. They essentially form the contract between developers and customers/clients. Requirement engineering is what you do before you start working on design or actual coding, in theory.) The most commonly used requirements management tool is probably, alas, Microsoft Word.
I am not one of those anti-MS people, but the problem with keeping requirements in Word (or any word processing software) is that it limits them to being a flat document. What you really want is for requirements to be "live", to facilitate tracking changes over time, to allow for dependency relationships between different requirement statements, and to be able to link requirements to specific parts of the design and the actual code. And of course you also want to be able to produce them as a document.
What Dr. Paul would like is for our application to be open source, web-based, and backed by a database, and for it to support the Volere shell and template. (Volere is basically a style of requirements - sort like how APA or MLA are styles for writing papers.) He suggested (though this is up to us, ultimately) that we could use CSS (cascading style sheets, into which you feed HTML files that it then formats in a consistent way, so that you can take the same HTML pages and show them different ways), PHP (a scripting language that generates HTML pages), and mySQL (an open source database) to solve our technology needs.
Of course, in our first meeting on this (the day he told us about it), we all started jumping in talking about coding the thing, and he sort of interrupted us to say, essentially, "Uh, how about using proper software engineering practices since that's what this class is about, dummies." So we discussed our software lifecycle model (settling on a risk-based iterative model, for now), and started working on requirements. (Too bad we don't have a web-based, open source requirements management tool! Oh yeah.)
So as of this moment we have a pretty good list of proto-requirements. Near the end of class last night we discussed deliverables for Tuesday, so that everyone would have something to work on. Warren is going to get our proto-requirements partly into the Volere template (which has the dual purpose of making our requirements nicer while increasing familiarity with the Volere template) and think about a database schema. Nobody else volunteered for a specific responsibility (despite the suggestion from Dr. Paul that we do so) besides me.
My job is to download PHP, mySQL, set up an Apache server on my own machine, and figure out how basically to make the round trip from a web page where you enter something, to a database, and back out to a display page. I should have this done by Tuesday and be ready to show the class the code and process for how this is done.
(What I mean by "make the round trip" is to code up a page that has blanks where you type stuff in, and then it takes the typed in stuff and stores it in the database, and then you can go to another page to see what is in the database.)
I've never worked with PHP or mySQL before, or really done any web-based stuff at all, so this should be a fun challenge to put together by Tuesday.
Another Way to Increase Self-Efficacy
...is to be forced to change your car tire on the way to work at 8 AM.
I can't recommend it, though. Phew.
I can't recommend it, though. Phew.
Thursday, February 22, 2007
Exercise and Self-Efficacy
At home I have a book (A Kind and Just Parent, by William Ayers) in which the author (who taught teen boys in juvenile detention) explains why he encourages them to lift weights, even during school time. He says that by working out with weights, the boys are able to apply effort and see results - and learn, hopefully, that they can change themselves by trying. (At least, that's my vague memory from reading the book a few years ago.)I often say that exercising, and especially weight-lifting, makes me feel "like a stud." What I really mean is that it increases my self-efficacy. Self-efficacy isn't my own invented concept, and you can read about it elsewhere, but what follows is my own take on it, which is not necessarily quite correctly in line with the original idea.
Self-efficacy is the belief that you can succeed at something through effort. I believe I could get a PhD in mathematics if I tried hard enough, but I don't believe I could ever be good at basketball - I have high self-efficacy in one area and low self-efficacy in the other (regardless of whether I'm correct in my judgments). But what I'm more interested in is self-efficacy in general - to what extent do I believe my results are influenced by my efforts, versus by factors beyond my control?
It seems to me from what I've read [note: this is a hedge to avoid providing references] that instilling self-efficacy (the idea that you can succeed through effort) in your children is much more important than instilling self-esteem (the belief that you're an OK person deep inside). In education, you can reinforce this by telling a kid who's done well on a math test, "You've been working really hard on that, I can tell," rather than, "Wow, you're really good at math." Ideally you would also put your child into situations where their effort really does determine their outcomes - not in situations where they will succeed (or fail) no matter what.
Anyway, I feel like I do increase my own self-efficacy when I exercise, and I bet this is true for most people, at least if they start with some activity they can make a good go at, because typically you make a lot of progress in the beginning of a new activity (especially if you're out of shape to begin with), and it really builds confidence.
I try to control my eating, but even if I have (momentarily) given up on that, and I get into a regular pattern of exercising, I suddenly get the feeling that I can fix my eating habits too, and then I start eating properly. In any given week, there is a high correlation between my exercise and eating habits, and I don't think it's just that I have "more will power" some weeks than others (though this might be true in some way). I really think exercise drives the whole thing for me.
Because it makes me feel like a stud.
Wednesday, February 21, 2007
What Is a Geometry?
That was the question answered in my Geometry class last night. Here, for your entertainment, I will produce a (non-rigorous) version of the answer.
Let's start with the idea that geometry is about congruence - which figures are congruent to each other? In Euclidean geometry, as I said yesterday, figures are congruent if you can make them line up by rotating them, moving them around, or flipping them over.
So basically, a geometry is a set (in our class so far, typically this is the complex plane - which is basically just a flat 2-dimensional space that extends infinitely) plus rules about what figures are congruent.
What types of rules pass as a geometry? Well, the basic thing is that congruence is an "equivalence relation," which means it has to satisfy these criteria:
These properties, which define an equivalence relation, are also true for common ideas like "equals" or "makes the same amount of money as" or "lives in the same city as" - basically, stuff that seems like it's related to things being equal. They aren't necessarily true for other types of relations, like "likes" (Sally likes me, and I liked David, but Sally didn't like David - liking is not transitive - and actually it's not reflexive or symmetric either) or "is bigger than" (which is transitive, but anti-symmetric and anti-reflexive).
So, getting a bit more formal, a geometry is a set (such as the complex plane) plus a group of allowable functions on the set, where the group of allowable functions forms an equivalence relation. Since we're doing this with algebra, not by picking up pieces of paper and moving them around ala Euclid, this can be set out rigorously with...well, math. Here are some types of transformations, or functions on the complex plane:
So the next part of class was investigating some combinations of these to see if they could constitute a geometry.
For instance, if your only function is reflection across the x-axis, this is not a geometry. Why? Because under that system, a figure is not congruent to itself. (It's only congruent to its reflection.)
But if you add the identity function, so that you have the identity function plus reflection across the x-axis, you have a geometry! You can formally test the properties of an equivalence relation in this case like this:
Another geometry could include only translations. Does this satisfy?
A less mathy way of saying this is to remember that translation means moving things around without rotating or flipping them. Is a figure congruent to itself? Sure - you just move it around not at all. If you can move one figure onto another, then you can surely move the other onto it instead, so it's symmetric. And if you can move figure A onto figure B, and figure B onto figure C, then you could move A onto C by just moving it onto B first, then following B's path to C, so it's transitive.
Note that all of these different geometries have different rules about, essentially, which types of figures are congruent to each other. Fun and games! (Did anyone actually finish this post?)
Let's start with the idea that geometry is about congruence - which figures are congruent to each other? In Euclidean geometry, as I said yesterday, figures are congruent if you can make them line up by rotating them, moving them around, or flipping them over.
So basically, a geometry is a set (in our class so far, typically this is the complex plane - which is basically just a flat 2-dimensional space that extends infinitely) plus rules about what figures are congruent.
What types of rules pass as a geometry? Well, the basic thing is that congruence is an "equivalence relation," which means it has to satisfy these criteria:
- A figure is always congruent to itself. [reflexivity]
- If figure A is congruent to figure B, then B is congruent to A. [symmetry]
- if figure A is congruent to figure B, and B is congruent to figure C, then A is congruent to C. [transitivity]
These properties, which define an equivalence relation, are also true for common ideas like "equals" or "makes the same amount of money as" or "lives in the same city as" - basically, stuff that seems like it's related to things being equal. They aren't necessarily true for other types of relations, like "likes" (Sally likes me, and I liked David, but Sally didn't like David - liking is not transitive - and actually it's not reflexive or symmetric either) or "is bigger than" (which is transitive, but anti-symmetric and anti-reflexive).
So, getting a bit more formal, a geometry is a set (such as the complex plane) plus a group of allowable functions on the set, where the group of allowable functions forms an equivalence relation. Since we're doing this with algebra, not by picking up pieces of paper and moving them around ala Euclid, this can be set out rigorously with...well, math. Here are some types of transformations, or functions on the complex plane:- Rotation - You can rotate around the origin (0) or around some other point.
- Translation - This means moving the plane side to side, up and down, or diagonally, without rotating it.
- Reflection - This means making the figure into a mirror image of itself across some line, such as the x-axis, or y-axis, or anywhere else you want.
- The identify function - this just maps each point to itself. It doesn't change anything.
So the next part of class was investigating some combinations of these to see if they could constitute a geometry.
For instance, if your only function is reflection across the x-axis, this is not a geometry. Why? Because under that system, a figure is not congruent to itself. (It's only congruent to its reflection.)
But if you add the identity function, so that you have the identity function plus reflection across the x-axis, you have a geometry! You can formally test the properties of an equivalence relation in this case like this:
- Reflexivity - the identify function must be included
- Symmetry - if a function f is included, it must have an inverse, and the inverse must be included.
- Transitivity - if functions f and g are included, the composition of f and g - that is f(g()) - must be included.
Another geometry could include only translations. Does this satisfy?
- Reflexivity: f(z) = z + 0 is a translation and is also the identity function. So that's good.
- Symmetry: if f(z) = z + w is a translation, then f(z) = z - w is its inverse, and is also a translation. Check!
- Transitivity: if f(z) = z + a and g(z) = z + b are translations, then f(g(z))) = z + (b + a) and that's also a translation.
A less mathy way of saying this is to remember that translation means moving things around without rotating or flipping them. Is a figure congruent to itself? Sure - you just move it around not at all. If you can move one figure onto another, then you can surely move the other onto it instead, so it's symmetric. And if you can move figure A onto figure B, and figure B onto figure C, then you could move A onto C by just moving it onto B first, then following B's path to C, so it's transitive.
Note that all of these different geometries have different rules about, essentially, which types of figures are congruent to each other. Fun and games! (Did anyone actually finish this post?)
Tuesday, February 20, 2007
"From Scratch"
Today for lunch, I am eating a Stouffer's frozen dinner - Tuna Noodle Casserole, to be exact. I normally try not to buy frozen meals that do not contain a vegetable, but I suppose the mushrooms and pieces of celery shown on the box momentarily lured me. Also they were on sale.
The back of the box advertises a "Tasty Fact", to wit:
I think this might be one of the funnier things I have ever seen on a frozen food box, and if you eat a lot of frozen food, you know it is a pretty rich genre.
What exactly does it mean for a giant corporate food conglomerate to make pasta "from scratch"? Is there a Stouffer's factory somewhere filled with Italian grandmas rolling out noodles based on a timeless tradition? Or do they just mean that they (Stouffer's, or a wholly owned Stouffer's subsidiary) actually manufacture the pasta used in their frozen foods? And how would this be different, exactly, from buying pasta manufactured by another giant corporate food conglomerate?
Next they'll be telling me the tuna was "fresh caught."
The back of the box advertises a "Tasty Fact", to wit:
At Stouffer's, we feel that making pasta from scratch is worth the extra effort.
I think this might be one of the funnier things I have ever seen on a frozen food box, and if you eat a lot of frozen food, you know it is a pretty rich genre.
What exactly does it mean for a giant corporate food conglomerate to make pasta "from scratch"? Is there a Stouffer's factory somewhere filled with Italian grandmas rolling out noodles based on a timeless tradition? Or do they just mean that they (Stouffer's, or a wholly owned Stouffer's subsidiary) actually manufacture the pasta used in their frozen foods? And how would this be different, exactly, from buying pasta manufactured by another giant corporate food conglomerate?
Next they'll be telling me the tuna was "fresh caught."
Sally's New Blog
If you get tired of checking this blog and having it be empty all the time, or if you just like Sally (!) and want to know what she's up to, please go check out her fabulous new blog, Empirical Question.
A Little Math
One of my courses this semester is Foundations of Geometry, which sounds like it would be easy, but so far has been pretty interesting, and has forced me to be more algebraically clever than usual. (Algebra, in a geometry class? Say it isn't so!)
When you have geometry in high school, it's usually Euclidean geometry, in two senses. The most important way in which it's Euclidean (in my view) is that it uses axioms and proofs to develop geometric ideas. Euclid totally invented this approach to math. Some people (like me) love this and other people (like Mosch) think it's a big waste of time. The secondary sense in which it's Euclidean is that it uses the specific axioms of Euclid. If you change one of Euclid's axioms (the parallel postulate), you can get some different interesting results.
My class is currently proceeding down two lines of work - some straight-up Euclidean stuff, usually presented as puzzles at the beginning of every class period, which we solve and then do some proofs about, and then "analytic" geometry.
Analytic geometry is where you say, "Why is Geometry the only part of math where we're still doing this weird Euclid-type stuff? Let's do everything with algebra and calculus instead!" And so it goes. Our textbook (a slender volume called "Modern Geometries: Non-Euclidean, Projective, and Discrete," by Michael Henle) uses this approach.
In analytic geometry, at least as presented in this course, you represent 2D shapes as coordinates in the complex plane. (This is basically like the regular cartesian plane where you have x, y coordinates, except that in this case the y axis represents the imaginary part of a complex number, so every point in the complex plane is actually just one number of the form x + iy.) Then you use regular math to prove stuff about them.
For instance, one thing you do a lot of in geometry is prove that things are congruent. "Congruent" basically means they are the same size and shape. Euclid's version of congruence is that two shapes are congruent if you can pick one up and lay it on the other and everything lines up. This makes sense, right? If you have two triangles on two pieces of paper, you can literally pick up one sheet, put it over the other, rotate it and move it around, and see if the triangles are the same or different.
In analytic geometry, you prove two things are congruent by proving that there is a one-to-one function (of an allowable type, like a rotation) that takes the set of points contained in one shape and transforms them to the set of points contained in the other shape. This is basically the same thing as what Euclid did, except that it's all algebra instead of being a physical maneuver.
These functions that change one set of points to another set of points are called "transformations" and the ones that Euclid would allow are basically rotation (where you turn something around), reflection (turning the piece of paper upside down, if you had the shapes on paper), and translation, which just means moving things up or down, side to side, or diagonally. If you think about how you'd line up shapes on two pieces of paper, those are the basic moves - you rotate the paper, flip it over, move it around, or some combination of those things. If you can change one shape into another by those types of maneuvers, then the two shapes are congruent.
So...that's about as far into analytic geometry as my class has gotten at this point. I could say more about it, but it would go into weirder math, so I'll refrain :-)
When you have geometry in high school, it's usually Euclidean geometry, in two senses. The most important way in which it's Euclidean (in my view) is that it uses axioms and proofs to develop geometric ideas. Euclid totally invented this approach to math. Some people (like me) love this and other people (like Mosch) think it's a big waste of time. The secondary sense in which it's Euclidean is that it uses the specific axioms of Euclid. If you change one of Euclid's axioms (the parallel postulate), you can get some different interesting results.
My class is currently proceeding down two lines of work - some straight-up Euclidean stuff, usually presented as puzzles at the beginning of every class period, which we solve and then do some proofs about, and then "analytic" geometry.
Analytic geometry is where you say, "Why is Geometry the only part of math where we're still doing this weird Euclid-type stuff? Let's do everything with algebra and calculus instead!" And so it goes. Our textbook (a slender volume called "Modern Geometries: Non-Euclidean, Projective, and Discrete," by Michael Henle) uses this approach.
In analytic geometry, at least as presented in this course, you represent 2D shapes as coordinates in the complex plane. (This is basically like the regular cartesian plane where you have x, y coordinates, except that in this case the y axis represents the imaginary part of a complex number, so every point in the complex plane is actually just one number of the form x + iy.) Then you use regular math to prove stuff about them.
For instance, one thing you do a lot of in geometry is prove that things are congruent. "Congruent" basically means they are the same size and shape. Euclid's version of congruence is that two shapes are congruent if you can pick one up and lay it on the other and everything lines up. This makes sense, right? If you have two triangles on two pieces of paper, you can literally pick up one sheet, put it over the other, rotate it and move it around, and see if the triangles are the same or different.
In analytic geometry, you prove two things are congruent by proving that there is a one-to-one function (of an allowable type, like a rotation) that takes the set of points contained in one shape and transforms them to the set of points contained in the other shape. This is basically the same thing as what Euclid did, except that it's all algebra instead of being a physical maneuver.
These functions that change one set of points to another set of points are called "transformations" and the ones that Euclid would allow are basically rotation (where you turn something around), reflection (turning the piece of paper upside down, if you had the shapes on paper), and translation, which just means moving things up or down, side to side, or diagonally. If you think about how you'd line up shapes on two pieces of paper, those are the basic moves - you rotate the paper, flip it over, move it around, or some combination of those things. If you can change one shape into another by those types of maneuvers, then the two shapes are congruent.
So...that's about as far into analytic geometry as my class has gotten at this point. I could say more about it, but it would go into weirder math, so I'll refrain :-)
Subscribe to:
Posts (Atom)
