Saturday, May 30, 2009
The slightly NSFW part which occurs in the second half is probably the funniest part of this video.
After the hilarity wears off, the viewer is left with the realization that yes, there are an awful lot of people out there who think the Internet is just a series of tubes, and you know what? You still have to be nice to those people.
Tuesday, May 19, 2009
Nick Burns, Your Company's Computer Guy.
Granted, these people seem kind of...befuddled, that's a kind way to describe them. But in the past few years I've gotten accustomed to befuddled, because there are lots of different ways to be befuddled about science and technology. And I have to admit, I've been them, at one time or another, just wanting things to work and not really caring about the underlying technology. They have all my sympathy: it is the stupid email attachment that's stupid, dammit, because everything worked fine before, and the user hasn't done anything differently, and all he wants to do is open his attachment and get on with his overwhelming todo list.
(I should add a disclaimer here: our IT guys at Major Midwestern Supercomputing Center are really fantastic. They're patient, they're respectful, they're sweet and funny and overworked, and they're nothing like this guy. But I've known lots of people who exhibit these characteristics and probably don't realize it, especially when it comes to their nearest and dearest. Our instructor tonight said he once showed this to his wife and said, "This is the worst IT guy in the world!" To which she responded, "He's exactly like you, honey.")
This is now one of the major rules of classroom etiquette in my technical PC maintenance course, which started tonight: that we respect each other and our deficiencies. At any time, someone might call "Nick Burns!" on us.
And with good reason. Some of the other students in my class already have enormous amounts of experience--they're sound engineers, self-taught IT guys, gaming programmers, honorably discharged Army computer specialists. I'm the only woman in the class (so far) and probably, even with my credentials as a technical writer at a major academic supercomputing center, the least experienced of them all. I'm prepared to learn from them as well as from my instructor.
It was a really great class tonight. Tonight I finally learned how to count in binary and hexadecimal and to convert between those two systems and decimal and octal. And then we got into the strange semantic language of logic gates, and I was excited about that too, because I'd had preparation for that twenty-one years before in symbolic logic, during my first semester of college, and I could remember and deploy some of it now.
I can do this. I can do this! I'm excited and looking forward to the next class. For once I almost felt like one of the boys, and not a silly female impostor.
Saturday, May 16, 2009
So, congratulations, my darling. I know it's still sinking in. I love you.
Friday, May 15, 2009
From Girl Genius, a favorite webcomic around here. The timing for today's installment seems...uncannily, almost deliberately apt. Hmmm.
Anyways, happy graduation week to all college instructors and professors out there...I hope you're enjoying a much-needed break before the onslaught of summer classes, travel, research... X certainly will be...
I didn't do as well as I'd hoped, but I survived (mostly) and I'm going back for more.
Some things I learned this semester:
- how to create simple and moderately complex programs in Visual Basic, bash, and C
- how to document my code
- how to work with conditional statements, subroutines, loops, functions, and arrays
- how to use server-side includes in a web page
- how to write (simple) algorithms from scratch
- how to do just about anything in bash
- how to take a PC apart and put it back together
- how to install Ubuntu on a laptop
- How you study and prepare for, and how you're evaluated in computer science courses is very different from how you study and prepare for and are evaluated in humanities classes. This should have been obvious to me, but it wasn't. It's even had me questioning whether, when I was an undergrad with a GPA of 3.8, I was even a very good student, because it seems to me that college wasn't very hard for me at all, that my major just wasn't very challenging. (I suppose that might also be true for a lot of mathematically or technically oriented students who bragged about being able to pass a course without ever cracking a book, but couldn't write their way out of a paper bag.)
- Deeply connected to that first point is that time management was a huge issue for me. Too often, I underestimated how much time it would take to complete an assignment or study for exams--there was a lot of late night panic that probably wouldn't have been necessary had I really been better at gauging the time required.
- I realized that I actually do care about my grades, and that it's OK--more than OK--to care about them. I don't really have a lot of respect for my two prior degrees, because despite a stellar academic record (at least on paper), I don't feel as though they've really gotten me all that far, so I'd kind of given up on caring whether I got A's or not. But it turns out that I do care, actually...and if I ever want to get a graduate degree in computer science at Major Midwestern Engineering School, I will have to care, quite a bit. In any case, I think A's in these classes will actually be more of a measure of achievement than the A's I got for my bachelor's and master's in English. Those grades really only measured how well I could snow my professors with my writing ability. These grades really will measure how well I understand and demonstrate tangible, useful skills.
- I can do this stuff. If it takes me a long time, if I feel like I'm swimming through molasses, it's because I've never done it before, not because I'm stupid. If I keep practicing, I will get better. Most of all, I don't need X or anyone else to hold my hand.
- I really need to restructure my life to accommodate both this and my work. Some things are just going to have to go by the wayside. Meals are going to get a lot simpler. Everyday routines are going to have to be a lot more streamlined. There will be no time for sloth or fussing of any sort. This is not a bad thing. I can see now why the uniform of the programmer/developer/computer scientist is a t-shirt and jeans or, in my husband's case, khakis and oxfords. "I don't have to think about what I'm going to wear," he says, standing before his rack of identical white or blue shirts and beige trousers. But I hope to still be able to bake French bread every once in a while. There should be some pleasure to life, after all.
Wednesday, May 13, 2009
"English," I said, half apologetically. "Completely nontechnical."
"Wow," he said. "You are going to be a stunning programmer someday. Better than a lot of programmers who come from science and math backgrounds."
His reasoning was that with a strong grasp of language, grammar, syntax, and stylistics, I would become very good at it over time...and that I'd be able to do something that programmers from technical backgrounds often didn't--make my code readable, easy to understand and update. "Never mind the math," he said. "You can look it up, learn it later."
I don't know if that happy state of affairs will ever come to pass, but it's encouragement I really needed to hear right now. I am still fighting a tendency to see technology as something that's off limits to someone like me, to see a huge yawning gap between him (a subject matter expert) and me (a mere technical communicator). But when I mentioned the networking course I'd be taking, he said, "That's the kind of course that is a great leveler. You don't need a scientific background to understand networking. You'll be leaps and bounds ahead of people who don't have a formal background in networking."
And maybe it's a bit of a challenge: you will be a stunning programmer someday. An expectation to live up to. In other words: this is something that should, actually, come easily to me. And perhaps, if I force myself to to see it as a potential to reach rather than as a set of odds to beat, it will start to come more easily.
Sunday, May 10, 2009
Currently, I've taken over a tutorial (which is probably less than half complete) for new users on a distributed system of supercomputing resources around the country (currently, we have two such machines here at Major Midwestern Supercomputing Center). Users are mostly scientists from a huge range of disciplines and their undergraduate and grad students, and many are new to scientific computing, so in addition to getting them used to using the user portal, I have to help them get used to working with the UNIX shell.
So right now, as a matter of fact, I'm putting together a section on shells of various kinds that users are likely to encounter at different institutions: mainly, csh, tcsh, and bash. I'm still puzzling over how to explain the differences between the shells in a way that is useful and will make sense. But I'm also working on creating a very basic tutorial on getting around in UNIX, because I've noticed that existing documentation often instructs users to do things like this:
rm -rf directory/subdirectory
If you don't know that rm -rf should be used with caution and type a wrong filename, the results could be disastrous. Oh, and you could accidentally clobber files while trying to redirect output, and make a lot of mischief with tar and other utilities if you don't know what you're doing with them.
Besides, when I don't know a system, cookbook-style instructions, which often seem to communicate, "Just do this, don't ask questions, and everything will be OK," make me feel helpless and disoriented. And the man pages are not really written for novices. I know that I could probably just link to half a dozen Linux tutorials for beginners, and I will anyways, but that also seems like it could be overwhelming, so my plan is to take the commands and utilities I find sprinkled throughout the original documentation and devote a screen or two to each one, just to explain what it does, some of its common options, and what users might want it for later on.
So my coursework is yielding tangible results already. I think the feeling of being a novice user is also helpful and something I want to hold onto for a while--part of the reason such tutorials are necessary is that the original authors of current site documentation are mostly technical experts and seem to have forgotten--or perhaps never known--what it's like to see UNIX and computing in general as a black box.