Thursday

Yes, it’s crunch time again (still).

This means that Julio first calls everyone in the morning to waste their time for an hour or two, then he arrives late, and, in a furious blitz of disordered hyperactivity, manages to grind all previous productivity to a complete halt for the afternoon while simultaneously rendering obsolete any work done in the morning and changing everyone’s priorities. In the process, he lectures about initializing variables and programming techniques. (*laf*). Then, when he’s wasted everyone’s time for almost the entire day, he starts subtly feeling out who is willing to stay late or work weekends because the workshop is just around the corner and we really need to get this stuff done and “out the door.”

Ah well, I’m sure tomorrow will be better. Maybe someone will bring a gun so I can shoot myself.

Bruce Hornsby

Cynthia and I went to see Bruce Hornsby at the Carpenter Center (otherwise known as, the Theater Amid Massive Destruction) Saturday night. It was quite cool. Except for the drunk women beside us screaming “woooooooo” during every quiet moment of every song. His band was awesome. The poor guy on guitar had to keep switching from electric to acoustic to mandolin on practically every song in the second set, though. I think the other guy on guitar was a relative of Bruce because he was introduced as “something” Hornsby, and, well, frankly he wasn’t that good, and I thought he got an inordinate amount of solo time. Anyway, I was impressed with the way Bruce directed the band, and he shared a lot of playing time with other band members.

Friday, Part 2

I had planned to write long saga about Friday, but now it’s Sunday night and I don’t really want to think about it anymore. So this is an abbreviated rendition.

When last we left our story, the BEAVA test specificity was coming up at 12% using the new computations Julio requested earlier in the week.

Needless to say, Julio freaked out. He had expected the specificity result to be about the same (actually so had I), having convinced himself that his computational changes would have a negligable impact on the test results. (In fact, I had observed that while most of the time the impact was negligable, sometimes the impact was quite dramatic.)

The next seven hours of my life consisted of a concentrated assault of non-stop Julio-style problem solving.*

At first, I thought there was a major bug in my code, so I didn’t complain about staying late to try to fix it. (I hate unfixed bugs. That being said, however, had Julio not been standing right there, I would have simply made a note of it to work on first thing Monday morning.) As time wore on, however, I began to suspect that the problem was probably not in my code at all, but rather that Julio’s computational changes had had a much more pronounced effect than he anticipated.

Were I to have suggested such a thing to him without quantifiable proof, he would probably have scoffed. Julio hardly ever takes anybody else’s word on anything related to statistics. (He has a PhD, after all.) So I was stuck until Julio ruled out every other possible explanation for the change in specificity (that is, until he ruled out the possibility that I had fucked up somewhere).

First, we checked the code that generated the specificity statistics. No problems found.

Then, just to make sure, we ran the statistics using the computations from the last version of BEAVA to see if we still got 10.47%. We did. This categorically ruled out any problems in the calculation of the specificity, which meant the problem had to be in the new score computations.

Julio, of course, assumed the problem must have been with my calculations, and not with his changes. A long ordeal of double-checking my calculations ensued. No problems were found.

At one point, Julio found that I had expressed normative error data as a percentage of correct responses instead of a number of errors. I chose to use this method based on his kevetching several months earlier about my expressing normative data as a number of errors instead of a percentage. This time, Julio declared that I should NOT have used a percentage and should have used the number of errors. Julio was convinced this was the cause of the problem. After a long time of recalculating the normative tables, there was no appreciable difference in the specificity outcome.

We spent an enormous amount of time comparing my computer-calculated numbers to Julio’s hand-calculated numbers. Any differences were examined in excruciately close detail. He found that certain numbers did not match up no matter how he checked them.

Some hours later, close to midnight, in fact, Julio declared that the reason the numbers didn’t match was because of my calculation of the normative data. (I have used these same calculations for the past six versions of BEAVA without any problems.) He insisted I fix this problem Monday. I shall do so diligently, and ensure that whenever he is looking over my shoulder that I use the “fixed” code, whilst continuing to use the CORRECT code behind his back. In any case, that “problem” was completely unrelated to the specificity problem.

In the end, Julio resigned himself to the fact that the specificity had indeed gone up because of his new computations. This realization took seven hours to reach.

I expect to receive a phone call from Julio Monday morning around 9:30-10:00, where I will have to rehash everything we did Friday night. Most likely, this conversation will take place when the Merry Maid people are running the vacuum cleaner in my ear.

