ewjordan

This seems like a great topic for a pre-trospective meeting to discuss the process of how to structure the process to figure out the process.

PM is a super heavily overloaded term that you'll run across in pretty much any company larger than small, definitely not specific to Google (disclaimer: I work at Google and don't speak for the company, but I'm brand new so my conception of the categories comes from what I've seen elsewhere). Engineers tend to raise an eyebrow at the entire job category because they're thinking of bad experiences with one particular flavor of PM (and often a particularly poor specimen at that), but that can be unfair, a lot of what they do is absolutely critical to business.

The acronym simply means either product manager, project manager, or program manager, but the responsibilities can be any/all of the following, and probably more, depending on the company:

- Full product owner, "the buck stops here" person. Many different possible titles here other than PM (usually "project manager" if that's the title), like general manager (GM), different flavors of producer, product owner (PO), VP of X, etc.

- Feature designer/owner/manager (product manager): writing specs (junior), pitching specs (mid-level), setting and selling product vision (senior), driving strategy (staff/exec, though at that level all roles start to get blurry). Decent business school grad representation here, you have to be good at strategy, negotiation, communication, and Powerpoint; having good product ideas helps a lot, too, but not if you can't sell them. A persuasive PM of this type is a force to be reckoned with and will get a lot of executive attention, which can be very good or very bad depending on whether the strategy they're into pans out or not. This is probably the type of PM the parent was talking about "armies of".

- Development director (project manager or program manager): a whip-cracker at worst or an impenetrable shitshield at best, they manage the practicalities of running a project, like project scoping, meeting and managing hard/soft deadlines, handling support, cross-team communications, processes, compliance, etc., often stepping in as an all-purpose guard against randomization so that others can focus on producing the product. Many PMs of this type ended up being the go-to folks for GDPR compliance over the past couple years, so it's not just internal process stuff that they deal with.

- Task checker: can blend into to the development director mentioned above, but at some companies this sort of PM will mainly focus on tracking tasks that are in-progress, getting estimates, watching velocity, and sending reports up the chain. Some devs find this role pointless and annoying, but it really depends on how good they are - if they're solid, they'll find a lot of ways to improve things instead of just tracking them.

- Scrum Master (project manager): Big-S Scrum is falling out of favor so it's not as fashionable to have this title anymore, but within some processes a similar role still exists as a type of project manager. In a nutshell, Scrum is a simple yet effective "People Over Process" process that consists of a bi-weekly no-laptops-allowed retrospective meeting where you get the team together to have a free-ranging discussion where everyone feels heard, so that you can all decide together whether the team should estimate engineering tasks in terms of hours or hats. You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats. A more seasoned Scrum Master will also schedule a quarterly retrospective-retrospective where the team discusses a strategy for what guidelines to put in place for the next retrospective so that the team can decide on hats faster and leave more time for the less settled question about whether or not the Fibonacci sequence is the right way to count hats or if a size-based approach will make people feel better supported in their work.

- Monetization designer (product manager): mainly at game companies, PM is often a super different role, probably best described as the profitability-focused counterpart to a game designer. They focus on setting prices, managing game economies, speccing and evaluating A/B tests, inventing loot boxes, etc. Ideally PM and designer would be one and the same, and the game design would be holistic with the monetization, with a designer that has serious Excel/analytics chops and deep inspiration and sensitivity about gameplay, but that's a more rare combination than you'd think, so a lot of companies split them out.

I'm probably missing some other ways this acronym is overloaded, but I think this covers most of it.

I 100% disagree. Have had extremely interesting conversations out of essentially this question regardless of my status relative to the person I'm asking (plus or minus 3 levels in the management chain), except in the rare case that the person is so super shy that they can't come up with anything to say even with coaxing. People that don't give a shit about me are even more interesting when they answer.

With a person who is higher status than you, they invariably have a life story that they are practiced at and enjoy telling, and know how to answer this question in a really satisfying and engaging manner because it's been asked so many times. That's the easy one, and pretty much no high level person will be upset if you ask.

It's toughest with someone not used to answering this question, or someone who thinks of you as higher status - in those cases, you can't just say "tell me about you", you have to make them comfortable and coax them into getting excited to tell you about things they care about. That requires active attention and listening, and is not necessarily easy.

Asking people to tell you about themselves is never rude, in any case. If your conception of "rude" includes that, then you're gonna have a rough time in all but the most wonky parts of business.

For a sufficiently advanced definition of "just playing the odds", that's pretty much what any model does.

> If the curvature were slightly less than 1, the topology would be "closed", meaning it would be finite, and traveling in a straight line ends back where you started.

Doesn't this require the assumption that the spacetime is embedded in a higher dimensional spacetime?

It's been a while, but IIRC there are perfectly valid topologically open cosmologies that have locally sphere-like curvatures (in other words, there's no necessary connection between curvature and topology without adding an embeddability constraint), right?

