It's an abstraction layer w.r.t. how you write code, not an abstraction layer in the live system. An IDE is a higher abstraction than e.g. vi but it doesn't mean you don't have to go low-level sometimes.
That’s not a bad thing though — what that means is that the original dev believed this could never happen and probably therefore could not decide exactly what the right way to handle the error is.
Writing is already amenable to many different levels of abstraction, though. If an LLM can expand your outline into writing, then you aren’t writing at the correct level of abstraction in my opinion; you should instead be explaining how you arrived at your chosen outline. You don’t need to explain the details because any party can generate those with an LLM; same as how many PRs today can be auto-generated and no one needs to read implementations; that is no longer the correct level abstraction to work at. This should actually free us to do work at a higher level of abstraction —- more consideration of strategy, objectives, etc and less worry about implementation details.
Math is based on axioms because you need some a priori axioms to do logical deduction, but the axiom selection is also historically fluid. Mathematicians suggest new axioms or move away from old axioms based on their understanding of which results are intuitive or not, and also which are most useful, and most mathematicians that work close to the axioms have some view on how “correct” or not various axioms are. As evidence of this, I’d point to how many mathematicians find the axiom of choice problematic due to results that seem clearly “wrong”, but nevertheless accept it because they need it to prove other things that seem obviously “right”. So the axioms are not the base truth, there is some platonic ideal of mathematics beneath that.
We try to spread out sandboxes evenly across the cluster (at least, across the workers which are available to take new sandboxes) to minimize conflict. But in general we don't get close to saturation thresholds so high that conflict becomes a problem, except during massive load tests. I suspect we'd see issues around 90% effective utilization.
We make a probabilistic routing decision based on worker load and attributes of the sandbox request. I compare to a load balancer because it's essentially just forwarding an HTTP request.
I'm a huge scheduling nerd, and the container scheduling system in this post is probably the most impactful system I've worked on. It's quite different than existing solutions, and I personally feel it's at an interesting point in the design space -- very distributed, no strong consistency anywhere, and oriented towards massive scales. Would love to hear feedback and thoughts!
The PM’s job in this situation is to articulate some sort of high level strategy generalizable across customers, based on information gathered from customers, which includes feature requests but is more than just that.
The skillset is different. SAs everywhere I’ve worked are solidly salespeople. They can do AE work in a pinch, they use Salesforce, they know how to understand the state of an account, etc. They tend to be more limited technically and as such are generally deployed for the sale of a product which is “finished”, and as such spend most of their time mapping customers onto existing patterns that are already known to work, and identifying those patterns.
FDEs are different in that they’re deployed to sell and integrate products which are unfinished in some way. For example Palantir sold a fairly low-level generalized product which required bespoke technical work to integrate with a customer. This integration work is more like normal engineering work in that lots of code may have to be written and there’s technical creativity required. The reason why FDE is increasingly in vogue now is because AI companies haven’t yet found a high-level product shape which is generalizable across many customers, because the market is immature and customers probably don’t know what they want. So there’s lots of engineering work required to take a lower-level offering (e.g some sort of agent) and figure out how to use it to generate value for one particular customer.
Is the point of math really to prove the statement? Arguably interesting, unproven statements are interesting often specifically because they are hard to prove with existing techniques.
It definitely is at the youth level. I don’t think any football or basketball pros could be soccer stars, but absolutely there are kids who are star point guards on their youth basketball team but top out at 5’8”, or football players who never make it past high school but could have been great at soccer.
AI is only eating some of that though. For instance, everyone who does performance work knows that perhaps the most important part of optimization is constructing the right benchmark. This is already the thing that makes intractable problems tractable. That effect is now exacerbated — AI can optimize anything given a benchmark —- but AI isn’t making great progress at constructing the benchmark itself.
I agree with this — there is at least some bifurcation by skillset and capabilities. Lots of engineers are overfitted to working on consumer web apps or SaaS products, but those are no longer an area of focus. You need to be adaptable enough to work on other kinds of systems too. Doing so either requires that you’re really good commercially (can lead development of a product over time, drive revenue, etc) or very good technically at a wide breadth of technologies and problems.
What makes this more extreme is that we’re in a paradigm shift, technically. Systems of the future look different than what’s been built before. Building agentic stuff is very different than web apps. The infrastructure side is also different. Moreover, both are uncertain so there’s no plug-and-play set of skills that would fit into any company in the way you could probably get hired reliably in the 2010s if you can operate Kubernetes, design a database schema, write Node.js APIs, etc.
Context windows are a natural improvement, but new architectures are completely speculative and it’s unclear we can make any sort of predictable progress with new, better architectures. Most progress has been made on essentially the same architecture paradigms, although we did move from dense models to MoE at some point.
You said above that our country “needs the best engineers and doctors.” Are the tests you mention really objective, direct measures of which student is likely to be the best engineer or doctor in the future? What does it even mean to be the best engineer, and how do you test that?
Depends on the team — managing can be quite a bit more scope than being a senior IC, depending on expectations for that role. You have broader ownership of technical outcomes over time, even aside from the extra responsibility for growing a team. Managers have all the responsibility of a senior engineer plus more. In that way manager feels to me like a clear promotion to me. Manager vs staff eng, maybe not though.
I don’t agree with that though, plenty of places practice agile well. Maybe big corporations don’t practice it well, but startups often do agile correctly and understand the philosophy.
I think the primary benefit of LLMs for me is as an entrypoint into an area I know nothing about. For instance, if I’m building a new kind of system which I haven’t built before, then I’m missing lots of information about it — like what are the most common ways to approach this problem, is there academic research I should read, what are the common terms/paradigms/etc. For this kind of thing LLMs are good because they just need to be approximately correct to be useful, and they can also provide links to enough primary sources that you can verify what they say. It’s similar if I’m using a new library I haven’t used before, or something like that. I use LLMs much less for things that I am already an expert in.
Big companies hired a lot, but I don’t think this specifically is true? In theory a high-value engineer would be productive, or else they aren’t worth stealing.
The simpler explanation seems more correct here — there was a lot of product fluff and a lot of headcount allocated to build that fluff.
What does it mean for someone’s model of the world to be accurate? My experience with mild depression is that you notice many negative things which are true but then lack perspective about how much they matter. When you feel better you just don’t pay any mind to these negative things.
It’s probably also the case that being physically fit and healthy helps one think more clearly. Carlsen notably spends a lot of time on physical health in addition to prep.
Doesn’t that imply an interface is necessary though, so you can compile (and potentially release) the components separately? I don’t use .net but this sounds quite similar to pulling things into separate crates in Rust or different compilation units in C, which is frequently good practice.
Reading between the lines, my guess is that the standup was the only forum for communication that the team had, and lots of communication was required because people weren’t working on the same things. The only real solution to that is to get people talking outside the standup.
I don’t think this is because of AI. Rather, it seems a continuation of a shift which has already been occurring for my entire career, which is that the tech industry continually sheds people whose skills are entirely practical and are tied to a specific era or regime of technology. For instance, at one point, there were webmasters, but now those jobs don’t exist anymore. Sysadmins have gone through a similar struggle with the advent of the cloud. Once there were sysadmin jobs, and now there are no more. Today it is happening to a certain kind of full-stack engineers specializing in technology of the last 15 years. In the future it will probably happen to YAML engineers who specialize in Kubernetes and GitHub Actions.
Consistently the most durable roles seem to be those which require theoretical understanding of the fundamentals —- UI/UX, systems, algorithms, etc. It’s unfortunate that not everyone gets a chance to learn these things.
You're right -- we do relax the integrality constraint, gaining performance at the expense of some precision, and we're generally able to paper over the difference at scheduling time. We've investigated integer linear programming for some use cases, but for solves to run quickly, we have to constrain the inputs significantly.
Great to see this post here -- really enjoyed writing it! I think it's really cool how an algorithm from an operational research context can play a critical role in a high-availability large-scale cloud service.
Sure, but without an LLM, measuring customer retention might require sending a request over to your data scientist because they know how to make dashboards, then they have to balance it with their other work, so who knows when it gets done. You can do this sort of thing faster with an LLM, and the communication cost will be less. So even if you choose the wrong statistic, you can get it built sooner, and find out sooner that it's wrong, and hopefully course-correct sooner as well.