closeparen

VMWare was for sale in the first place because it is obviously not going to be the case in 10 years that every dentist’s office and car dealership needs 3-10 instances of Windows Server in the closet. It makes sense to sell to someone who can extract as much value as possible from it on the way to zero.

Exactly. There should be no problem having tens of thousands of stateless, I/O bound database-transaction-wrapper endpoints in the same service. You're not going to run out of memory to hold the binary or something. If you want to partition physical capacity between groups of endpoints, you can probably accomplish that at the load balancer.

Having the latent capability to serve endpoint A in the binary is not interfering with endpoint B's QPS unless it implies some kind of crazy background job or huge in-memory dataset. Even in this case, monoliths normally have a few different components according to function: API, DB, cache, queue, background worker, etc. You can group workloads by their structure even if their business purposes are diverse.

There is a point in commit throughput at which finding a working combination of reverts becomes unsustainable. I've seen it. Feature flagging can delay this point but probably not prevent it unless you’re isolating literally every change with its own flag (at which point you have a weird VCS).

Unfortunately the thought pattern “modern software development is way too complex, we need something radically simpler… I know! I’ll use Scala!” is not a thing.

>Modules cannot call each other, except through specific interfaces (for our Python monolith, we put those in a file called some_module/api.py, so other modules can do from some_module.api import some_function, SomeClass and call things that way.

This is a solution to a large chunk of what people want out of microservices. There are just two problems, both of which feel tractable to a language/runtime that really wanted to solve them:

1. If the code implementing the module API is private, it must all be colocated in one package. If it is public, then anyone can import it, breaking the module boundary. You need a visibility system that can say "this subtree of packages can cooperate with each other, but code outside the subtree can only use the top-level package."

2. If a change module A has a problem, you must roll back the entire monolith, preventing a good change in module B from reaching users. You need a way to change the deployed version of different modules independently. Short of microservices, they could be separate processes doing some kind of IPC, or you need a runtime with hot reloading (and a reasonably careful backwards compatibility story).

Culturally, America wants manufacturing back in order to increase the prestige of non-college men. Some amount of spillover to engineers might be tolerated, but if the pay, benefits, and authority are seen to mostly accrue to high-SAT-scoring engineers (just like in Silicon Valley) then a manufacturing renaissance will be considered an abject failure.

I give more of my attention than I'd like to admit to Twitter these days. But before that it was Hacker News, and before that it was Reddit, and before that it was Digg + Gawker-family blogs like Lifehacker.

I think the impulse to scroll is a feature of my own psychology, not something inculcated in me by Tech, and small web properties with simple feed algorithms are capable of feeding it perfectly well, often better than Big Tech and its data science armies.

The most legible metric in the vicinity of responsible, high-quality software engineering practice is unit test coverage. It's practically guaranteed that VPs of Engineering are reporting on test coverage to the CTO, and not implausible that he's reporting on that in aggregate to the CEO.

>I think a more fundamental way to address the problem of team A being blocked by team B is to organize the teams so as to minimize cross-team dependencies.

1. Teams or organized so as to minimize cross-team dependencies.

2. We notice that those projects which nevertheless do require cross-team dependencies are very hard.

3. We lionize and promote those who demonstrate successful cross-team project delivery and leadership.

4. Teams are organized so as to maximize opportunities to demonstrate this competency.

>accelerate the impact you can have with this new family of tools.

Tech spent the last 10 years drilling into engineers' heads that scaling your impact is not about writing more or better code, but about influencing the work of other engineers through collaboration, process, documentation, etc. Even the non-managerial "senior IC" tracks are mostly about doing this with greater and and greater numbers of people. I wonder if we will start to see recognition in career tracks for people who are actually just extraordinarily productive by themselves or in small groups, or if you'll pretty much just have to be a startup founder to get paid for that.

Our regulatory compliance regime hates it when we run non-main branches in production and specifically requires us to use feature flagging in order to delay rollouts of new code paths to higher-risk markets. YMMV.

If you can compromise an employee desktop and put a too-cheap-to-meter intelligence equivalent to a medium-skilled software developer in there to handcraft an attack on whatever internal applications they have access to, it's kind of over. This kind of stuff isn’t normally hardened against custom or creative attacks. Cybersecurity rests on bot attacks having known signatures, and sophisticated human attackers having better things to do with their time.

Even if you "make it" in the context of your career and organization, you will lose in the housing market of any metropolitan area where such careers are on offer, simply because other people were there first.

A lot of people seem to run a cluster per microservice.

Cursor’s use of grep is bad. It finds definitions way slower and less accurately than I do using IDE indexing, which is frustratingly “right there.” Crazy that there’s not even LSP support in there.

Claude Code is better, but still frustrating.

American society’s view of the importance of biomedical research is directly written down in NIH grantmaking and funding levels. It’s not looking good.

The median US pay for a man with a bachelor's degree is ~$90k. Bay Area home prices run 3-4x the US median.

I agree about the 80/20 part. On the workflow front, there’s been enormous progress from Copilot to Cursor to Claude Code just in the last 2 years. A lot of this is down to the plumbing and I/O bits rather than the mysterious linear algebra bits, so it’s relatively tractable to regular software engineering.

I’m not following. It seems straightforward enough, and consistent with both charts, that a dramatic speedup in coding yields a more modest improvement in overall productivity because typing code is a minority of the work. Is your contention here that the LLM not only documents, but accelerates the thinking part too?

Which part of the third chart do you disagree with?

>First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down

Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.

It's "anti-AI" from the perspective of an investor or engineering manager who assumes that 10x coding speed should 10x productivity in their organization. As a staff IC, I find it a realistic take on where AI actually sits in my workflow and how it relates to juniors.

Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck.

People get over this and even grow to appreciate it from the perspective of the production code, but from the unit testing side it’s been an unrelenting nightmare from the time I started using the language professionally ~10 years ago until we got Copilot.

It’s total slop. Perfect for the slop generating machine.

I have to work in a very explicit, verbose language where we are expected to write mostly mock-driven unit tests to a 95% coverage standard. Although I would prefer to use a nicer language and adopt a more nuanced testing strategy, I find that for the situation I'm actually in, AI increases tractability by a lot.

>When (not if) the database becomes an attribute store across a wider scope, the implications are scary.

Penury and deportation are quite a bit of scope already! Maybe they'll put an "arrest" bit in there. Warrants are already a thing. I don't see the UK going in for murder just yet. What's left?

It has been obvious for at least 10 years of "digital privacy" as an issue that the next time people with certain database attributes would be restricted from full participation in society or rounded up by armed men, the attributes at issue would be citizenship and immigration status.

This moment is the test for the edifice that the privacy advocates have built in all that time. We should all be watching closely.

San Francisco continues to use trolleybuses (powered by overhead wires) after the most of the country has moved onto hybrid and battery-electric vehicles because the energy demands from climbing hills are beyond at least the earlier generations of batteries.

Nothing stops me from implementing a Thrift or gRPC handler that uses a field from the request to look up an object in a hashmap and then call one of its methods with data from the request. But a distributed object system will do this implicitly on my behalf, so that the programmer’s perspective is like passing objects (by reference) over the network.

CORBA is trippier than that. A client’s request could include elements not normally serializable, like callbacks. A server could provide an object in response to your query and then continue mutating it, with the mutations reflected (effectively) in your address space, without your knowledge or participation.

"RPC" originally referred to a programming paradigm where remote calls looked just like any other method calls, and it might not even be any of the programmer's business whether they're implemented in-process or on another machine. This obviously required wire protocols, client and server libraries, etc. to implement.

There's been a renaissance in the tools, but now we mainly use them like "REST" endpoints with the type signatures of functions. Programming language features like Future and Optional make it easier to clearly delineate properties like "this might take a while" or "this might fail" whereas earlier in RPC, these properties were kind of hidden.