The teddy bear, with his little poignant voice: “That’s probably because you’re storing post references in Mongo.”

Then, if the business domain is complex enough to genuinely need to persist a lot of JSON somewhere, with actually no need to maintain relations between the JSON... MongoDB can be a great storage for that. It's just unlikely to work well as the _main_ DB for everything.

The point is that it's not common to be able to build a product that can be fully modelled as pure JSON documents, without relations. If it actually can, sure, go with MongoDB. Or DynamoDB.

What most of those business domains really needed was a relational DB. With the ability to support a bit of JSON on the side.

Yes, but that's an extreme case. Most MongoDB deployments I've seen, especially in startups, were based on the idea that all their data could be JSON. MongoDB and nothing else. That approach always underestimates the relations between the JSON documents.

It's the middle of the night, and you hear a rhythmic thumping sound from the cabinet. As if a little furry paw were banging against a sheet of metal. A little voice reaches you. "Are you relying on informal foreign keys in your JSON, Ti?" More banging. "I know what you've done, Ti."

The teddy bear replies: "maybe, but flexible data models can be supported with Postgres and JSONB, and most data sooner or later becomes relational. Maybe not today, maybe not tomorrow, but it will." The teddy bear turns and stares into the distance. "Somehow, it always does."

I think that I’d be interested in a stuffed teddy bear powered by a LLM fully trained on Stack Overflow and technical blogs. I’d keep it on my desk and rubber duck with it. Sometimes I’d give it to a child, and the teddy bear would always, inevitably, end up saying you should never use MongoDB.

The real question is whether younger people entering the industry (and learning the trade via AI tools) are learning the skills to debug this sort of problem. Chances are that the engineers working on this have learned by hand how to navigate this sort of problems.

I think you can run other apps even while Finder is in a bad state (i.e. a terminal). Or he could have gone in the garden and stare at the clouds.

Curious about in which directory you ran Claude Code. In other words, what context did it have access to?

That’s a good point. @gergely.pragmaticengineer.com, was that an “active” 10 iterations over 30 minutes, or was it fully hands off for you?

Indeed. As someone who’s lived in several countries, the HMRC and gov.uk sites in general are much better than what they have elsewhere.

I remember how in the mid 2010s, Government Digital Services (GDS) in London had become a hub of tech talent. So many great folks from the London tech scene ended up there. They built some pretty solid stuff that often went uncelebrated because public service is just not as glamorous as a startup.

Not sure if this relates to what I was saying, but I'd say yes, it applies to most languages and ecosystems. With caveats. Pulling in a dependency for something trivial (npm left-pad) is a liability, but reimplementing something complex like crypto instead of using an OSS lib is also a liability.

Freedom to develop and try tools is good. See Yarn vs npm. Or Bundler vs RubyGems. Or Gradle vs Maven vs Ant. But in Python it looks like the _default_ is bad and everyone seems to dislike it. This leads to ecosystem fragmentation. And to arguments about which build tool to use.

I get how each tool improves upon the older ones, and I understand the gaps in tooling and DevEx that the community is working to fix. But it's also surprising that Python itself hasn't adopted and crowned one as the official tool (to replace pip), and set the goal to support and maintain it.