> You're assuming that it was based on whether or not the candidate was hire. Nobody with an iota of experience in machine learning would do something like that. (For obvious reasons: you can't tell from your data whether people you did not hire were truly bad.)

It's a fine strategy if all you're trying to do is cost-cut and replace the people that currently make these decisions (without changing the decisions).

I agree that most people with ML experience would want to do better, and could think of ways to do so with the right data, but if all the data that's available is "resume + hire/no-hire", then this might be the best they could do (or at least the limit of their assignment).

I don't think I'm with you. A neural net cannot do this - picking apart male and female tokens requires a signal in the gradients that force the two classes apart. If there's no gradient, then something like weight decay will just zero out the weights for the "gender" feature, even if it's there to begin with. Confidence wouldn't enter in, because the feature is irrelevant to the loss function.

A class imbalance doesn't change that: if there's no gradient to follow, then the class in question will be strictly ignored unless you've somehow forced the model to pay attention to it in the architecture (which is possible, but would take some specific effort).

What I'm suggesting is that it's likely that they did (perhaps accidentally?) let a loss gradient between the classes slip into their data, because they had a whole bunch of female resumes that were from people not in tech. That would explain the difference, whereas at least with NNs, simply having imbalanced classes would not.

If they were using any sort of neural networks approach with stochastic gradient descent, the network would have to spend some "gradient juice" to cut a divot that recognizes and penalizes women's colleges and the like. It wouldn't do this just because there were fewer women in the batches, rather it would just not assign any weight to those factors.

Unless they presented lots of unqualified resumes of people not in tech as part of the training, which seems like something someone might think reasonable. Then, the model would (correctly) determine that very few people coming from women's colleges are CS majors, and penalize them. However, I'd still expect a well built model to adjust so that if someone was a CS major, it would adjust accordingly and get rid of any default penalty for being at a particular college.

If the whole thing was hand-engineered, then of course all bets are off. It's hard to deal well with unbalanced classes, and as you mentioned, without knowing what their data looks like we can only speculate on what really happened.

But I will say this: this is not a general failure of ML, these sorts of problems can be avoided if you know what you're doing, unless your data is garbage.

That would be "amended" if we're gonna go all the way with this.

Once your test suite is big enough that it won't run within a minute or two, it's kind of hard to keep a "green on each commit" workflow, though. Especially with UI and visual diff tests in the mix, I certainly don't want to tie up my local computer for a full test run when I'm just fixing a small bug; pushing the commits in a branch and letting the full suite run against that while I move on to another task is a much better use of resources, and that's where the PR model seems most useful to me.

Are there workflows that avoid this problem but still enforce every commit being green?

Will the other tech companies be remembered for never resisting in the first place? IIRC Microsoft and Yahoo we're both like "censorship and tracking? HELL YEAH, where do we sign?" from day one.

I use several different computers and operating systems regularly, and it's really useful to have my browser history, bookmarks, extensions and other configuration synced up.

That's not to say I'd be miserable without it, but it's a nice convenience that almost immediately upon starting up a new machine, my browser is set up exactly the way I like just logging in.

Yeah...and that thread says that the change is basically nothing, just a UI indicator:

> Q: I don’t get, though — if you’re signed in to the browser but sync is off, then what does it mean to be signed in to the browser? What does it do besides sync?

> A: Not much, you can think of it like a Gmail login state indicator.

If that's fully the case, then there's nothing to see here and people are freaking out over nothing. Am I missing an important element here, other than that people don't trust Google?

I'm still not clear about what the actual change in behavior even is - seeing some statements on Twitter from someone on the dev team, it sounded to me like there isn't actually any difference, just a UI change to show which Gmail account is currently logged into.

If that's really all it is, I don't really get what people are upset about. Specifically, if there's no additional data being stored connected to your account (which is what one of the devs seemed to be very explicitly claiming) until you deliberately connect Chrome to your account, this seems like a whole bunch of drama over a misunderstanding.

If I'm wrong, then that's a separate matter. Personally, I appreciate the syncing features, but I completely understand why people would be bothered, and it's definitely something they should roll back.

The big difference between leaving a relationship and leaving a job is that even if you're in a good place, a job will never last for life. Some relationships will.

Anecdotally, I don't know a single person that has regretted leaving a job when they decided to (disclaimer: most people I know work skilled jobs). Even when people come back to the same company, it's usually on a different team and with a 30% bump in salary. So I generally agree, once you're thinking about it, it's probably time to go, you'll only end up better off.

Relationships are a lot more nuanced, hence the lesser benefit the article reports versus leaving jobs. I'd want to see it broken down by relationship length, age, happiness level and other factors before making any serious decisions based on this article.