munchbunny

I find this is often true for me. If there's a bunch of code that I'm having a particularly hard time understanding, it's usually because I don't actually have a working mental model of what the thing is supposed to do.

Problem is, with complex systems often the way to record the mental model is something like a design document, and getting programmers (including myself) to write thoughtful natural language to accompany our code is a constant uphill battle against business pressures to ship more.

I'm sure I've inflicted my share of hard-to-understand code too, most likely out of not wanting to spend extra time on some byzantine section of legacy code.

Arguably that’s a different overload of the term “AI” the way it’s used in business, but I think it’s a good reminder that AI as a field has a long history that developed separately from ML and data science.

I was going to suggest: we have a bunch of data scientists working on intrusion detection problems in cybersecurity, tied to an engineering organization instead of an IT organization. On the balance of considerations, I think it has a net positive impact. And I'm pretty sure plenty of other companies have something similar. Unfortunately, we also have an ongoing hiring freeze, so I can't recommend my own organization.

I can empathize with the author on this one, that sometimes your emotional interest in someone dissipates for superficial reasons, but no matter how much you rationally know it’s dumb, you also know it’s unlikely you’ll think yourself out of the hole.

I’m also kicking myself for not making this connection back when I first inadvertently typed gibberish into my documents by accidentally touching my Yubikey.

The actual boundaries tend to be a bit fuzzy because a lot "product management" comes down to doing whatever the team needs in order to make sure a good product is delivered, and by necessity product managers often do a substantial amount of project managing.

Typically you'll see people conflating "program management" and "product management" in tech. You don't usually see "project management" in that mix since that tends to refer to a more industry agnostic discipline.

If your management hierarchy has too many mediocre managers, you lose the ability to evaluate who is/isn't pulling their weight at fine granularity, so you're stuck with blunt tools.

I never got to see the responses myself, but the recruiters from HR could. That said, if a hiring manager wants to bias their hiring based on this information, they'll figure out at some point before making a decision, whether or not you provided it. Your resume, your name, your educational background, your accent, etc. all passively shed information, so I would often find the answers without wanting to or trying to find them.

Others may be more concerned with the applicability of the pattern itself.

Probably. I’d agree that it’s worth trying at the very least. I’ve run into enough “should be easy” cases that turn out to be not that easy that my default is to get the data and see if the hypothesis really pans out.

But, say you had such a container, there’s an important distinction between “you captured a log showing the smoking gun evidence of the supply chain attack”, and “you successfully picked that log out of all of the log data you generated and classified it with high confidence as an attack”.

Speaking from experience, the second problem is the hard problem for a multitude of reasons. So while you would have the data, you’d probably have trouble getting good precision/recall on when to actually sound the alarms vs. when it’s some SRE who needed to troubleshoot some network connectivity issues.

Or maybe it’s just so easy to find out the gender during medical screenings that you have to not look on purpose, so why not look? Then you don’t have to go out of your way to plan for two (pretty much) mutually exclusive possibilities.

Parents who want their children’s paths predestined don’t have a “knowing the child’s gender” problem, they have a “you can’t control your child’s basic personality” problem.

If someone’s on the receiving end of all of those things they’ll usually leave sooner or later. Who wouldn’t want to?

Feels a lot like hiking: as you get more fit you also get access to more fun.

If you're trying to do this right, the short answer is "don't try to sync passwords." Use federated authentication (such as OAuth), or just use different passwords.

Can someone fill me in as to why they can’t just store the password using something like bcrypt?

It's addressed in the last paragraph: "For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted."

I guess you either have to store the password in plaintext so they can do dynamic hashing operations on it, or transmit the password (via TLS hopefully) which is vulnerable to packet capture (or captured within the receiving app).

TLS (when securely configured) is generally considered sufficient protection for the passwords in transit because stealing the password out of TLS typically requires first compromising the TLS connection, in which case you don't even need the password because you can steal the bearer token and the bearer token doesn't require you to get past a MFA check.

Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?

This question doesn't quite compute for me, do you mean provisioning as opposed to authenticating? There's no reason an identity provider would need to send a user's password to the user when trying to authenticate that user.

It’s entirely possible that the candidate was just off their game that day, or they weren’t “warmed up”. I get noticeably better at interviewing after the first few. It happens, but the interviewer has the information they got, and it’s not possible to totally control for that kind of variance.

What hiring managers should be actively minimizing, that most hiring managers I’ve seen do not, is variance that their interview process introduces by, for example, not standardizing and training their interviewers.

> Ditto. These tickets should be easy to auto-close if you force folks to include info about their client.

As a (former) modder, though not for VRChat, I can definitely empathize with this. Code quality with mods is a freaking wild west where modularization isn't really a thing and everyone monkey-patches everything. Supporting your mod/content amidst other mods is in the gray area where the etiquette expects content creators to support their stuff even though there's no "warranty" on the label, so you get significant variance in how demanding players are or how accommodating content creators are.

That said, I don't think anti-cheat is the answer here. Officially supporting mods and driving modified clients down a predictable path where you'll know when and how a client is modded seems like a better approach. Modders benefit from having real infrastructure to work with, and as the game dev you can ask players to turn off mods for troubleshooting.

I think you’re using “advertising” the way a marketing person would use “marketing”.

I don't think this changes anyone's point, just clarifying what might feel pedantic where there is a term of art associated.

I see the same problems in internet debates about which programming language to learn first or how to learn programming in general, and a lot of it just doesn’t take into account that learning is a long journey and staying on the path is often more important than taking the fastest or cleanest path. If trying to roll your own stuff is more engaging, great!

The exercise that helps me, personally, is to ask a series of context questions:

* Who is the intended audience? Why would the intended audience care about what's being discussed? Corporate communications tend to err on the side of broadcasting too widely rather than too narrowly.

* What is the communicator actually trying to get out of this communication? It's often not what it says on the label. With some people it's usually not what it says on the label.

* When they use a specific buzzword or marketing term, why did they use that term and not any other term? It's easy to dismiss buzzwords as bullshit (e.g. omnichannel marketing), but they didn't catch on out of sheer luck, so why is it that this specific person is using this specific term?

There's much more there, but in general I will try to focus on understanding the context that whatever is being communicated fits into, and once I understand that then things tend to be easier to parse.

This is the heat death of any organization. Organizations can absorb a stunning amount of dysfunction and somehow keep ticking.

> The director retorted and asked rhetorically what if my team complained that I wasn’t doing any work?

I think you can interpret that question two different ways, and it's hard to tell which one it was without being in the room/being in their head. The more generous way to interpret this is that they were checking your understanding of the role a manager plays outside of pushing changes and decisions.

That said, if it was clearly the director communicating that a manager should be jumping in and imposing a vision immediately, then you would've been misaligned philosophically, and that's probably not a job you'd want even if you're qualified. Being a manager while fundamentally disagreeing with your own boss is having one hand tied behind your back.