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.

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.

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?

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).

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.

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.

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

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.

> 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?

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.

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.

One of the biggest problems with PHP, IMO, is that most of the code you'll find online is extremely old, and probably will give you terrible advice, using old deprecated mysql libraries, etc.

But to manage scalable PHP (or any language, for that matter) you still need smart programmers, a lot of whom will have been through most of the serious academic works in the field. They won't love working with PHP (I never did), and it might mean greater flight risk (yup!), but they might join the job anyways (at least half a dozen people that I know with those creds that joined up with the last project I was on where we had no choice but to deal with PHP) because of other reasons, like liking the company, people, or goals.

I've worked with a dozen different languages over the last 20 years. PHP is not one that I'd pick for a new project, but TBH, it's not the worst I've had to deal with. My experiences with the Visual Basic, Perl, and R code that I've had to interact with were actually far worse (typically because the people that code them are not as solid in software engineering), but I wouldn't judge people that use them just based on having done so. Unless we're spinning up new prototypes, very few of us actually get to choose the technologies that we use.

This is never how the companies I've been at treated culture fit interviews. Maybe I've only been at good companies, but typically we're only screening for dealbreakers and red flags, and the "culture fit" interview is little more than a chance to relax the interviewee between grueling tech interviews and have a low-pressure chance to sell them on the company; if they happen to offer up an offensive statement or shoot themselves in the foot, then that's on them.

The only situations where I've seen people cut based on culture fit questions, they've done something really odd. Comment on an interviewer's looks. Talk unreasonable shit about current company coworkers or policies, or spill confidential info. Indicate unwillingness to work with people of certain political persuasions. Outright racism or sexism. So on.

"Like to have a beer with" is a terrible hiring criteria, even if it might be useful when playing both internal and external politics. But "I'd never be willing to tolerate this personality in everyday work interactions" is a very valid reason to cut someone from consideration, and that should be considered in every interview.

Almost every toxic coworker I've come in contact with worked on a team that specifically did tech-only interviews, and didn't take culture into account. YMMV...

I'm unclear about the claim that less economic growth would be better, though, and the author seems very committed to it. I wasn't able to find the article they reference as explaining how less growth is what we really need (J.W. Forrester, World Dynamics, Portland OR, Productivity Press, 1971), and it comes from almost 50 years ago, which might as well be another economic era altogether.

Does anyone know what the arguments are, what assumptions they require, and whether they still apply today? My understanding is that "less growth is better" is a distinctly minority take amongst modern economists, but the rest of this article seems very intelligently laid out, so I'd like to dig deeper.

I've always thought that for any dial we have, there's always an optimal setting, whether it's tax rates, growth rates, birth rates, etc., and blindly pushing one way or the other (like both political parties tend to do) is not helpful, or at the very least merely indicates different value systems.

Presumably people felt the same levels of pain in the past as they do now, given the same maladies. Is the situation:

A) More surgeries with extremely painful and long recovery periods are happening, where these meds are truly necessary

B) Doctors are prescribing opiods more freely for lower levels of pain than in the past

C) People are faking pain more often

D) People who really do need pain meds are staying on them longer than they should

B) seems to be the accusation that I usually see, but have doctors really gotten worse and less careful over time? To an extent that explains the whole crisis?

My guess is that D) is the real cause, for may different reasons.