Riffing on the idea that "productionizing a cool research result into a tool/product/feature that a substantial number of users find better than their next best alternative is actually a lot of work": it's a lot less work in larger organizations with existing users numbering in the millions (or billions).  But, as noted, larger orgs have their own overhead.

I think this predicts that most of the useful products built around deep learning which come out of larger orgs will have certain characteristics, like "is a feature that integrates/enhances an existing product with lots of users" rather than "is a totally new product that was spun up incubator-style within the organization".  It plays to the strengths of those orgs - having both datasets and users, playing better with the existing org structure and processes, more incentive-aligned with the people who "make things happen", etc.

A couple examples of what I'm thinking of:

1. substantial improvements in speech recognition - productionized as voice assistant technology, it's now good enough that it's sometimes easier to use one than to do something by hand, like setting a timer/alarm/reminder/etc while your hands are occupied with something else,
2. substantial improvements in image recognition - productionized as image search.  I can search for "documents" in Google Photos, and it'll pull up everything that looks like a document.  I can more narrowly search "passport" and it'll pull up pictures I took of my passport.  I can search for "license plate" and it'll pull up a picture I took of my license plate.  I just tried searching for "animal" and it pulled up:
   1. An animated gif of a dog with large glasses on it
   2. Statues of men on horseback, as well as some sculptures of eagles
   3. A bunch of fish in tanks

For structural reasons I'd expect "totally novel, standalone products" to come out of startups rather than larger organizations, but because they're startups they lack many of the "hard things are easy" buttons that some larger orgs have.

Protos have some relatively unique characteristics and pathologies that push me to recommend this pattern, where I wouldn't necessarily do so for other "shared dependencies" (though I think I probably still favor a monorepo in most situations).

They're fairly distinct as far as build targets go, since you often end up generating packages in multiple languages, and the relevant versioning strategy is per-build-target, not per-source-file. It is important to avoid the issues with inappropriate shared dependencies across protos that I mentioned in the article because that is one way you run into trouble with versioning, but imo the solution to that is "programmatically enforce proper separation of concerns within the monorepo".

Appreciate the recommendation.  Around April 1st I decided that the "work remotely for an alignment org" thing probably wouldn't work out the way I wanted it to, and switched to investigating "on-site" options - I'll write up a full post on that when I've either succeeded or failed on that score.

On a mostly unrelated note, every time I see an EA job posting that pays at best something like 40-50% of what qualified candidates would get in the industry, I feel that collide with the "we are not funding constrained" messaging.  I understand that there are reasons why EA orgs may not want to advertise themselves as paying top-of-market, but nobody's outright said that's what's going on, and there could be other less-visible bottlenecks that I haven't observed yet.

My guess is that it's something like "the impact of mitigating x-risks is probably orders of magnitude greater than public health interventions" (which might be what you meant by "unless you're very optimistic about X-risk charities being effective").

Was this specifically with protos?  "very weak separation between service models and clients" doesn't sound like something that'd happen with protos, since clients are generated from the service models directly.

Can you go into more detail on the specific failure modes you ran into that seemed to be downstream of everything living in a monorepo?  I agree you need to be more careful about maintaining proper separation of concerns, but I'm not seeing how monorepos would be more likely to cause versioning issues across environments.  I can imagine that if protos didn't have a build step, you might run into problems similar to e.g. dynamic linking (or resolution at runtime like with protobufjs), and it might be easier to establish a versioning strategy other than "just pull latest main, it's fine!" with separate repos, but that's typically not how protos work.  I guess there can be a similar failure mode if you tell your build system to resolve proto dependencies at build time by compiling from whatever protos are currently in the repo, instead of using a fixed published version for each target?  I might not be understanding what you're pointing at, though.

These seem mostly non-responsive to the described situation.

• Paxlovid itself is free at point-of-sale (or at least the current supply is), so there's no monetary concern.
• These patients have already been tested.
• Not only did they get tested but they tested positive.
• See "paxlovid is free".
• They already have covid, they aren't being asked to do something unusual and unpleasant to prevent an uncertain future harm.
• They're literally being offered a prescription by a doctor and turning it down.

The ladders for data scientists and data engineers tends to be comparable at these kinds of companies. If you have a quantitative PhD with an emphasis on any domain that has transferable domain knowledge (i.e. anything math/CS/econ probably counts) then you might even be able to start one step up the ladder. But even if you just learned R to do data analysis in some other field that would probably make it much easier to pick up, say, python, and hop sideways.

I should note that the junior-level compensation is probably the most difficult to attain if you're coming in from another field, since the major pipeline is "college grad with several internships gets hired start into big tech company". By comparison it's much easier to get any sort of entry-level engineering role (which is still going to pay pretty well), get a couple years of experience, then go on to one of the big tech companies. (It's not impossible to get a junior role at a big tech company straight out of the gate; I know several bootcamp grads who have done it. It'll definitely be made easier by having a PhD.)

Here are some reasons:

1. As you say, the pay is good.  But even having said that, I think most people don't understand quite how good, if you actually optimize for it (primarily in the US, though the rest of the world is catching up).  At the top decile, which isn't that hard to get to if you have some native talent and actually try, the pay bands look something like this:
   • Junior (0 - 2 years of experience): 150-200k/year
   • Mid-level (2 - 5 years of experience): 250-400k/year
   • Senior (5+ years of experience; no pressure to advance beyond this level): 350-550k/year
   • Staff (8+ years of experience): 500-750k/year
2. The work is fairly heterogenous both across and within industries, companies, and roles.  It's not that hard to find "something else" to do if you don't like the specific thing (or type of thing) that you're working on at any given moment, though hopping across some domains can require a bit more retraining than others.
3. If you like solving logic puzzles, you'll probably find the work enjoyable, at least until you grow your career to the point where you're doing less writing code and more "everything else".  At that point you typically decide whether you want to make the jump to the next level (from Senior to Staff) - you don't totally stop writing code at that point, but it's at most a small part of your responsibilities.  You don't have to make that jump if you don't want to; at most companies Senior is the "terminal" level at which point there's no expectation that you need to continue growing your skills to the next level.
4. It changes the way you think.  Many of the common abstractions and patterns used in software engineering have obvious applications for real life tasks and decisions.  If you internalize the patterns in your day job, you'll start seeing them everywhere.  Oftentimes learning something on the job will feel like a fuzzy intuition you had clicking into place, as you realize there's a formal structure for it.
5. It gives you a toolset for making your own life easier in a variety of trivial (and sometimes not-so-trivial) ways.  Not all data entry/scraping/etc is worth automating, but sometimes it is.  Custom browser extensions are something that can be very valuable if you have any sort of idiosyncratic needs or preferences in terms of interacting with the internet.

Glad to hear it!

Interesting, was this recently posted?  Do you mind if I DM you with some questions?