* Julio-style problem solving involves a great deal of panic, thinking out loud, talking to himself, walking back and forth, ridiculously unfounded assumptions, blaming everyone but himself, jumping to conclusions, and talking in gibberish.

Friday, Part 1

It may be useful to deconstruct the events of this past Friday, in the event that I should suddenly go on a murderous rampage at my place of employment sometime in the coming weeks.

Friday started for me at about 8:30, as it does every weekday. I agreed to work on this particular Friday because we are in a “crunch” trying to prepare for a workshop in the first week of November. I arrived at work with very little to do except wait for Julio to dictate some text to me so that we could declare this version of the, ah, let’s call it, BEAVA program finished. I had been waiting for him to dictate this text since I arrived at work Thursday morning. He assured me at the end of the day Thursday that he would be in Friday morning to dictate this text. (I remember commenting to a co-worker, “I’ll believe that when I see it.”)

Having nothing to do, I began to work on tying up loose ends, polishing up comments, cleaning up directories, setting up todo lists, and all the various little things that mark the end of one project and the preparation for the start of the next project. (This was nice, actually, because I am rarely afforded the luxery of being able to do these things.)

The other programmer at Gulag 727 commented to me that he also had nothing to do, since he was waiting for some wav files to be recorded and some testing to be done. Since he had already worked 50 hours during the week, he commented that he might just go home and if Julio said anything about it he would tell him to, and I quote, “suck it.”

Julio called me from home at around 10:30, sounding like he had just gotten out of bed. This has become a regular habit for him in the past few weeks. Typically these phone calls start with his declaration that he is “just checking in,” which is usually followed by the question, “where are we at?” This is Julio-lingo, and can only be used by qualified PhD-holders. Roughly translated, it means, “I have absolutely no idea what is going on at my own company and I can’t remember anything that we were working on less than 24 hours ago, so can you please bring me up to speed so I can then tell you the best way to continue your work?”

These phone calls might have some mild purpose if they occurred at 8:30, but since they usually occur at 10:00, you can probably imagine that by that time I have already figured out on my own what I’m going to be doing for the day and am well on my way to doing it, and really don’t need any guidance. In fact, more often than not, I have already determined what I will be doing on a given day at the end of the previous day.

But I digress.

On this day, Julio’s phone conversation will have nothing to do with anything that we’re working on. He commenced explaining to me what we will be doing with BEAVA and related products over the course of the next year. This took a long time, seeming an hour but probably more like 30-45 minutes. He concluded by saying he would be in to dictate the text I needed, then asked to be transferred to someone else.

About an hour later, I saw that he was still talking to other people at the office. I think it was around 12:15 that he finally got off the phone.

I then learned that he was scheduled to see a patient at 3:00. I recall commenting that he would probably not get around to dictating any text to me until 4:30 or so.

The day continued to pass fairly uneventfully. I started working on coding that would have to be done for the next project.

Julio arrived about 2:45. He did not dictate any text to me before seeing his patient at 3:00.

After seeing his patient, he started making noises about working with me about 4:10. He came into my cubicle a number of times and then left again. It was not until about 4:50 that he actually sat down in a chair long enough to start working with me.

Did he dictate any text?

Nope.

For this version of the BEAVA test, Julio had requested changes in the computation of two of the scores the test reports. BEAVA is a test designed to look for the presense of, let’s say, buck teeth, in the test subject. The determination of whether the test subject has buck teeth or not is based on examining the values of a number of key test scores. Now, the test is supposed to have a “specificity” of 10%, which basically means it is only supposed to be wrong 10% of the time. (This is apparently good in the testing world.) Prior to the changes Julio requested, the BEAVA test had a specificity of 10.47%. Julio had been happy with that. It meant that his test was scientifically credible and not a complete farce.

So when Julio sat down at 4:50, he wanted me to recalculate the specificity of the test based on new computations, just to make sure his new calculations didn’t “throw anything off.” Wondering why he hadn’t asked for this several days ago when he told me to change the computations, I started generating the statistics he wanted. This takes a minute or so.

My heart sank when I saw the test now had a specificity of close to 12%. This was going to be a problem. This was going to be a MAJOR problem. And here it was 5:00 on a Friday.

Surprise!

You may be surprised to note that uvtek.net is still in the same place. (You may not have noted this at all, but it’s true.) That’s because I decided it would be better to wait until around November 1 to move the server, because it’s already been paid through the end of November. That way, if there are any problems on the new server, I can switch it back to the old server within the 30-day money-back-guarantee period.