So far it has been customary to start out each post with an apology, so I see no reason not to continue the tradition. It has been far too long since the last post. I'm sorry. I get home and my brain feels like cottage cheese. Excuses, excuses.
Moving on, a few words on what I do:
For those of you outside of the tech industry, I should mention that "Software Engineer" is a much vaguer job description than many might realize. Often, it is code for "low level programmer." I mention this because I don't want to falsely come off as a big cs kind of gal, and I am frustrated about how no one questions me when I say software engineer, but I have to justify my position when I describe myself as a cartographer (which, provided you know what it is, a relatively specific calling). Anyway, in quality assurance, I am in better straits than some programmer-monkey, but to be honest, most of the time a monkey could do my job.
Before a software program goes out, it has to be tested. Not in a fun Grandma's Boy sort of way, but rather an excruciatingly regimented process. It involves going through every possible action, methodically, to make sure that there isn't a single bug in the software. Of course, every time new code is added, more testing has to be done. This happens a lot, be it by adding new features to the new version or trying to make a relatively young (think less than five years) program more stable. The world of software is held together by a fragile web of interlocking code, so a solution to one problem can easily become the root of another. I don't do code (too stupid and lazy).
No, I am not a developer, but a tester, the grinding force wearing down the ground behind their heels, pointing out their mistakes. It's really an unpleasant concept. The specifics of that though, I'll save for another day.
What I wanted to talk about this evening was the other task with which I occupy myself.
When testing, you have to not only test what has already been written, but create materials against which the machine can be tested. QA is about adding the human element into the mechanical process, finding the errors that the machine could never find. The company I work for makes photogrammetry software, tools for analyzing aerial images. A lot of this stuff is still more accurate when done by hand, but since it takes hours, the move to automation in the industry has been fast and hard. Right now, one of the developers I work with is trying to write a program that will make a lot higher quality terrain models. To measure quality though, it is necessary have baseline data against which to compare the results.
For the past week, I've spent every day staring at stereo imagery, putting points on the ground of a simulated 3D picture. Beyond it feeling like my eyes are crossing a little more permanently every day, it's actually pretty interesting. The setup I have uses quad-buffered stereo viewing, where the left and right images are put on top of each other and blink really quickly, while I wear
shutter glasses (also blinky), the combination of which (in theory) leads to a crisp looking 3D image on the screen. Then, by adjusting the parallax (distance between the two images), you can move your cursor above, below, or, preferably,
on the ground. This method replaces the old way, involving two projectors in a machine, from what I hear, the size of an old Volkswagen. Nevertheless it takes hours and hours to do. Amazing when you think that within my tenure there I could get comparable results from just pushing a few buttons.
Also, you should all probably read this:
