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.

Absolutely, though I'd warn that if you naively use PHP and a default setup (Apache with default settings for PHP or something like that), you're probably not going to serve as much traffic per server as a naive Python or Ruby setup will get you. You have to tune your way there, and it can be a bit of a process, but it's definitely possible, and there's nothing very subtle about it.

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.

If a company already has a large PHP codebase, then it's probably the right choice to stick with it. And it can scale just fine, easily as well as Python or Ruby if you dig into how to do it right.

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.

"What most people really mean when they say someone is a good fit culturally is that he or she is someone they’d like to have a beer with."

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

Extremely interesting take, with a lot of good stuff to think about.

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.

Opiods have been around forever; pardon my ignorance, but what is different now that makes so many more people get hooked on them?

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.

A decade ago self driving trucks existed only in thoughtspace; today they're actually being built, driven, and refined. That the old estimates we're wrong doesn't mean the tech will never happen, it's almost available right now. Long haul trips are arguably the easiest to automate, since the routes are stable and easily mapped, even if the last few miles or exceptional conditions will still require human intervention (which could be remotely handled).

Betting on widespread automation of trucking is probably one of the safest AI-related bets you could make right now.

There are dedicated reporters at a lot of outlets for each of the tech giants, I don't understand that complaint. I've talked with several of them, they show up at like every tech gathering they're allowed into, and many people at those companies know their names/faces and avoid them like the plague.

What else can you do in Seattle with absolutely zero skill or qualifications and no willingness to commit that pays that well?

Not a joke question. I'd have loved any fraction of $880 a month when I was in college and was otherwise worth nothing and couldn't get a traditional shitty part time job because I had unpredictable hours due to school.

Fair, I upvoted you because that's a wrong interpretation of what you said.

"figure something out, or die"

The Republican party salutes you, you speak their disgusting and morally bereft "truth" with extreme accuracy.

That "European presence" requirement is, by itself, an attempt to force their laws on the world, and if it's going to have teeth, will require other countries to bow to pressure to enforce it even though they had no input.

If Jamaica passed a law fining any company that hired homosexuals, we'd consider it bullshit even if they tried to abstract it a level up by only passing it as a local law, and then passing another law saying companies that serve Jamaicans have to have local representatives. I'm not sure why you think this is any less bullshitty a tactic, other than the fact that the law they're trying to push seems more reasonable (which I agree with).

Yes, and thank you, I couldn't remember the name of the book to reference it!

I think it makes a somewhat strong case; to me, the big problem to explain regarding the evolution of intelligence is the fact that it only helps survival a little bit, not a lot. And it evolved in very little time, which usually requires huge selection pressure. Sexual selection offers a potential explanation there.

Evolution wasn't trying very hard to create intelligence; it's really not that useful for survival relative to how expensive it is biologically, to the extent that some people think it's more an artifact of human mate selection and signaling (like a peacock's tail) than a proper adaptive trait.

Without a strong survival gradient pushing a population towards higher intelligence, it's actually surprising that evolution stumbled on it at all, which speaks to how easy it must be to find in solution space, not how hard.

I would be very surprised if a human-guided search can't crack the problem relatively soon - we're only just now starting to hit the threshold of computing power necessary to do it, so it's not too shocking that we haven't fully succeeded yet.

Well, "We want less traffic, build more roads" actually helps, in a way: all the additional people driving are doing so because it's more convenient than the next available option, so they're all getting real value out of the extra roads. They just don't reduce traffic as much as we'd expect. And sure, the plan results in more people driving, which is mostly a bad thing due to emissions, so it's not a great strategy, especially when alternatives like mass transit are available to invest in.

Housing is not the same. Besides the fact that it doesn't share the qualities that make traffic highly susceptible to induced demand (you've gotta sleep somewhere, whereas you can choose not to drive, or at least choose when to drive), even if the end result of building more housing is that prices stay the same, it's still a better situation. The externalities of "people sleeping indoors" are not nearly as bad as "people driving cars", there would be more people living where they want to live, less of them would have to travel to get to work, environmental impact is lower per person when they live at higher density, economic output is greater at higher density, etc.

I get that macroeconomics is not always simple, but that doesn't mean it's always counterintuitive. And let's be honest here: in the Bay Area we've been adding housing much slower than we've been adding jobs for many decades now, and the "over simplistic" econ 101 prediction that prices would go up as a result has been extremely accurate. One point for Occam's Razor.

Activists are implicitly making the argument "yeah, our counterintuitive 'build less to reduce prices' policy hasn't worked in the past, but that's only because we haven't been allowed to implement it fully and prevent any market rate housing from being built!", which is the same kind of bullshit all-or-nothing argument that hardcore anti-government types make when we point out situations where deregulation fails to produce great results. Sometimes we just need to accept that maybe there's nothing subtle going on, apply F = ma, and see if the simple solution works. Especially when we've already been trying the crazy out-of-the-box solution and it's been failing miserably.

People want more affordable housing by apartment count; activists will happily block large projects that would include sizable numbers of affordable units because they're not happy with the percentage of affordable units. The percentages that they want tend to be high enough that the projects would be unprofitable, so the end result is that 0 units get built, either at market rate or BMR.

Most YIMBYs are perfectly happy to add more affordable units, as long as the economics work out so that something gets built. Many (not all) activists would prefer to block everything than compromise.