On the time I accidentally emptied a workstation printer
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
And not "slim and sexy" cat shape like might be in @Tsaukpaetra's spank bank of perverse furry art. Think more "People of Walmart" and obese cats that can no longer jump to high perches.
You're making some assumptions about disjointedness there.
-
@Luhmann said in On the time I accidentally emptied a workstation printer:
first priority action of my collages
-
@HardwareGeek
I blame @accalia
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
Think more "People of Walmart" and obese cats
For the first part of that, I prefer this cat:
-
@Luhmann said in On the time I accidentally emptied a workstation printer:
@Polygeekery said in On the time I accidentally emptied a workstation printer:
With the exact BAC I had at the time.
some variables can be difficult to control .. better make it two bottles
So try it, take a shot, try it, take a shot, until we get a recreation of prior events?
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
I bet I could end one of those emails with a promise of a $50 Amazon gift card for anyone who read that far and I wouldn't have to pay it out.
I seem to recall a story about a game dev actually doing something like that in their EULA.
-
@PleegWat said in On the time I accidentally emptied a workstation printer:
@Polygeekery said in On the time I accidentally emptied a workstation printer:
I bet I could end one of those emails with a promise of a $50 Amazon gift card for anyone who read that far and I wouldn't have to pay it out.
I seem to recall a story about a game dev actually doing something like that in their EULA.
As a junior in high school, the Honors English teacher made us do a writing/reading journal (writing about the book we were reading) periodically. We were really sure that she wasn't actually reading them. So one kid wrote "Ms _____, if you're reading this, I owe you $10". She never mentioned it.
Incidentally, she was also the cheerleading coach and that was blatantly obviously much more important to her.
-
@Benjamin-Hall A friend of my brother (so we're in friend-of-a-friend territory, although he actually witnessed it, so it probably (?) really happened) did something similar when defending his PhD.
At the start of his defence he put a couple of bottles of Champagne on the side of his desk, without saying anything. Somewhere deep in his manuscript was a footnote saying "if you mention this to me during my defence you've won two bottles of Champagne." As you can guess, no one said anything (including the reviewers who are supposed to have read everything... although possibly in that case they did notice it but for some reason just didn't say anything). The Champagne was part of the buffet afterwards so it wasn't wasted anyway.
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
@remi said in On the time I accidentally emptied a workstation printer:
@Luhmann it's even worse when there are both a priority and a severity field. It's almost impossible to get a user to understand that both are not the same.
I've come to the conclusion that you may as well get rid of both. 90+% of users fall into two camps in regards to those.
- Users who ignore them and accept defaults
- Users who think everything is the end of the world
You could replace them with randomized plaid patterns and it would make little difference to overall outcome.
We only pay attention to the ones that are URGENT. Because it's written into our contract. We have an SLA for responding to those. They don't come in very often any more and the customer is understanding when you get those end of the world type people.
The ones that are real are usually either a billing problem or a data call that someone high enough up that we can't refuse needs TODAY (seems like Friday afternoons mostly).
-
@remi said in On the time I accidentally emptied a workstation printer:
@Benjamin-Hall A friend of my brother (so we're in friend-of-a-friend territory, although he actually witnessed it, so it probably (?) really happened) did something similar when defending his PhD.
At the start of his defence he put a couple of bottles of Champagne on the side of his desk, without saying anything. Somewhere deep in his manuscript was a footnote saying "if you mention this to me during my defence you've won two bottles of Champagne." As you can guess, no one said anything (including the reviewers who are supposed to have read everything... although possibly in that case they did notice it but for some reason just didn't say anything). The Champagne was part of the buffet afterwards so it wasn't wasted anyway.
Around here you need to give three copies of the published dissertation to the university library. I've heard people mention that you could put in a 10€ bill somewhere in the middle and then a few years later come check if anybody ever as much as flipped through that copy.
I didn't, but I know it'd still be there.
-
@PleegWat said in On the time I accidentally emptied a workstation printer:
@Polygeekery said in On the time I accidentally emptied a workstation printer:
I bet I could end one of those emails with a promise of a $50 Amazon gift card for anyone who read that far and I wouldn't have to pay it out.
I seem to recall a story about a game dev actually doing something like that in their EULA.
The story was that the publisher would own the end user's immortal soul unless the end user objected. On the official objection form the user then would read that it was a joke and in return get an extra voucher.
No takers.
-
@sloosecannon said in On the time I accidentally emptied a workstation printer:
@Gribnit said in On the time I accidentally emptied a workstation printer:
@Benjamin-Hall said in On the time I accidentally emptied a workstation printer:
Recently we had an outage because one of the other junior devs was working on getting a replica of production set up so that team could validate a database migration to AWS (currently colo at a local data center). Well, they had the database set up, and were connected to it. But something had gone wrong, so they needed to drop the database(s) and rebuild from test data.
You see where this is going? He was connected to the test database. But he also was connected (in a different terminal window) to the production read-write database. As root. And the wrong one had focus.
Fortunately we caught it before our hot read-only clones tried to sync, so we could just fail over to one of them as the primary db instead of having to restore from backup. And they implemented big colorful "you're in production, idiot" warnings on all the SSH prompts at that point.
is anybody having an unrestricted prod user and prod being accessed through anything but a read-only mirror.Depending on the company though, that kind of infrastructure (and cost) isn't feasible.
At the company I work for we're trying to do things right, so they set up separate accounts for system administrators to do their administration, in addition to their regular accounts for email, Microsoft products access, etc.
Auditors for ISO 27 000 security management come in because we wanted to get the certification:
Well, you should use a dedicated computer to log in to those accounts. Can't know that you haven't got a RAT installed and thus are providing hackers access to those admin accounts.This way costs can go up very quickly.
FYI, I think our IT department asked if they could postpone abiding by that guideline as part of risk management. The financial department didn't like having to buy all system administrators a second laptop in one big bunch, and neither did the system operators love to haul a second laptop around...
-
@JBert said in On the time I accidentally emptied a workstation printer:
At the company I work for we're trying to do things right, so they set up separate accounts for system administrators to do their administration, in addition to their regular accounts for email, Microsoft products access, etc.
Auditors for ISO 27 000 security management come in because we wanted to get the certification:ISO 27001? That's how we do it and we've got the certification.
-
I guess it's that one.
And I think we also can get away with not having the extra computer, but because the auditor mentioned it we would still need to take note that we're deviating from the recommendation.
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
- Users who think everything is the end of the world
- Users who have learned from experience that anything less than DEFCON 11 THE EARTH IS ABOUT EXPLODE will be ignored for at least 2 weeks.
-
@El_Heffe Trick is… give the users a priority field and then don't show that to any staff, who have their own importance field that is never shown to users.
-
I have been summoned, and so I appear...
-
@dkf said in On the time I accidentally emptied a workstation printer:
@El_Heffe Trick is… give the users a priority field and then don't show that to any staff, who have their own importance field that is never shown to users.
Ohhhhhhhhhhh, I might have to dust off our helpdesk codebase. I know a few users that deserve the "If you get around to it, have nothing else to do, and are tired of scratching your balls" importance field.
-
@El_Heffe said in On the time I accidentally emptied a workstation printer:
Users who have learned from experience that anything less than DEFCON 11 THE EARTH IS ABOUT EXPLODE will be ignored for at least 2 weeks.
The overlap between that fraction and the fraction that thinks them having to walk another 25 feet to pick up something that they probably didn't need to print anyway is a DEFCON 11 issue is approaching parity.
-
@El_Heffe said in On the time I accidentally emptied a workstation printer:
DEFCON 11 THE EARTH IS ABOUT EXPLODE
lower DEFCON level means higher readiness.
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
25 feet (About 12 centimeters for the metric folks)
:zwj:
-
@remi said in On the time I accidentally emptied a workstation printer:
We had those two fields in a previous bug tracker. Now there is only one, and it has a default value of "medium", and approximately 101% of issues use this priority, and all is well.
I wonder if defaulting to lowest wouldn't work better.
-
@topspin said in On the time I accidentally emptied a workstation printer:
@Polygeekery said in On the time I accidentally emptied a workstation printer:
25 feet (About 12 centimeters for the metric folks)
:zwj:Maybe he is a NASA contractor?
-
This post is deleted!
-
@boomzilla said in On the time I accidentally emptied a workstation printer:
We only pay attention to the ones that are URGENT. Because it's written into our contract. We have an SLA for responding to those.
A couple of years back, we had in our yearly objectives something like "resolve all urgent tickets in a timely manner." Which was both precise enough to possibly get us in trouble (if users were dumb enough to swamp us with stupid "urgent" items), and vague enough to allow us to wiggle out (I don't remember how the "timely manner" was specified, it was a bit more precise than that, but still not a hard time limit so we could always have pushed things a bit, and also there was a clear understanding that the priority of an item is what the user and support decide together, not what the user initially picked, so we could easily degrade items if needed).
Which all didn't matter in the end because we were lucky to actually have a manager with more than half a neuron (yes, those do exist!). In practice the objective's evaluation was "are users happy with our support?" and the answer was always "yes" because we don't have many users and they rely on us for many things and we've always helped them. The objective really just was an attempt of making it look to HR as if we had a formal, measurable, goal.
I think that's the last time I cared about priority in a ticket.
-
@Gąska said in On the time I accidentally emptied a workstation printer:
@remi said in On the time I accidentally emptied a workstation printer:
We had those two fields in a previous bug tracker. Now there is only one, and it has a default value of "medium", and approximately 101% of issues use this priority, and all is well.
I wonder if defaulting to lowest wouldn't work better.
We actually had this discussion in my team. Some people argued that picking one value or another (I don't remember the arguments for each value) would either better reflect users' expectation, or be a stronger incentive for the user to change the value to something meaningful. None of those arguments were really convincing, and since we also have a very low rate of new tickets (it's just formalising the way we help the few users we have), it doesn't really matter, so we stuck to whatever default the system itself provided.
Though it's maybe worth noting that while the default priority is the middle of the scale (there are 3 more severe, and 2 less severe, priorities), it's actually called "high." I suspect the people who designed the system had the same argument as we did and settled for an actual middle-of-the-road priority, but named as a top-of-the-scale priority to make it... more scary for users? more believable? A bit of this and a bit of that? Whatever.
(amusingly, the 3 more severe priorities are "urgent", "critical" and "immediate" (in this order of growing priority), and by having to find names higher than high, they had to pick names that IMO don't clearly indicate the order. What I mean is that while the order between low/medium/high is obvious, it's much less obvious to me whether "critical" is higher or lower priority than "urgent", for example)
-
@remi said in On the time I accidentally emptied a workstation printer:
it's much less obvious to me whether "critical" is higher or lower priority than "urgent", for example
That's because "urgent" refers to time, and "critical" refers to importance. Something can be urgent but not critical (change the logo for tomorrow's client demo), or critical but not urgent (fix the rare data-loss bug before the release scheduled in 6 months).
-
@Zerosquare ... aaand you're bringing back the start of this sub-thread (
to add a link but it's not that far up), about having a priority and a severity field (or urgency/importance/whatever other word you want to use and yes they're all slightly different but keep reading...).Yes, I think the makers of this system decided to mix the two notions and then ended up picking terms that apply more to one than the other. Probably in part because even people writing bugtracking systems can't make the difference between the two. They are different in theory, but the difference is so abstract that no one can use it in real life. Forget about it. Just use priority. And even that, as the discussion here shows, is useless. Forget about it. Sort issues internally if you want, when deciding which ones have to be handled first, but don't bother exposing that to the user. KISS.
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
I bet I could end one of those emails with a promise of a $50 Amazon gift card for anyone who read that far and I wouldn't have to pay it out.
At one place I worked, a senior dev ended important emails with something like " if you read this line, ask me for a beer at the pub". Over several years of him doing that, I was the first one to ask him for a beer. He was surprised when I asked.
-
@remi In SRs, I think we only have severity. I'm also pretty sure customers pay higher support fees to be able to use the higher SR severities.
But I don't deal with SRs, I deal with bugs. For bugs, we have both severity and (development) priority. The bug severity is set by the support engineer to communicate how urgent the customer feels the issue is, and is completely ignored by development. Bug priority is set by development; anyone else touching it gets a stern talking to, and it is the main guide as to if and how quickly an item gets picked up.
-
@remi said in On the time I accidentally emptied a workstation printer:
We had those two fields in a previous bug tracker. Now there is only one, and it has a default value of "medium", and approximately 101% of issues use this priority
Part of the problem may be that, without a good view of the whole field, there is no sense of scale. If I had to setup a helpdesk ticket system, I'd probably put in the following choices for a "priority" field:
- EHS violation
- Hinders my work
- Obstructs my work completely
- Obstructs the work of the whole department
- Incurs a quarterly expense
- Incurs a monthly expense
- Incurs a daily or weekly expense
-
@remi said in On the time I accidentally emptied a workstation printer:
(I don't remember how the "timely manner" was specified, it was a bit more precise than that, but still not a hard time limit so we could always have pushed things a bit, and also there was a clear understanding that the priority of an item is what the user and support decide together, not what the user initially picked, so we could easily degrade items if needed
Ours is something like...we have to respond within an hour (or maybe 30 minutes?) during working hours that we've seen the ticket (just making an update, e.g., assigning it to yourself, etc) counts. And we have to have a plan of action within 24 hours (adjusted for business days). So not really too bad.
-
@acrow said in On the time I accidentally emptied a workstation printer:
Part of the problem may be that, without a good view of the whole field, there is no sense of scale.
I agree, but the wider part of the problem is that in practice no one has that view of the whole field, or at least no one who actually interacts with each individual ticket.
Depending on the scale of the project and of the whole organisation, maybe there is one architect/senior developer/manager (whatever their title is) who can have that view of everything (but even that isn't guaranteed!), but unless the project is tiny and basically there are just a couple of persons doing everything, that person is unlikely to be involved in filtering each and every item to understand them and assign the "right" priority. So by necessity that field has to be set by someone with a partial view of things, and as other persons with other partial views of things come along they will perceive the actual priority of the item differently (and may or may not adjust it, depending on how the system works).
Plus, there is the whole thing that users should not have to care about this. They've stumbled upon an issue, they've reported it. End of story. You don't ask users to fill in the name of the sub-module from which the error comes, even though that's a key information that you need to assign it to the right person.
So again, by all means use those fields internally when deciding on what you need to work next, but don't bother the user with it.
-
@Carnage said in On the time I accidentally emptied a workstation printer:
At one place I worked, a senior dev ended important emails with something like " if you read this line, ask me for a beer at the pub". Over several years of him doing that, I was the first one to ask him for a beer. He was surprised when I asked.
Oh that reminds me that I am actually doing something similar right now!
We have a monthly team meeting for which everyone prepares 1-2 slides on what they've done. It's all collated in one big PPT that obviously uses the company template. That template has a footer (in bright red!) that says something like "internal - confidential - public" and we're supposed to edit it to keep the relevant one (this serves as a reminder that every PPT should have the confidentiality level in it so we know how they can be distributed or not -- and as severity levels for bugs, it doesn't work very well...).
For the past few months, the footer in my slide(s) reads "does anyone read footers?", in the same bright red font etc. Someone finally noticed it, but it took some time before that happened.
-
@remi said in On the time I accidentally emptied a workstation printer:
Plus, there is the whole thing that users should not have to care about this. They've stumbled upon an issue, they've reported it. End of story.
I'd have to disagree on that. I notice that a lot of the time I don't know the actual urgency of a customer's request unless they tell me.
There have been cases where I've rushed a fix out, for a bug that technically could endanger lives. And then do a follow-up. And I get told "yeah, we'll start updating the firmwares after the site is all up next month. Don't worry about it. As long as it's eventually fixed so we can lift the movement restrictions on that area".
And another time, I'd left a minor UI form tweak in the queue for a week. And then I get a call: "We're getting fined for every day that UI doesn't match the manual to the pixel." (Some government departments really don't like foreign competitors to their pet vendor.)
Of course, my tickets come from external customers. That are organizations. So we have contractual obligations. But I can't really imagine completely bypassing the users' view on the severity of issues when scheduling work, no matter the product.
-
@acrow That's a good point, but I still believe that having a priority field isn't going to work. As was said before, all you'll get is that all tickets will ultra-high-priority-!eleven!
Your examples are good of why a field (or even several) won't work. The "bug that technically could endanger lives" could have been seen as such by the customer and entered as super-urgent but it's actually not. Sure, in that case having both urgency and severity would have worked, but that's assuming the user would have filled it in correctly, which is unlikely. A user smart-enough to decide that it could technically endanger lives is likely to also think "OMG, this needs to be fixed right now!!"
And because of that low likelihood (basically, all those dumb users poisoning the well for the few less-dumb ones), even if the second example of the "minor UI form tweak" had been correctly tagged as "low severity, very urgent", it's likely you (or someone else) would still have dismissed it as "just another user who can't walk 5 m to use a different printer and screams that they can't work." That is, unless the item description did explicitly include the "We're getting fined" bit, but that doesn't fit into a priority field.
I can't really imagine completely bypassing the users' view on the severity of issues when scheduling work, no matter the product.
I agree with that, but I also think that an enum (low/medium/high) isn't going to work here. As you highlighted, you need to have an actual discussion with the user to find out. It doesn't fall into the neat little categories that technical people (and humans in general) like to make.
So I stand by my opinion. Don't bother with a field that will be at best useless, at worst misleading in the vast majority of cases, and instead talk to your users. Get to know them. Yes, it's more effort. But I'm pretty sure it will be much better for your customers' satisfaction than firing an automated "our issue is serious to us" every 12 hours.
-
So, to tie the subthread back to the topic... what would the appropriate priority for a "walk the employee out the door" ticket be when they print 2000+ pages on a customer's print station?
-
@izzion said in On the time I accidentally emptied a workstation printer:
So, to tie the subthread back to the topic... what would the appropriate priority for a "walk the employee out the door" ticket be when they print 2000+ pages on a customer's print station?
That's not really that much of a catastrophe. It's entirely fixable with just some money and an intern's time (to take all those useless printed pages to the right disposal system). If anyone is walking out of the door, it's only due to sheer embarrassment.
Unless the things being printed were stuff that really shouldn't be.
-
@remi said in On the time I accidentally emptied a workstation printer:
You don't ask users to fill in the name of the sub-module from which the error comes,
Subcomponent is a mandatory field for products which have them. Some products yell at you for picking the wrong one.
But then, some products yell at you for not including a step-by-step reproduction which works on their environment, or for not including extensive workaround descriptions.In short, some products give this company a bad name.
Of course, this is a bug tracker not an SR system and it's not customer facing. But internally we use bugs to other systems, since we're not allowed to use the SR system.
-
@PleegWat said in On the time I accidentally emptied a workstation printer:
Subcomponent is a mandatory field for products which have them. Some products yell at you for picking the wrong one.
Yes, ours also does. Which is stupid IMO, as users mess it up regularly and we have to change it afterwards, and it doesn't add much for the user (product is useful, because that's what the user sees on his computer, but not submodule). Sometimes when two modules are properly integrated together (
) it's actually hard to know which of the two is at fault, and finding out is really part of the resolution of the issue.
-
@remi said in On the time I accidentally emptied a workstation printer:
@PleegWat said in On the time I accidentally emptied a workstation printer:
Subcomponent is a mandatory field for products which have them. Some products yell at you for picking the wrong one.
Yes, ours also does. Which is stupid IMO, as users mess it up regularly and we have to change it afterwards, and it doesn't add much for the user (product is useful, because that's what the user sees on his computer, but not submodule). Sometimes when two modules are properly integrated together (
) it's actually hard to know which of the two is at fault, and finding out is really part of the resolution of the issue.Yeah, and the entire product/component/subcomponent can be changed later on. The bug number doesn't even change - just the associated JIRA ID does if you change the top-level product.
-
We don't let our users directly file bugs. CSRs create support tickets in their system, some of which end up becoming defects in engineering's JIRA after being reviewed by the product owner. Other non-engineering staff can use a similar (filtered) process, but no one sets priority outside of engineering. QA (part of engineering) can file defects directly.
Only the product owner (or engineering manager) sets priority, and there are a few types:
- Red Alert : The system is non-functional, core workflows are down for everybody. Of course...these are usually known by the team on call because all the monitoring goes nuts. This generally only affects the on-call team and whoever they pull in.
- Yellow Alert : A key workflow is degraded for at least one customer. This is interrupt priority, but not "work through the night" priority like red alerts.
- Release Blocking: Something came up in the QA environment and the next release can't go out until its fixed. Takes priority over other in-progress work, and bypasses some limits. Only QA can make these ones, and product owner has to say that it's release blocking.
- Top of swim lane : This is the next thing you pick up when you've got room unless it's blocked by something else. But that's it.
- Everything else.
And we prioritize as a product-specific team (including product owner and designer) every week, accepting stuff off the back log (or closing it), estimating it, and then deciding whether it's "do it next" or just "when we get to it".
-
@Rhywden said in On the time I accidentally emptied a workstation printer:
I mean, I myself once wanted to shutdown my workstation, typed in
shutdown -h nowand only when I saw theconnection lostmessage (and the subsequentinternet seems to be down) it dawned on me that I just had powered down the router.The guys at DEC SRC (or was it Bell Labs? I don't remember) had a shutdown command that demanded that you type the hostname of the machine before it would do anything. I thought it was a pretty good trick. It was 30 years ago and I still haven't seen it anywhere else...
-
@izzion said in On the time I accidentally emptied a workstation printer:
So, to tie the subthread back to the topic... what would the appropriate priority for a "walk the employee out the door" ticket be when they print 2000+ pages on a customer's print station?
Depends on what the pages contain.
( </joke> )
But for blank pages?... For the pettiest of companies maybe. If some place considers accidentally wasting 2,000 pages of A4 to be a fireable offense, then I wouldn't want to work there anyway.
Accidents happen. I've accidentally ordered a reel of 1,000 oscillators (32kHz, 3.2x2.4mm). Don't remember the exact cost, but in the 2k€+ range surely. And I'm still working here.
-
@Planar said in On the time I accidentally emptied a workstation printer:
@Rhywden said in On the time I accidentally emptied a workstation printer:
I mean, I myself once wanted to shutdown my workstation, typed in
shutdown -h nowand only when I saw theconnection lostmessage (and the subsequentinternet seems to be down) it dawned on me that I just had powered down the router.The guys at DEC SRC (or was it Bell Labs? I don't remember) had a shutdown command that demanded that you type the hostname of the machine before it would do anything. I thought it was a pretty good trick. It was 30 years ago and I still haven't seen it anywhere else...
That form of mollyguard is still used in S3 bucket and GitHub repo deletions.
-
@acrow said in On the time I accidentally emptied a workstation printer:
I've accidentally ordered a reel of 1,000 oscillators (32kHz, 3.2x2.4mm)
And the supplier wouldn't restock the reel?
-
@acrow said in On the time I accidentally emptied a workstation printer:
@izzion said in On the time I accidentally emptied a workstation printer:
So, to tie the subthread back to the topic... what would the appropriate priority for a "walk the employee out the door" ticket be when they print 2000+ pages on a customer's print station?
Depends on what the pages contain.
( </joke> )
But for blank pages?... For the pettiest of companies maybe. If some place considers accidentally wasting 2,000 pages of A4 to be a fireable offense, then I wouldn't want to work there anyway.
Accidents happen. I've accidentally ordered a reel of 1,000 oscillators (32kHz, 3.2x2.4mm). Don't remember the exact cost, but in the 2k€+ range surely. And I'm still working here.
I've run stress tests that cost more than that.
-
@Zerosquare Digikey stock is at least partially flown from the U.S., but they do some legal gymnastics to keep us from having to do border processing on them. We've never tried it, but just assume that the process isn't quite as easy in reverse.
Also, SMD components have handling requirements. Digikey couldn't guarantee their integrity once the reel has left their hands.
-
@acrow said in On the time I accidentally emptied a workstation printer:
Accidents happen. I've accidentally ordered a reel of 1,000 oscillators (32kHz, 3.2x2.4mm). Don't remember the exact cost, but in the 2k€+ range surely. And I'm still working here.
There's an old story about an employee making a major mistake costing lots of money who went to meet with the owner expecting to get fired. The employee did not get fired and remarked how surprised he was at the outcome.
"You just cost us $X. I consider it an investment. You won't make that mistake again and I want to get a return on my investment."No one bats a thousand.
-
@Polygeekery said in On the time I accidentally emptied a workstation printer:
@acrow said in On the time I accidentally emptied a workstation printer:
Accidents happen. I've accidentally ordered a reel of 1,000 oscillators (32kHz, 3.2x2.4mm). Don't remember the exact cost, but in the 2k€+ range surely. And I'm still working here.
...
No one bats a thousand.
There was that one guy who just made the one hit, actually.
