![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Thursday, March 28th, 2013 09:24 pm
there are many ducklings in the office
This post was going to begin with something work related, but then as I was getting ready to type, I realized that I didn't--technically--know all the types of metaphors, and also, this leads to a fan moment IRL.
Specifically, Common Types of Metaphors, which I feel needs a new category; specifically, metaphors using common metaphors from pop culture. So I can cite this at some point to people who have never seen House and I can feel smug, instead of uncomfortably aware these people really don't watch enough TV, when I say, "That is my new duckling!" at work.
Per usual, it took me several seconds to realize their expressions indicated they were looking for infant fowl, not y'know, one of the new testers.
So someone get on that, please. Metaphor that depends on a metaphor and the circumstances surrounding its use in pop culture. I like 'pop metaphor'.
Also, I have a duckling! Due to my lead being--herself. and I love her--I was assigned one of the ten new sort-of-temp-testers, if you can call a minimum year and a half contract temp. They were hired and paid for by our vendor but work with us, which leads to about half of us assuming we're training them to take our jobs, which is possible but woudl increase the suicide rate by ten people if they expect ten testers to do the work of almost forty and who they were hired specifically to supplement.
So I--and the other ten testers with our ducklings--introduced them around and made much of them and currently Duckling is on a donut reward system of the future, as while I do not have donuts now and cannot guarantee when they appear, the number he receives depends on his good behavior. He's like, three negative donuts right now, and in addition, I will deliberately feed all the other ducklings donuts in front of him if he goes on like this, which I suppose means we have a pretty good working relationship.
Also, and I do not say this lightly, I got one of the best ducklings. Another one--not mine--I worked with was methodical to the point of insanity, and didn't seem to hear me telling him anything unless he had a question and agreed with my answer after a lot of thought. Mine is bright, willing, sarcastic as fuck (we bonded) and to my growing interest, is already developing a testing style of his own, which I approve of a lot. One of the bigger mistakes is to either a.) take your mentor-type-person's--your Duck Hen, if you will, though no, I'm not using that so that's the last time I'll say it--style as your own with slavish devotion and repeat all their mistakes or not know why some of it you do, or b.) take up the idea of Best Practices like you plan to start a cult and recruit followers.
Things I have learned about Best Practices when used as a battering ram:
1.) They can be really goddamn impractical to the point of death by paperclip from sheer annoyance, because I only have one good blue pen and dude, I'm not losing it now.
2.) They can be general to the point of meaninglessness in which you may or may not have an existential crisis in your cubicle.
3.) They quite literally sometimes don't apply and stop talking about them.
It's not an issue yet, but it's slowly growing as a thing to aspire to, which in the general I have no objection because some things work and that's why it's called best practices. Mostly because when I hear it cited, it's on the order of entering a particularly fundamentalist church--you both see the same statement, but honest to God, how are you reading it like that and why. In testing for a program in the public sector--say, welfare et al--there are some very major differences as compared to say, Amazon or Best Buy that don't really translate well, and it's very, very hard to get that across.
(Also, trying to explain that the federal agriculture department is the equivalent of the illuminati is difficult, because well, agriculture. People don't get the power of farmers in the US.)
It's also been interesting to explain specific tester strategies we use for something things, because it's very, very difficult to get across this in a way that doesn't sound like we're fucking with developers: sometimes, even if you know the problem, you don't tell them. There are historical defect-related reasons why this is a bad idea, not least of which is a.) you could be wrong (rare, as in, it's rare we do know, but when we do, we're right), b.) developers are under the impression testers are not so bright and will not only ignore you, but assume your defect is also nonsense, or c.) this is very, very complicated, but generally, it really slows things down if it's something that intersects code and public policy because--and this is where it gets odd--how you explain it to them is not how they read it at the best of times, and that goes both ways.
It is also a matter of documentation in general, which I'll get to.
Which is why with two of the new testers I explained the one line rule--developers skim and will only take in that first line, so make sure it gets the right kind of attention--and the minimal information rule to be used sparingly. Specifically, there was a line of instructions that vanished from one of the pages that was kind of critical in understanding sizes when uploading a document, and so I had my tester deliberately upload a file I knew was too large because that line wasn't there and had them defect it while citing the current text on the page.
Now, note: I do know the file size you're supposed to use, and I told Duckling, but I specifically said also no matter what not to mention it even once until they realized it, at which time when they told us the file limit size, we say that needs to be in the instructions. Because secret d.) developers occasionally really prefer to figure this out themselves because this could be an internal matter with them and if they hunt it, they can find out how the problem occurred and when; if I tell them, sometimes we'll never know how or why it occurred, or even when, and that can be kind of the end game.
This isn't a bug, it's a feature--if you know the solution, just implement it, and most of the time, that's not an issue except the times when it really is. However, when working with benefits for the most vulnerable people in the state, tiny really strange and unexpectedly new problems are still problems and they are almost never just one but comes as a group of tiny problems that all occurred during a careless baseline deployment in our environment--maybe near the very end of testing--where we'd already tested X sixteen times and cleared it so didn't know we needed to do it again. Or example, a baseline that was deployed across all environments but production and--thankfully--ours that kind of was massive server errors everywhere, including in dev, where the base code lives.
Also, it takes a certain level of credibility and willingness to die on that hill to tell developers they're wrong and you're right, which is why when I do it, I do it in essay format with documentation, because if in general they know that the only times I will have a footnote section attached is I am that damn sure, the ones I can't do that with are more likely to be treated with benefit of the doubt.
The ducklings are learning. Luckily, they're learning from all of us, so I can't bend Duckling's mind too badly, though apparently we're in some kind of competition and he's recruiting the other testers to come to me for help under the thinly veiled excuse I'll answer questions, hence he's at negative three donuts--he was at six, but then we kind of ruined a wall in the tiny tiny former closet now double office two of them are in to set up their whiteboard and so being partners in crime, well, we kind of depend on each other for denial related purposes.
I have a very awesome duckling.
Specifically, Common Types of Metaphors, which I feel needs a new category; specifically, metaphors using common metaphors from pop culture. So I can cite this at some point to people who have never seen House and I can feel smug, instead of uncomfortably aware these people really don't watch enough TV, when I say, "That is my new duckling!" at work.
Per usual, it took me several seconds to realize their expressions indicated they were looking for infant fowl, not y'know, one of the new testers.
So someone get on that, please. Metaphor that depends on a metaphor and the circumstances surrounding its use in pop culture. I like 'pop metaphor'.
Also, I have a duckling! Due to my lead being--herself. and I love her--I was assigned one of the ten new sort-of-temp-testers, if you can call a minimum year and a half contract temp. They were hired and paid for by our vendor but work with us, which leads to about half of us assuming we're training them to take our jobs, which is possible but woudl increase the suicide rate by ten people if they expect ten testers to do the work of almost forty and who they were hired specifically to supplement.
So I--and the other ten testers with our ducklings--introduced them around and made much of them and currently Duckling is on a donut reward system of the future, as while I do not have donuts now and cannot guarantee when they appear, the number he receives depends on his good behavior. He's like, three negative donuts right now, and in addition, I will deliberately feed all the other ducklings donuts in front of him if he goes on like this, which I suppose means we have a pretty good working relationship.
Also, and I do not say this lightly, I got one of the best ducklings. Another one--not mine--I worked with was methodical to the point of insanity, and didn't seem to hear me telling him anything unless he had a question and agreed with my answer after a lot of thought. Mine is bright, willing, sarcastic as fuck (we bonded) and to my growing interest, is already developing a testing style of his own, which I approve of a lot. One of the bigger mistakes is to either a.) take your mentor-type-person's--your Duck Hen, if you will, though no, I'm not using that so that's the last time I'll say it--style as your own with slavish devotion and repeat all their mistakes or not know why some of it you do, or b.) take up the idea of Best Practices like you plan to start a cult and recruit followers.
Things I have learned about Best Practices when used as a battering ram:
1.) They can be really goddamn impractical to the point of death by paperclip from sheer annoyance, because I only have one good blue pen and dude, I'm not losing it now.
2.) They can be general to the point of meaninglessness in which you may or may not have an existential crisis in your cubicle.
3.) They quite literally sometimes don't apply and stop talking about them.
It's not an issue yet, but it's slowly growing as a thing to aspire to, which in the general I have no objection because some things work and that's why it's called best practices. Mostly because when I hear it cited, it's on the order of entering a particularly fundamentalist church--you both see the same statement, but honest to God, how are you reading it like that and why. In testing for a program in the public sector--say, welfare et al--there are some very major differences as compared to say, Amazon or Best Buy that don't really translate well, and it's very, very hard to get that across.
(Also, trying to explain that the federal agriculture department is the equivalent of the illuminati is difficult, because well, agriculture. People don't get the power of farmers in the US.)
It's also been interesting to explain specific tester strategies we use for something things, because it's very, very difficult to get across this in a way that doesn't sound like we're fucking with developers: sometimes, even if you know the problem, you don't tell them. There are historical defect-related reasons why this is a bad idea, not least of which is a.) you could be wrong (rare, as in, it's rare we do know, but when we do, we're right), b.) developers are under the impression testers are not so bright and will not only ignore you, but assume your defect is also nonsense, or c.) this is very, very complicated, but generally, it really slows things down if it's something that intersects code and public policy because--and this is where it gets odd--how you explain it to them is not how they read it at the best of times, and that goes both ways.
It is also a matter of documentation in general, which I'll get to.
Which is why with two of the new testers I explained the one line rule--developers skim and will only take in that first line, so make sure it gets the right kind of attention--and the minimal information rule to be used sparingly. Specifically, there was a line of instructions that vanished from one of the pages that was kind of critical in understanding sizes when uploading a document, and so I had my tester deliberately upload a file I knew was too large because that line wasn't there and had them defect it while citing the current text on the page.
Now, note: I do know the file size you're supposed to use, and I told Duckling, but I specifically said also no matter what not to mention it even once until they realized it, at which time when they told us the file limit size, we say that needs to be in the instructions. Because secret d.) developers occasionally really prefer to figure this out themselves because this could be an internal matter with them and if they hunt it, they can find out how the problem occurred and when; if I tell them, sometimes we'll never know how or why it occurred, or even when, and that can be kind of the end game.
This isn't a bug, it's a feature--if you know the solution, just implement it, and most of the time, that's not an issue except the times when it really is. However, when working with benefits for the most vulnerable people in the state, tiny really strange and unexpectedly new problems are still problems and they are almost never just one but comes as a group of tiny problems that all occurred during a careless baseline deployment in our environment--maybe near the very end of testing--where we'd already tested X sixteen times and cleared it so didn't know we needed to do it again. Or example, a baseline that was deployed across all environments but production and--thankfully--ours that kind of was massive server errors everywhere, including in dev, where the base code lives.
Also, it takes a certain level of credibility and willingness to die on that hill to tell developers they're wrong and you're right, which is why when I do it, I do it in essay format with documentation, because if in general they know that the only times I will have a footnote section attached is I am that damn sure, the ones I can't do that with are more likely to be treated with benefit of the doubt.
The ducklings are learning. Luckily, they're learning from all of us, so I can't bend Duckling's mind too badly, though apparently we're in some kind of competition and he's recruiting the other testers to come to me for help under the thinly veiled excuse I'll answer questions, hence he's at negative three donuts--he was at six, but then we kind of ruined a wall in the tiny tiny former closet now double office two of them are in to set up their whiteboard and so being partners in crime, well, we kind of depend on each other for denial related purposes.
I have a very awesome duckling.
