News flash: funding is easy when you’re profitable.

But I do think he’s generally correct. Of course there’s a quantum of VC funding that is only possible in California but that’s focusing on the 1%. There’s plenty of VC in EU now.

Most of my clients want a tech stack that is FOSS to the greatest extent possible since the cost of vendor lock-in can be crippling.

Explicit legal guarantees yes for sure, enterprise will pay for “FOSS as a service” since that comes with SLA’s and means they don’t need or don’t need as large an internal platform team.

But a system of systems composed of MIT and Apache-2.0 components… it might sound ironic but that commands a premium when it’s a proposal for a large enterprise. You’re giving them the guarantee that they can walk away if they want to and you can charge for that.

After all, they should know how to compile their software. Any automation of that process is cheating their employer.

Eg it’s known they had Stone Age technology and prepared spear tips etc by flaking stone. I assumed that it was assumed those spear tips went on the end of a stick.

The key is to have clear specs and clear architecture, and then have agents enforce this.

I devote most of my time to specs and much more of my time to e2e and integration tests.

I find a lot of value, even more value than before, in strictly hexagonal designs and even a large does of DDD.

Following these principles, it’s relatively easy to design systems of systems that decompose to domains that decompose into use cases / ports / adapters.

By the time you’ve decomposed to this level, AI is very capable and it’s easy to review or verify by tests. I am very comfortable with AI verifying if a basic CRUD port is functional, for example, because at this point each operation becomes less than a dozen lines of code.

Stop thinking of yourself as a programmer and start thinking of yourself as an architect.

The key rule is that decomposition of a problem into smaller problems is what wins. This was always true, extremely true before AI and extremely true with AI.

Focus your individual effort on the top-level decompositions and let AI handle the lower-level decompositions. Trust AI to test the lower-level and make sure you test the higher levels.

Like remote-access for tech support, but lighter and less exposed.

Someone is having issues with the website? Samewindow.com allows support or their collaborators to use the same browser window.

Browse together with samewindow.

Learn code.

Write a web server. Run it on Linux.

Make it available to the world.

You’ll learn quickly.

But does Iran need to suffer less than the USA to win here?

The stakes for Iran and its regime are survival. They’ll suffer a lot of pain if it means staying alive and in power.

The stakes for the US are a lot less than survival, as a nation or as a regime.

Iran doesn’t need to make the US suffer more than Iran can bear. Iran needs to make the US suffer more than the US can bear.

It’s an idea that can be checked, empirically, and it has been.

There are studies of patch releases that show patch releases introduce new bugs _only_ 15-25% of the time.

Which is not a small failure rate, sure, but that still means that a priori you are much more likely to become less vulnerable by blindly installing patches than by blindly not installing patches.