I was setting up a retreat venue, and they were pretty weird and special beds—such that if they would’ve actually worked, it would’ve pivoted our strategy for setting up the space in a somewhat major way.
jacobjacob
Karma: 4,294
You mean money or social capital?
I think it depends on scale. If Ford produces cars in batches of 100(? 1000? more?) they probably can’t rejigger the factory. In this case it was a local ironworker who probably had 10 or fewer guys working his shop, so a bit more flexibility.
How I buy things when Lightcone wants them fast
Yes, show up uninvited. That happens a lot in our slack. Our team is small enough that most people read most channels.
Can confirm Lightcone is very chaotic and sometimes works heroic hours, and it seems tangled up in our way of working for reasons that are not super clear to me.
So when reading your comment I was asking myself why the above template couldn’t be run by a project that wanted to work closer to 40 hours rather than 80 hours per week? One answer is that “Well, if people are importantly blocking elements, they must be available to reply on slack and unblock other people whenever”, which is mostly true for us, except that 1) we almost never wake up people who are sleeping :) and 2) if people sign-post they are taking a rest day or going on vacation others usually try fairly hard to find a way to solve problems without contacting them.
For what it’s worth I don’t consider this essay to be about “ops” that much. Also lots of people keep calling much of what Lightcone does “ops”, but we often really don’t think of ourselves as doing ops that much :) Some words that sound to me more like the thing I think of Lightcone as doing, most of the time: “uncertainty reduction”, “product discovery”, “trying to doing things fast”.
I might write up rants about hiring at some point, though I don’t think I’m particularly experienced or great at it :) For now I’ll just say I like YCombinator’s content on this. Not sure how to find all the relevant essays and videos, but this might help https://www.ycombinator.com/library?categories=Hiring
Things I’ve read / advice I’ve gathered that influenced me a lot, are:
Paul Graham’s essays and YCombinator’s startup philosophy
lean manufacturing philosophy
Elon Musk’s operational principles (there’s a ton of junk content about this online, but I’ve been able to find some good first-hand accounts from people who work at tesla and spacex, as well as probably the single best piece of content, which is the 2-3h starbase tour https://www.youtube.com/watch?v=t705r8ICkRw ). Tesla also has a “25 Guns” team that runs on a to-me very similar philosophy
first-hand or second-hand conversations with the founders of FTX
honorary mention, because it’s not advice inasmuch as a benchmark: https://patrickcollison.com/fast
I don’t have that much experience, so don’t want to say too much. But I think it should apply well to things like startups searching for product-market fit (you’re rate-constrained by how fast you can figure out what people want), or a factory increaseing how many widgets they can output per day, but less well to e.g. teams that are trying to maintain a system, like a gardener, or a janitorial service.
I think this post makes sense from a “theory of constraints” perspective: if you’re pursuing a mission that’s no faster than some identifiable step, and the best thing you can do each week to move faster toward your mission is mostly about speeding up that step.
The lame answer: yeah, it does mess with deep work, and I’m not super sure how to balance them.
The spicy answer: I have an unwritten polemic entitled “Against Deep Work”. I can’t share it though since I have not written it. Fortunately, much of what I hope to say in that post is captured in Chapter 9 of the Lean Startup, which has a section that resonates a lot with my experience. I’ll just go ahead and quote it because it’s so damn good (starting on page 191 in the linked PDF).
Imagine you’re a product designer overseeing a new product and you need to produce thirty individual design drawings. It probably seems that the most efficient way to work is in seclusion, by yourself, producing the designs one by one. Then, when you’re done with all of them, you pass the drawings on to the engineering team and let them work. In other words, you work in large batches.
From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that’s the theory. Unfortunately, reality seldom works out that way.
Consider our hypothetical example. After passing thirty design drawings to engineering, the designer is free to turn his or her attention to the next project. But remember the problems that came up during the envelope-stuffing exercise. What happens when engineering has questions about how the drawings are supposed to work? What if some of the drawings are unclear? What if something goes wrong when engineering attempts to use the drawings?
These problems inevitably turn into interruptions for the designer, and now those interruptions are interfering with the next large batch the designer is supposed to be working on. If the drawings need to be redone, the engineers may become idle while they wait for the rework to be completed. If the designer is not available, the engineers may have to redo the designs themselves. This is why so few products are actually built the way they are designed.
When I work with product managers and designers in companies that use large batches, I often discover that they have to redo their work five or six times for every release. One product manager I worked with was so inundated with interruptions that he took to coming into the office in the middle of the night so that he could work uninterrupted. When I suggested that he try switching the work process from large-batch to single-piece flow, he refused— because that would be inefficient! So strong is the instinct to work in large batches, that even when a large-batch system is malfunctioning, we have a tendency to blame ourselves.
Large batches tend to grow over time. Because moving the batch forward often results in additional work, rework, delays, and interruptions, everyone has an incentive to do work in ever-larger batches, trying to minimize this overhead. This is called the large batch death spiral because, unlike in manufacturing, there are no physical limits on the maximum size of a batch. It is possible for batch size to keep growing and growing. Eventually, one batch will become the highest-priority project, a “bet the company” new version of the product, because the company has taken such a long time since the last release. But now the managers are incentivized to increase batch size rather than ship the product. In light of how long the product has been in development, why not fix one more bug or add one more feature? Who really wants to be the manager who risked the success of this huge release by failing to address a potentially critical flaw?
Overall I think deep work is sometimes important. But other times it’s just a symptom that you’re in a large batch death spiral; and changes that enable you to have more deep work will also trap the organisation harder in the death spiral.
How my team at Lightcone sometimes gets stuff done
There’s at least one hotel in Berkeley with rooms for $500/night or more, and I claim for the better hotels it is quite rare that you can get them for <$200. As evidence, you can select some dates and look at the hotels here: https://maps.app.goo.gl/pMwuNQoZVJzV9Kx77
I’m not sure, but I think I might have seen a sign in a rose garden room with a $500 rack rate. Second floor building B. I found it quite funny given how far from the current state it was, it read like a decades old relic of what the Inn once was.
Curated.
There are really many things I found outstanding about this post. The key one, however, is that after reading this, I feel less confused when thinking about transformer language models. The post had that taste of deconfusion where many of the arguments are elegant, and simple; like suddenly tilting a bewildering shape into place. I particularly enjoyed the discussion of ways agency does and does not manifest within a simulator (multiple agents, irrational agents, non-agentic processes), the formulation of the prediction orthogonality thesis, ways in which some prior alignment work (e.g. Bostrom’s tool-oracle-genie-sovereign typology) does not carve at the joints of the abstraction most helpful for thinking about GPT; and how it all grounded out in arguments from technical details of GPT (e.g. the absence of recursive prompting in the training set and its implications for the agency of the simulator).
I also want to curate this piece for its boldness. It strikes at finding a True Name in a domain of messy blobs of matrices, and uses the “simulator” abstraction to suggest a number of directions I found myself actively curious and cautiously optimistic about. I very much look forward to seeing further posts from janus and others who explore and play around with the Simulator abstraction in the context of large language models.
At first glance of seeing this, I’m reminded of the safety questionnaires I had to fill out as part of running a study when taking experimental psychology classes in undergrad. It was a lot of annoyance and mostly a box ticking exercise. Everyone mostly did what they wanted to do anyway, and then hurriedly gerrymandered that questionnaire right before the deadline, so the faculty would allow them to proceed. Except the very conscientious students, who saw this as an excellent opportunity to prove their box ticking diligence.
As a case in point, I might even point to the arXiv paper you cite that has an x-risk sheet at the end.
In short, this could help resolve matters of fact that influence policies and decisions made by political leaders in an increasingly complex modern world, putting humanity in a better place to deal with the global turbulence and uncertainty created by AI systems when they rapidly reshape society. A fuller motivation for “ML for Improving Epistemics” is described in Hendrycks and Mazeika (2022).
I think that for most AI papers that come out you can find a corner case at this level of abstraction where that paper helps with x-risk, basically regardless of whether it actually does. For what it’s worth, I spent about 2 years of my life working full-time on building a platform where top forecasters attacked AI questions, and wrote what I believe at the time was the most well-written database of forecasting questions on AI. I eventually stopped working on that, because I believe the work didn’t really matter for alignment.
(So, overall, I’m pretty worried that, if used frequently, these kinds of spreadsheets will mostly increase safetywashing, because they’ll mostly make lots of researchers talk about safety even though they have nothing to say, and there’ll be pressure toward saying that their thing helps with safety.)
If someone asks what the rock is optimizing, I’ll say “the actions”—i.e. the rock “wants” to do whatever it is that the rock in fact does.
This argument does not seem to me like it captures the reason a rock is not an optimiser?
I would hand wave and say something like:
“If you place a human into a messy room, you’ll sometimes find that the room is cleaner afterwards. If you place a kid in front of a bowl of sweets, you’ll soon find the sweets gone. These and other examples are pretty surprising state transitions, that would be highly unlikely in the absence of those humans you added. And when we say that something is an optimiser, we mean that it is such that, when it interfaces with other systems, it tends to make a certain narrow slice of state space much more likely for those systems to end up in.”
The rock seems to me to have very few such effects. The probability of state transitions of my room is roughly the same with or with out a rock in a corner of it. And that’s why I don’t think of it as an optimiser.
An update on this: sadly I underestimated how busy I would be after posting this bounty. I spent 2h reading this and Thomas post the other day, but didn’t not manage to get into the headspace of evaluating the bounty (i.e. making my own interpretation of John’s post, and then deciding whether Thomas’ distillation captured that). So I will not be evaluating this. (Still happy to pay if someone else I trust claim Thomas’ distillation was sufficient.) My apologies to John and Thomas about that.
Sorry for late reply: no, it does not.
Hard to give a general answer, but I think 2x someone’s normal salary (especially if it’s cash) is usually quite sufficient to get the job done, and kind of reliably has helped me in the past when I’ve try to find people happy to work night shifts