n0w

The author seems to have either misunderstood the API they're referencing or are assuming US only addresses. The specific endpoint they're calling seems to be for US specific zip codes.

The point stands that this doesn't "just work" for global services.

They're likely trying to retrieve source maps

Code is a specification. You cannot have a program unless you specify how it works.

This is an interesting idea. I wonder if it's more that we have different "levels" of memory instead of generally "poor" memory though.

I'm reminded of an article on the front page recently about the use of bloom filters for search. Would something like a bloom filter per-topic make it easier to link seemingly unrelated ideas?

A CRDT is any data structure that meets the definition (associative, commutative, idempotent, etc...)

Event Sourcing is not strictly designed to achieve eventual consistency in the face of concurrent writes though. But that doesn't mean it can't be!

I've also been considering an intent based CRDT system for a while now (looking forward to checking out GPs link) and agree that it looks/sounds very much like Event Sourcing. It's worth while being clear on the definition/difference between the two though!

I think the suggestion is to encapsulate global mutable state behind a strict interface (if you want global mutable state)

100%

The only point from the article I agree with strongly would be putting the keyboard away for a bit and picking up a pencil & some paper and trying out some rough sketches (though I think you can do this just as well at your regular desk)

The API surface of some struct is determined by visibility, not by whether a member of the struct is a method or a field.

I can't remember the specifics for why fields cannot be used within a Go interface but I do remember missing it a few times while writing Go code.

I can't remember where I picked it up from, but nowadays I try to be mindful of when things are "accidentally" repeated and when they are "necessarily" repeated. Abstractions that encapsulate the latter tend to be a good idea regardless of how many times you've repeated a piece of code in practice.

This all strikes me as very similar to promise pipelining and distributed capabilities from an OCap system like E.

Any code sending an outbound request in reaction to a write is causally related and could be represented as a pipelined promise. The receiving system can then proceed in its work until it needs to "await" the incoming promise and can see whether it was broken due to a failure to persist some earlier write. This could also be handled at the network layer if the receiving system was external.

I'm pretty sure I remember Kenton announcing that Cloudflare Workers now supports something like (or exactly) object capabilities and promise pipelining and his knowledge/interest in such systems is already reflected in Cap'n Proto RPC.

Very cool stuff if you ask me!

CRDTs seem to give the best experience when they correctly model the "intent" of changes.

But a diff between two different states of raw text can't convey the intent of a code change (beyond very simple changes).

This is why I think CRDTs haven't caught on for VCSes and I'm not sure they _could_ without some kind of structured editing.

This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...

TFA seems to present reasonable advice. Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.

> I don't know why the job postings make the backlog the focus of what they're looking for. I can only imagine that hiring managers and recruiters have a very poor understanding of product management, reducing it to the mere management of open issues in the backlog.

It's not just hiring managers and recruiters. A large number of senior leaders in organizations have a very poor understanding of product management as far as I can tell.

Feature factories are much easier to implement/understand and fit more neatly into traditional structures.

Maybe you're right. If so, I've only ever worked for companies with leadership that sucked at communicating.

I don't think it's that simple though. My personal belief is that leadership rarely has a good reason for obtuse decisions and following the leader seems more likely. Even if the first company has a good reason that makes sense for them, I'm not convinced the same (or any) reasoning applies to all the followers.

I also believe that the majority of the leadership at companies I've worked for are poor downwards communicators :)