Feb. 7th, 2018

randomdreams: riding up mini slickrock (Default)
I dreamed I was working for a circuit board fabrication company. The president was Darth Vader. The director of HR was Princess Leia. DV kept hiring jerks who would sexually harass Leia, and then she'd fire them and yell at DV, who would hold his helmeted head in his hands.
I was doing board layout. We had this meter-by-two-meter sheet of glass, and I'd draw the individual conducting traces onto the glass, by dipping my fingertip in a vase that looked like a volumetric flask, filled full of glycerine and aluminum powder, and as I traced across the glass it would (if I remembered to turn the power on) draw a perfect thin straight conductive trace. If I forgot, it would just be this big smudgy shiny grease smear. We had a board that was bigger than the glass, so we clamped a book on one side and I drew over onto the book, but the trace wouldn't attach across the boundary. The entire company was housed in a semi-abandoned summer camp, and I personally worked in a giant barn with no walls (and birds flying around in it) so every time the wind came up, which seemed to be constantly, it would blow all my design notes away. There were big canopies I could pull down on the sides to shelter it somewhat but it took two people and every time I went looking for someone to help me all I found was Leia yelling at DV.
randomdreams: riding up mini slickrock (Default)
A big chunk of my job right now is designing hardware and software to run automated testing on components: control piles of power sources, oscilloscopes, voltmeters, to characterize our components. 30 years ago the way people did this was with individual measurement instruments, the size of a couple of stacked textbooks, with displays and controls: the stuff you see in the background of any good movie that has an obligatory laboratory scene.
What everyone actually uses these days is a single big box full of cards, each card duplicating the function of one or several of those instruments. They are blazingly fast, easy to program, and cost as much as a reasonably nice new car, which is why we don't have one. This isn't just cheapness: anyone can use a discrete measurement instrument. Only people with the fancy software and experience can use the instruments in an instrument chassis. So you're paying a *lot* of money for a piece of equipment that 95% of the engineers in the building can't use.
Hewlett Packard, then Agilent, then Keysight, built this thing that is somewhere in between the two: it's a big box with a card rack and a fair chunk of intelligence. My manager found three of them in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.” He came to the wistfully optimistic conclusion that this was a compromise position that allowed us flexibility and saved piles of money.
Actor two in this drama is my coworker. You know how there are people who love a challenge, learning something new or figuring out how to get something to work? And there are people who aren't really so into that? Well, whatever the opposite of someone who loves a challenge is, that's my coworker. He passionately loathes new things and challenges. He doesn't think he does, and in fact he says the opposite, but wowie. Every time he has to work with a new piece of equipment he starts chewing gum as loudly and quickly as he can and has severe restless leg syndrome and sometimes gets facial tics. He really hates it.
So the way we have worked this out in the past is my manager hands the new thing to me, I go tickle it until it sings, I write a bunch of more or less black-box functions, with descriptions, and I had it to my coworker and say "you call this with these variables and it will return what you need." Every once in a while he tries to look into what I did, and how it works, and immediately closes the code window and goes back to using it as a black box.

So, over the last six to eight months, I've been, when time permits, playing with these big quasi-chassis instrumentation systems, and through careful reading of the literature about them and writing lots of routines that exercise bits of them, I've been finding more and more ways in which they don't actually do what we want. (The cards that go in them are proprietary, and quite limited in functionality, for instance, so they aren't really any sort of bridge between The Old Way and The New Way. They are in fact The Inconvenient Way, but we're firmly in the fallacy of sunk costs here.) They do some very interesting things, that could be really nice, if their basic functionality matched what we need.

Here's the problem. Our corporate technical support wrote a bunch of programs that are supposed to work on this hardware, but they clearly didn't have access to the hardware to test it: they wrote it based on the literature description, and there are minor syntax errors that prevent almost any of their subroutines from working. Mine do, because I hate using their programs, because they don't work. I write stuff that handles and uses the raw text communication, rather than layers of nested error-handling structures. Their programs are beautiful, generalist, have drop-down menus to select everything, and don't work. My programs require having the programmer reference guide open next to me as I concatenate individual commands and chuck them at the instrument and then query it to make sure it got what I wrote and behaved the way I wanted to.

My coworker doesn't want anything to do with the new instrumentation, but can at least run some of the corporate-supplied fancy subroutines. When they don't work, though, he's lost. My manager understands some of how the language and interface works, but lacks any skill in using the software interface, and he's very, very literal. The command language has a lot of optional text in it, and the corporate interfaces do a poor job of consistent usage. "[CONFigure]:MEASure:[VOLts]:[DC]:RANG {x}", for instance, means that you can but don't have to use either "conf" or "configure", but you do have to use either "meas" or "measure", but "vol" or "volts" are also optional, and so forth, and sometimes the corporate stuff is all MEAS:RANG 10 and sometimes it's all configure:measure:volts:dc:range 10, and my manager, when trying to debug something, gets all wound up on why 'configure' is missing or why the output of one function says something different than the output of another one, even though they both do the same thing.

Today the two of them spent almost the entire day arguing with each other, with me in the middle, paging through the programmer reference guide and trying to, on the fly, assess whether the syntax of problem functions was correct or not. I wrote some fancy debugging tools that neither of them trust, but with them, I could convince the instrumentation to do everything I wanted to, including duplicating things that neither of them could get it to do. The problem is that none of us really understand why a stream of data that looks exactly the same to all of us works when it comes out of my function, and doesn't work when it comes out of the corporate-supplied function.

It was kind of a headache-inducing day.

It's easier to deal with my headstrong, impatient, borderline abusive boss, because when I keep providing good answers and making things work, he stops yelling and starts thinking, and then we make progress. My coworker just sits there clutching his head, sighing really loudly, and saying "this is a nightmare, a nightmare!" and predicting doom and futility.

But at least as of today my manager is finally convinced that these things are a dead end, and we're going to have to upgrade to the fancy stuff at some point, although it did take someone elsewhere in the company telling him that rather loudly to get him to that point.

Profile

randomdreams: riding up mini slickrock (Default)
randomdreams

April 2020

S M T W T F S
   12 34
567891011
12131415161718
19202122232425
2627282930  

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 17th, 2025 08:34 am
Powered by Dreamwidth Studios