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.
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!
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)
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.
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 :)
You've got more than one app sharing a db when you deploy a new version. Unless you're happy with downtime during deploys as the cost of not having to manage how your schema evolves.
These kinds of best practices make sense regardless of how many apps access a db.
Following the advice doesn't also prevent you from enforcing a strict contract for external access and modification of the data.
The more I learn about the relational model from a first order logic perspective, the more I wonder what we would have ended up with if more people thought of data/databases in this way (as opposed to the more record/object school of thought).
Event sourcing and CRDT like distributed data using something like the Event Calculus?
I don't think products necessarily accrete features because the existing users need them to do more "stuff".
Additional features tend to target new/different subsets of users in an attempt to increase the size of the user base (and thus value to the creators).
So how do you choose the "MVP" features to expose to each subset of users?
> "knowledge or lack of knowledge does not differentiate..."
I agree wholeheartedly. Knowledge, or even intelligence, shouldn't be the most highly valued skill in a team lead.
But there are many people extremely confident in their confirmation bias that seem to be unwilling to consider anything that might challenge their ideas. Our industry has a problem with celebrating the intelligent arsehole. Not only is humility not incentivized, it seems to be actively counterproductive.
I wonder how we can foster the kind of culture that values experience, encourages innovation, and is also able to get things done without chasing geese?
The point stands that this doesn't "just work" for global services.