![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
These notes are either on the progress of the report I was doing yesterday from 7am to 4pm, or on the mini-breakdown I was having while creating it.
Blondie suggests actually talking with the programmers who worked on making $OLD and $NEW talk. Much ♥ for Blondie.
Made filters for Production & Refusals. I shall use those in everything from now on.
Today's attempt will to be to make the thing do logtime, percentage of the $OLD time. The problem is with those people who have like negative something? Maybe? At any rate, I will look into it. And it should be able to replace what goes where by changing the buckets; nothing is going to be hard-coded but the buckets. So we can change the bucket and make things all OK.
And people who are not in $NEW will still have their shiznit all up ins $NEW, so that will be all good, right?
Oh, query to make old break screen time show up in the Non-Productive bucket. Yay bucket.
Other Trendy Chick is singing in the bullpen, parodying a style of song: "I drink a lot and get crazy and smash things!"
Oi, this query is taking toooooooo long to run. I'm going to have to rebuild it all after I know exactly what I am doin… Oh. Right. Wrong kind of join. Dammit.
Woo, I sped up the whole query by making it all interviewers with the stuffs joined so all interviewers and whatever was in those, so things without things will be showing up. And oh damn I need to re-do things for the filter? But sped it up making the joins like a flower not like a chain.
Focusing on making it work first.
Leftover Leftovers Guy came in wearing a muscle shirt. Now that interviewers are here, he is in his $WORKPLACE shirt. He feels "accentuated" by the fit of the shirt.
Now I am looking at the differences in the logtimes that could happen according to the way I understand things work. I could see an $OLD time being less than a $NEW time, just because I do not think the passing is perfect.
About half the differences there are a few minutes less. I am not worried about a few minutes less. Some of them are up to nine hours less – but, um, that is not much compared to like 70 hours more. So I am inclined to think that it works better this way.
Had nice rousing conversation in break room over breakfast with Leftover Leftovers Guy and Other Trendy Chick about Cartoons These Days; I mentioned Happy Tree Friends.
Looking at PivotCharts to see if those will give me any insight about stuff.
( Fig. 1 )
… yeah, I'll say that shows up what is going on quite nicely! Though how it is happening, I am not so clear. But! It is not a coincidence! Yay PivotChart!
I have stared at it until I am blue in the eyes. But I am still not getting how. I made a version that shows the negative discrepancies, and those are really not showing up in a pattern like that. Those little jogs between 0 and 24 show up at 12 and 16 hours, roughly… it really does jump out. So glad I am used to looking for patterns.
Now what it seems to correlate very well with is logtime percentage. Right?
Annnnnnd it looks like the people with screamingly blatantly unacceptable $OLD logtimes (on aver……. Oh jesus I need to see what job the ratios are worst on. )
So. Discrepancy goes hand in hand with bad logtime. Right.
…omgwtf. Attempted to calculate logtime my damn self to see if it lined up. And there's where I found it. Somehow, $OLD is pulling logtimes out of its ass, because the following should add:
Logged onfiltered= Phone Time + Menu Time + Break Time.
It does not. Not in the slightest. Phone % + Menu % = Total %, but there is no corresponding "other %" – and damme if the people with way out of wack calculated-by-me logtimes do not have mad discrepancy between $NEW and $OLD times.
Dear self: "what the cheese!" is not a valid or informative query name. "what the cheese" without the exclamation point is valid, but hardly informative. "Logtime: what the cheese" is slightly more informative, but not much.
Love, the geek with naming standards
…omfg wrong. I did the wrong thing. I'm glad I found out where the hell I was coming from, because I am an idiot to have done the wrong thing. Ooops. Bad loonie. No biscuit.
What I did, was do (phone time + break time) / total = log time. No.
(Phone time + menu time) / total = log time. Idiot loonie.
Also, gum is good for programming because gum is something in the mouth to be chewing on: something that is not food, for the damned oral fixation, which I probably cultivated but it is so real.
So let's go work on log time again. I have enough confidence in the 3 month that I can probably bang it out really quickly, and shove in a report. So I am not worried about that. Give me a day's notice and I can do it. But I really want the log time, because that is a major part of infrastructure.
To ask someone like the Guru: how do people get more $OLD log time than they have logged hours? Phone hours + Menu Hours > Logged in hours. Usually, Phone Hours + Menu Hours =< Logged in hours.
Now we're cooking with gas. I'm going to see how people are doing if their log time is calculated with $NEW assumed to be right. Oi!
I don't get this. This fame thing. I don't get it. …In other words, SOME of the people with lousy log time have st00pid hy00ge discrepancies, and some do not. I do not discern a pattern. So far, I have not found the science. (and the numbers keep on circling me.)
…and evidently this machine is not made to do heavy math. Dammit. And this is one of the new boxen.
( Fig. 2 )
This here demonstrates that the people with logtime percents closest to 100 do not have a significant number of lost hours, and most importantly, that lost hours and low log time percentage and $NEW/$OLD lost hours go all together.
…and it also looks like the creamer they have back there is dairy. Side effects ftl.
But I'm already looking at logtime.
( Fig. 3 )
OK, looks now like number of hours lost is pretty random vs. log time.
Before I go completely wacknuts (I have gone, and have since emerged out the other side) I am going to package up the raw-ish data and send it off to somebody and then attempt to do some other stuff while I can still, like, think.
Blondie suggests actually talking with the programmers who worked on making $OLD and $NEW talk. Much ♥ for Blondie.
Made filters for Production & Refusals. I shall use those in everything from now on.
Today's attempt will to be to make the thing do logtime, percentage of the $OLD time. The problem is with those people who have like negative something? Maybe? At any rate, I will look into it. And it should be able to replace what goes where by changing the buckets; nothing is going to be hard-coded but the buckets. So we can change the bucket and make things all OK.
And people who are not in $NEW will still have their shiznit all up ins $NEW, so that will be all good, right?
Oh, query to make old break screen time show up in the Non-Productive bucket. Yay bucket.
Other Trendy Chick is singing in the bullpen, parodying a style of song: "I drink a lot and get crazy and smash things!"
Oi, this query is taking toooooooo long to run. I'm going to have to rebuild it all after I know exactly what I am doin… Oh. Right. Wrong kind of join. Dammit.
Woo, I sped up the whole query by making it all interviewers with the stuffs joined so all interviewers and whatever was in those, so things without things will be showing up. And oh damn I need to re-do things for the filter? But sped it up making the joins like a flower not like a chain.
Focusing on making it work first.
Leftover Leftovers Guy came in wearing a muscle shirt. Now that interviewers are here, he is in his $WORKPLACE shirt. He feels "accentuated" by the fit of the shirt.
Now I am looking at the differences in the logtimes that could happen according to the way I understand things work. I could see an $OLD time being less than a $NEW time, just because I do not think the passing is perfect.
About half the differences there are a few minutes less. I am not worried about a few minutes less. Some of them are up to nine hours less – but, um, that is not much compared to like 70 hours more. So I am inclined to think that it works better this way.
Had nice rousing conversation in break room over breakfast with Leftover Leftovers Guy and Other Trendy Chick about Cartoons These Days; I mentioned Happy Tree Friends.
Looking at PivotCharts to see if those will give me any insight about stuff.
( Fig. 1 )
… yeah, I'll say that shows up what is going on quite nicely! Though how it is happening, I am not so clear. But! It is not a coincidence! Yay PivotChart!
I have stared at it until I am blue in the eyes. But I am still not getting how. I made a version that shows the negative discrepancies, and those are really not showing up in a pattern like that. Those little jogs between 0 and 24 show up at 12 and 16 hours, roughly… it really does jump out. So glad I am used to looking for patterns.
Now what it seems to correlate very well with is logtime percentage. Right?
Annnnnnd it looks like the people with screamingly blatantly unacceptable $OLD logtimes (on aver……. Oh jesus I need to see what job the ratios are worst on. )
So. Discrepancy goes hand in hand with bad logtime. Right.
…omgwtf. Attempted to calculate logtime my damn self to see if it lined up. And there's where I found it. Somehow, $OLD is pulling logtimes out of its ass, because the following should add:
Logged onfiltered= Phone Time + Menu Time + Break Time.
It does not. Not in the slightest. Phone % + Menu % = Total %, but there is no corresponding "other %" – and damme if the people with way out of wack calculated-by-me logtimes do not have mad discrepancy between $NEW and $OLD times.
Dear self: "what the cheese!" is not a valid or informative query name. "what the cheese" without the exclamation point is valid, but hardly informative. "Logtime: what the cheese" is slightly more informative, but not much.
Love, the geek with naming standards
…omfg wrong. I did the wrong thing. I'm glad I found out where the hell I was coming from, because I am an idiot to have done the wrong thing. Ooops. Bad loonie. No biscuit.
What I did, was do (phone time + break time) / total = log time. No.
(Phone time + menu time) / total = log time. Idiot loonie.
Also, gum is good for programming because gum is something in the mouth to be chewing on: something that is not food, for the damned oral fixation, which I probably cultivated but it is so real.
So let's go work on log time again. I have enough confidence in the 3 month that I can probably bang it out really quickly, and shove in a report. So I am not worried about that. Give me a day's notice and I can do it. But I really want the log time, because that is a major part of infrastructure.
To ask someone like the Guru: how do people get more $OLD log time than they have logged hours? Phone hours + Menu Hours > Logged in hours. Usually, Phone Hours + Menu Hours =< Logged in hours.
Now we're cooking with gas. I'm going to see how people are doing if their log time is calculated with $NEW assumed to be right. Oi!
I don't get this. This fame thing. I don't get it. …In other words, SOME of the people with lousy log time have st00pid hy00ge discrepancies, and some do not. I do not discern a pattern. So far, I have not found the science. (and the numbers keep on circling me.)
…and evidently this machine is not made to do heavy math. Dammit. And this is one of the new boxen.
( Fig. 2 )
This here demonstrates that the people with logtime percents closest to 100 do not have a significant number of lost hours, and most importantly, that lost hours and low log time percentage and $NEW/$OLD lost hours go all together.
…and it also looks like the creamer they have back there is dairy. Side effects ftl.
But I'm already looking at logtime.
( Fig. 3 )
OK, looks now like number of hours lost is pretty random vs. log time.
Before I go completely wacknuts (I have gone, and have since emerged out the other side) I am going to package up the raw-ish data and send it off to somebody and then attempt to do some other stuff while I can still, like, think.
