I always thought it meant "I'll go check if it's raining (and never come back)", but it turns out that a rain check is an IOU given out when an outdoor activity is disrupted by weather, so you can use it for a later event.
6,770 karma · joined February 26, 2009
Let's not move the goal posts, please. If you're going to use a hypothetical situation as an analogy, make sure it's actually analogous. Yes, an engineer who puts together a circuit has that responsibility, because they're an engineer. They went through the required training that makes them an engineer and not just an engineering student.
> I find it hard to believe that the lab tech said it could never be the parts, considering how those things are handled in student labs, small parts break all the time.
And therein lies the problem. You "find it hard to believe" that the lab tech could have been that unhelpful, just like the lab tech found it hard to believe that the student wasn't doing something wrong. Both you and the lab tech are behaving in a way that is inappropriate for a senior mentoring a junior.
In my experience mentoring others, the first assumption should not be that the person you're mentoring simply didn't do enough and that they should try to do better. Yes, that might end up being the case, but most of the time there's also something else that could have been done better. Maybe the documentation is not clear enough, maybe the process didn't help catch the mistake, maybe the expectations I set weren't clear enough, maybe I didn't communicate well enough.
"Go check your work again" is rarely helpful, even in the extremely rare cases where that's the only thing that needed to be done and no other improvements exist. If you're really convinced that they merely need to check their work again, guide them to it.
That's why they are junior and you are senior, because they need more guidance than you do. They will not develop the necessary insights and instincts without that guidance.
> I've seen the other side of the equation as well, when things don't work students often just throw their hands up and say "it doesn't work" without any of their own troubleshooting expecting the tutor/lab tech/professor to do the troubleshooting for them (quite literally, can you check that we wired everything correctly...)
And in turn, you're arguing that the mentor should merely throw their hands up and say "go check your work yourself". Again, even that can be said differently: "Can you explain what you have checked so far and how you've checked it?"
> Simply saying "it wasn't my fault because I had a wrong part" shouldn't just give you an A.
You are drawing a lot of your own conclusions from what hasn't been said. In this comment thread, you have repeatedly and consistently shown bias through your assumptions. Yes, what you're saying could have been the case, but I see no evidence of it and no reason to simply assume it without at least inquiring about it.
They should expect that particular incident to not affect their performance evaluation, since it was very much not their fault.
In your hypothetical scenario, your hypothetical junior engineer went to the senior engineer repeatedly for advice, and the senior engineer did not do their job properly:
The lab tech was unhelpful, insisting that it must be something with how I had it wired, encouraging me to re-draw my schematic, check my wires, and so on. It could _never_ be the equipment's fault.
This is a huge failure in mentorship that wouldn't be ignored at a company that actually cares about these things.
Our computer lab had Novel Netware, I forget which version. Every once in a while, our regular programming classes (Pascal in first two years, C and Assembly Language in third year, Prolog and Theory of Relational Databases in fourth year) would be held in the lab, instead of the classroom, and we would get to put what we learned to use and do some actual programming.
Now, some of us had computers at home and had been using them since before the high school, so we tended to finish our work really fast and then get bored. And just like a lone sharpie cap is the most terrifying thing a parent can stumble upon, so a bored high school kid is the worst thing for your computer security.
Each student had their own account, but teachers shared a limited number of teacher accounts, with special privileges, such as monitoring other students' screens, having full write access to every student's files, etc.
For some reason, I don't remember why, teachers would occasionally go to a student's workstation and log in as a teacher there, to fix the problem. I honestly can't remember why, but it was a common enough problem that it wouldn't raise any brows even if one of us "advanced" kids did it.
So, of course, I eventually came up with the idea of writing a really small and simple program that would look exactly like the Netware login prompt, with one small difference: when you entered the password, it would write it to a file on the filesystem spit out whatever the "incorrect password, try again" reply was, and then execv the actual login program.
The ruse worked perfectly: I called the teacher, they tried to log in, thought they mistyped the password, tried again, succeeded, did whatever it was they were supposed to do, and logged out. Now I had the teacher account password, and so did my best friends in mischief.
We had some innocent fun by pulling a couple of very minor pranks on our fellow students that flew under the radar, so none of the teachers realized that the security was compromised.
But then the annual programming competitions came, and those went all the way from school level, to municipality, to city, to republic, to federal. I was one of the people who qualified to the city-level competition, and what do you know, that year it was hosted in our school's lab.
I finished all the problems with plenty of time to spare, which is how I came up with the "brilliant" idea of helping some of my peers by sharing my solutions with them using the teacher account. Now, one thing they neglected to teach us was the importance of testing, but I'll be honest, even if they did that, I was a typical teenage "gifted kid", which meant I was overconfident and lazy. As a result, everyone who I shared my solutions with happened to have the exact same bugs in them.
A few days later, they called me to the teachers' room in the computer lab, and said that they knew I cheated, that I was already disqualified, and that I should save myself some trouble and explain what I did. So naturally, I came clean and I thought that was the end of it.
Indeed, it was the end of it for me. Nothing else happened, at least nothing of consequence for me. Years later, I found out that I almost got expelled. They held a teacher assembly or conference or whatever it's called when you get all of them together to make a decision, and the decision was whether to kick me out of the school. Fortunately, they decided to let me off with a warning and the official reprimand from the headmaster.
My mom didn't think that was funny at all.
> Like, just use a gun. Whatever you were going to attack with, put that in a gun, and attack at 45rpm, 3000 ft/s.
This is one of the many reasons why I like the Dresden Files universe. Wizards wield incredible power, but a wizard can still be brought down by a sniper.
Questions like this are why I'm beginning to dread the whole hiring process. It's a great question in some situations, but absolutely dreadful in others.
If you catch me with it during a two-week sprint when I worked on an interesting bug, I'll have no problem answering it and the discussion will be fun for both of us. But if you catch me at a different moment, I'll draw a blank and start feeling pressured.
Yeah, bugs can be extremely rewarding and interesting, but not everyone will find them memorable enough to be able to talk about them in the context of an interview question.
For example, if you asked me that question right now, I would be hard-pressed to answer it. Sure, I've had interesting bugs, but I've spent the last several weeks leading a greenfield project and having to deal with project management bullshit I never signed up for in the first place, and interesting bugs are not in my "mental cache".
Which brings me to my biggest gripe with this kind of question: people like to be reasonably prepared for an interview, and throwing this kind of unexpected question can make them feel bad.
That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay.
I always thought that this expression used the word "imply" in its mathematical sense, i.e. "correlation is not a sufficient condition for causation". Did I get that wrong, or did the author?
The reason why I interpret it that way is simple: when fascists are actually in power, there's no such thing as "mainstream" anymore. Authoritarian rule means that there's only one correct way of thinking and behaving, and everything else is a crime or heresy or "evil", depending on the specific flavor of authoritarianism. "Mainstream", on the other hand, implies that there are other views and that they can be discussed.
Back in 2006, I was working mainly in C with a bit of C++. One of the things I was taught was that "macros are evil", period. Then, in my spare time, I decided to try Common Lisp. I had a blast. I never wrote anything more useful than a half-assed catalog for my MP3 collection, but I learned a lot. My main takeaway was the power of metaprogramming -- with all of its footguns and pitfalls -- and took that knowledge with me to my day job, where I suddenly had a more nuanced view of how preprocessor macros can avoid being evil.
Later, when I changed jobs, I went back to Java, which was my main language before the C stint. I slipped back into the comfort of having my memory managed for me and the expressiveness of OOP. But in my spare time, I discovered Self and Io, and the fact that you can have OOP without classes blew my mind.
At that same job, I undertook the task to make our proprietary in-house language not only transpile to C++, but also compile to be executed on JVM. Understanding how JVM bytecode instructions work was easier than it might have been had I not dabbled in Forth in my spare time.
These days my day job involves working with C++ full time, but my hobby projects in Rust taught me to structure my thinking about the ownership and lifecycle of memory allocations.
So yeah, most of what I do in my spare time with other languages is largely "unproductive diddling" if you only look at the code I write in those languages, but the insights I take away with me are useful.
Also, it's fun ;)
Here's another example: what's the metric equivalent of "footing" the bill? The verb "to foot", in this example, has the exact same etymology as the noun "foot", but it isn't used as a measurement.
It's like asking what the imperial equivalent is for "the poem's meter". The question is nonsensical, unlike the comment you were replying to.
Sure, the comment was whimsical and flippant, but it was based on a legitimate objection: why express the pressure in an incredibly obscure way? The objection has sense, and the joke is related to it. Your knee-jerk reaction to the joke, however, conflates disparate categories.
To answer your question, "moving" would have been a perfectly acceptable substitute. You could also use "crawling", "creeping", "worming", or "wriggling".
> >> A pointer type that uniquely owns a heap allocation of type T.
> Until that documentation changes I find the article's point quite valid.
I think there's some confusion here and that it's because the concept of "pointer" is slightly overloaded.
One overload of the meaning is "first-class pointer types": https://doc.rust-lang.org/reference/types/pointer.html
The other overload, the one used in the docs for Box, Rc, and such, is basically "anything that implements Deref". People who say "Box is not a pointer" are referring to the fact that Box is not a first-class pointer type, i.e. it's neither a reference nor a raw pointer.
In retrospect, I realize that the part you quoted might sound like I felt that toy programs like that weren't magical, when I was a kid. On the contrary, I'm trying to say that they don't feel like magic in today's world.
Sure, and that's how you know you're really into programming. That's how I could tell my kid wasn't really into it, but rather wanted to try out this thing his dad loves to do so much ;)
I guess that hasn't really changed: if programming is something that "calls to you", it will still "call to you" despite all these changes.
I guess what I'm wondering is whether there's a "middle ground" we're missing. There are kids who will choose software development just because "it's a good career". I don't want my kid to take that path and risk ending up with a job that is absolutely devoid of joy, rather than trying to find something that would be more fulfilling. On the other extreme are the kids who are the way I was when I was a kid: programming is something that fascinates them regardless of whether it's useful or a good career, because they find joy in the act of programming itself.
Does the middle ground exist? Are there kids who would actually be happy writing software for reasons not so banal as "it's a good career", but aren't in the "holy shit, this totally abstract and pointless thing I did was so cool" category either?
The saddest thing about the way this changed is that the barrier to learning is so much lower today, but what do you actually do once you've learned?
When I was a kid, there were no programming classes in school and I had to go buy books and magazines to learn how to code in BASIC or assembler or Pascal. But once I've learned a new trick, I could immediately do something with it and feel good about it. It didn't matter it wasn't something spectacular, it didn't matter it wasn't very useful, because it was mine and there weren't 1000 of other things just like it, available to me at a touch of a button.
Compare that to what my kid is going through. He wanted to try learning to code, so we signed him up for some classes where he learned some Python. Later, in high school, he took AP CS Principles and they taught him some rudimentary JavaScript. Now, in his junior year, he's taking AP CS A, where they're teaching him Java.
Thing is, what can he do with all that? He's surrounded by devices running code. Writing a toy program that fills the screen with "HELLO, I AM COMPUTER" does not feel like you just learned a magical incantation that makes this machine do your bidding. Writing some actually useful code is harder, and it feels pointless, because there's almost always an existing app you can have at a click of a button and it does what you thought of and probably better. Writing useful code that doesn't already exist -- like e.g. your own mod for such-and-such game -- is even harder than that.
> Any individual developer is going to be in a niche. Your web developer knows nothing of how to write ABAP, your SAP developer has no clue how to do embedded programming for a microcontroller, your real-time embedded programmer knows nothing of databases, your database admin thinks React is something to do with nuclear power plants.
To top off the irony, generalists are not being appreciated or sought much.
No, it doesn't. Not for what you're arguing.
You made a claim about personal responsibility. I replied to it by pointing out the power imbalance between the employer and their employees. You took it to mean that the power imbalance between the employer and each individual employee matters.
It does not.
Think, for a moment, about what you're arguing here. Dariusz has repeatedly requested changes to his working conditions, because those conditions were too exhausting for his health. Amazon repeatedly chose to not grant any of those requests.
The argument you present here is that whether Dariusz was unwilling or unable to find the job should somehow change the responsibility that Amazon has towards making sure that the Dariusz's working conditions wouldn't end up killing him.
If that is your position -- and I suspect it is, given all the replies on this topic where you characterize Dariusz as a person with subpar mental health who lack self-preservation instinct -- then we have reached a fundamentally irreconcilable disagreement of a moral/ethical nature.
That depends on the power imbalance.
The power dynamics in a job market are not symmetrical. The employees and employers are not on equal footing and don't wield the same power. The power imbalance becomes more pronounced the lower you go in the pecking order, with blue-collar laborers being the lowest rung.
In short, the more an employer is in position to exploit their workers, the more responsibility they should bear. That's one of two ways to prevent exploitation. The other way is to shift the power balance back, by organizing into unions, which is why Amazon, Starbucks, and similar companies have been engaging in union-busting quite a lot.
> We don't ban jobs like roughnecks and our culture of rewarding working too hard is a problem.
That's one part of the cultural problem. Another important part is the constant indoctrination, from a rather young age, against workers' rights and in favor of exploitation.
That's how we end up with so many people who are biased towards corporations and always looking for ways to absolve them from their wrongdoings.
> There is no political statement besides the always work harder ethic which I don't agree with.
Of course there's a political statement there. The political statement is right there in assigning disproportionate blame to the worker who has repeatedly requested to be treated in a way that would not lead to his death, and not enough blame to the employer who refused to consider those requests.
That's what politics are -- or should be -- really about: real lives of real people. We're all used to looking at politics as machinations of the political class, but that's not how things are supposed to be.
As for insults, it was not my intention to insult you and I'm not sure which part of my reply you found insulting. If it was the reading comprehension, then I apologize for the way it sounded: I merely meant to say you might not have understood the sentence properly, which is something that happens to everyone.
If it was the part where I pointed out your bias, that's on you. When I point out that the person you're trying to blame for their own death might not conform to your own expectations -- the expectation that they are free to choose to quit without any consequences -- you're perfectly happy to call that a "fantasy", but you don't apply the same label to your own ideas about people who "want to work themselves to death". If you find the description of your biases insulting, maybe you should re-evaluate them.
Granted, the sentence could have been phrased in a way that didn't leave things open to your interpretation, but then we come to the second thing that "doesn't add up": your own bias, evident in your insistence on victim-blaming.
People like Dariusz continue working in adverse, unhealthy conditions because they don't have the luxury of just quitting.
Did you read the whole article carefully? There's a detailed description of the events that led to his death, and how the company's treatment of him and of his requests and complaints directly contributed to his death.
- Cactus Missile
- Mammoth Marula
- Super Lizard Wizard
- Cheesethorn Bush
- Cheesnado Lizard Wizard
- Cheesnado 2: Cheesnado Strikes Back
- Cheesewolftrap
This provided @selimthegrim with the opportunity to use Danilo Kiš as an alleged example of how the expression was also used in Yugoslavia, not that I can find anything to verify that claim.
Suffice it to say that I don't know anyone from my generation who has even heard this expression, much less used it, and it's certainly not part of the cultural milieu in which my generation grew up.
Like I said, it's just pedantry, and not of the good, informative kind we can see in sibling threads, where the interesting background and nuances of the expression are highlighted for purposes of enlightening the readers. Rather, it's terse, opaque kind of pedantry whose purpose I fail to understand, unless it's to stubbornly double down on the claim that the expression you used is universally unambiguous and instantly recognizable to everyone.
It was also quite informative to learn about this phrase and its nuances.
I'm still trying to figure out what you're trying to say, though.
If your point is that there was plenty of bigotry in old Yugoslavia, then yeah, I know that. It's still alive and well in the remnants of it. The casual bigotry and rampant nationalism are part of the reason why I'm still "rootless", because I wouldn't fit in with my compatriots anymore.
But none of that was really the point here. The point is that a phrase might be very well recognized by some people here and totally unknown to others who might stumble into using it by accident.
I mean, I don't actually know if Vektorceraptor was being deliberately antisemitic or not. Maybe Vektorceraptor did know it and its antisemitic connotations and used it like that on purpose. Or maybe not, maybe it meant what I read from it and described in my reply.
Yeah, it's fascinating to read the history of that expression, and to find out it's not a "Western", but a Soviet expression. But I'd like to offer a gentle reminder that the countries that comprised the Soviet Union are one set, and the countries that used to be in the Soviet sphere of influence is another set, and they're not the same set.