Someone seeking a job that you control can probably be said to be like a coworker for the purposes of analyzing power imbalances.
993 karma · joined January 1, 2015
This is especially true when two products have teams of about equal size, experience, and expertise. Time spent selling is time not spent making a better product. All other things being equal, every hour spent selling is one less hour spent working on making your product better.
Nobody is going to die if you can't date someone.
Again, I advocate a conservative approach to getting a date with a coworker. One request, declined for any reason, should be treated as a firm no absent explicit signals to the contrary (request for a rain check, some other sort of proactive, explicitly date-seeking behavior from the other party). Your odds of getting into trouble under this rule are so vanishingly small as to be nonexistent. If you choose some less conservative rule, including, apparently, whatever rule you've been following up to this point, your risks are higher.
Of course, there's also the issue of not wanting to make your woman coworkers uncomfortable. I would hope that would be something of intrinsic value to you, and that on this basis alone you might change your behavior after seeing its impact in the past. The fact that you're still arguing about this makes me doubt that you do value their comfort the way that I think you should. But I don't know how to tell you that you should care about other people in a way that's going to stick. :(
- Further reparations to groups representing those similarly situated.
- Meaningful engagement with mental health professionals to attempt to work on the source of the problem.
- Less defensive, less self-promotional apologies.
These four are the bare minimum. Until he has done each of these, he's receiving a failing grade from me.
IMO, you should seek therapy. You sound like you need it more than most.
Did you ask multiple times? This sounds like what could easily happen when someone won't take the initial "no," implicit or not, for an answer. Based on the rest of your comment, I expect so.
A few important points:
1. Repeated asking has been held to be sexual harassment, if repeated for long enough.
2. Here's a simple rule: ask once, and only once. She knows where you work. If she's interested, she'll ask for a rain check and get back to you.
> I just don't think this is suitable verbal behavior for supposedly rational adults
3. Rational adults understand and respond to signalling. They don't demand that all communication happen explicitly and on their terms, because they know that such demands are ineffective for all purposes, will not be heeded, and might make them social pariahs.
If I could not acquire productive assets, there would be much less reason to save. And it's unclear how one would save, as banks would likely not exist either. You can solve this problem somewhat by having a centrally planned economy. But then you have the problems that hit those.
(Also worth noting that McMansions are typically homes to the upper middle class and the rich, not the poor.)
One example that was brought up elsewhere in the thread is the way python looks up variables in successive scope dictionaries. This is obviously terrible for performance, and that's a big part of why Python is slow.
But how are other languages fast? Doesn't every language have to resolve variable names to memory locations? Well, yes, but fast languages do this mostly at compile time. How? Well, I'm not an expert in this, but at a high level, each variable is assigned a location in memory or registers, and then future references to that variable are rewritten to refer to the memory location by register name or memory address. This takes the whole "looking up a name" issue out of the path of work that has to get done at runtime. And you've switched from looking up things in tables to operating directly on registers and memory locations.
BTW, this has nothing to do with high-versus-low level. It's more about how mutable the process of name resolution is after program compilation. One could theoretically write an assembly language where memory locations are names, not numbers. If reflective features like runtime scope editing are available, this would be a very low-level language that still requires some kind of dictionary lookup at runtime.
You keep on talking about ordered tables like red black trees, as in this comment, which is another sign that makes me wonder if you might be confused.
So you're saying you're going to hash the keys, then sort them according to the hash, with tie breaking on the key itself? I'm not aware of any sorted table that does this, but I'm sure some exist. I suppose you'd get something of a win if N was large, and the keys had long common prefixes, and you didn't care about the ordering property.
But in that case you'd probably use an actual hash table, not the algorithm you just described. Unless there's something I'm missing.
Most of the things you mentioned are not hash tables, but members of a parent concept, dictionaries. Hash tables all by definition involve some sort of hashing of the key. The two main categories of hash table are chained hash tables (std::unordered_map does this, at least in the implementations I'm aware of) and open addressed hash tables, which use probing instead of secondary data structures to resolve conflicts.
Oh dear. No. That's not true at all. Suppose I have back pain. Then I eat some dirt. Then I feel better. Then I start claiming that dirt ingestion cures back pain. Someone would be well within their rights to call that bullshit, despite my anecdote. Even if I could find a dozen people who had the same experience, it would still be bullshit.
That said, I had been under the impression that chiro is about as effective for lower back pain as evidence-based physical therapy. But that doesn't mean it is effective. It could equally well mean that we don't know of many good treatments for lower back pain, and thus that physical therapy is only good as a placebo (chiropractic).