jalospinoso

I think "how much coding?" is the wrong unit.

The better question is: how much independent judgment do you need before delegating implementation?

You should learn enough to:

- turn vague requirements into interfaces, invariants, and tests - read a diff and explain what it actually does - debug without asking the same system that wrote the bug - recognize when the architecture is wrong rather than continuing to patch symptoms - reason about state, concurrency, failure, security, and cost

That probably means learning one language deeply, plus basic data structures, databases, networking, operating systems, version control, and debugging. Not because you will hand-type every line forever, but because those are the mental models required to supervise an agent.

The curriculum should change, not shrink. Less time memorizing syntax; more time decomposing problems, reading unfamiliar code, testing behavior, instrumenting systems, and understanding failures.

I would use AI early, but periodically remove it. If you cannot build and debug a modest program without the agent, you do not yet know whether it is accelerating you or substituting for understanding.

A practical rule: on’t merge code you can’t explain, and don’t deploy a system whose important failure modes you can’t enumerate.

The uninteresting version of this is “US entity follows US law.”

The interesting version is that Web PKI is not just cryptographic infrastructure. It is also a policy distribution system. A browser trust store, a CA, a subscriber agreement, revocation rules, export controls, and sanctions law all end up in the request path of "can this site speak HTTPS to normal users?"

That does not make Let’s Encrypt uniquely bad. Any CA has some jurisdiction, owners, contracts, root-program obligations, abuse process, and legal exposure. Moving the CA changes the governance surface; it does not remove governance.

But it does mean "just use Let’s Encrypt" is not a neutral answer when protocols, browsers, APIs, app stores, or regulators effectively require TLS. The operational dependency is not only ACME uptime and certificate issuance. It is also jurisdictional continuity.

The hard product question is what failure mode we want:

1. Web PKI: power concentrates in CAs, browsers, and root programs. 2. DANE/DNSSEC: power shifts toward DNS operators, registries, registrars, and governments. 3. Self-signed / TOFU / pinning: power shifts toward application-specific trust and worse UX. 4. Multiple CAs: better resilience, but still bounded by browser trust stores and legal chokepoints.

There is no apolitical trust system here. There are only different control planes with different failure modes.

The practical ask from Let’s Encrypt should be clarity: issuance vs renewal vs revocation, existing certs vs future certs, domain location vs subscriber location, hosting location vs user location, and how they interpret “use” of a certificate. Without that, operators are left guessing whether this is a narrow compliance clause or a broad infrastructure-risk event.

[flagged]

I've been working on a field guide in working with colleagues. I'm interested if this is helpful for folks wanting a more applied view:

https://lospino.so/statistics/jensen-shannon-divergence/

Feedback welcome both from initiates (on helpfulness) and experts (on correctness)!

I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases.

Many of these differences are intentional and defensible from the C++ side. But some are still surprising because they invalidate patterns that were historically common, performant, or idiomatic in C.

The interesting part to me isn’t "C vs C++," but where the languages diverged philosophically: object lifetime vs raw storage, stronger type systems, implicit conversions, ABI and optimization assumptions, and the boundary between "portable" and "works on my compiler."

I’d also be curious which C constructs people still genuinely miss in modern C++. For me, restrict is still near the top of the list.

Yes! Going through production/printing rites now. No firm date yet, I'm guessing low numbers of weeks.

Thank you for the correction!