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.

These are called "tagged templates": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> 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'm not convinced.

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?

Oh, hey. That's cool. I hadn't realised Douglas Crawford worked on E. I haven't actually looked but I wonder who else participated?

E had some really cool ideas, it's sad that it doesn't seem to be that well known!

> "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?

As someone interested in pursuing similar ideas I would recommend taking a look at Object Capabilities and the E Language if you haven't already.

I believe Sandstorm.io (and Cap'n Proto) at least adopts some of the ideas.

I came across this after seeing relic[0] submitted the other day and thought it was pretty interesting.

I've been into CRDTs for a while and have started wondering about generic mechanisms for distributed data. This lead me to read a lot more about the Relational Model of data and eventually to the Event Calculus.

What's interesting to me is that these things end up feeling a lot like CRDTs[1] or Event Sourcing. I haven't quite finished pulling on these threads but the relic link was a timely read considering!

I really liked the first half of this paper and the Authors categorization of complexity. However the second half fell a bit short for me. It seems they made the same mistake as many other people (SQL != Relational) and their idea of Feeders and Observers seems a bit more like an escape hatch than an elegant method for interfacing with the outside world.

[0] https://github.com/wotbrew/relic [1] http://archagon.net/blog/2018/03/24/data-laced-with-history/

Thank you for taking the time to reply so thoroughly, this seems like very actionable advice. Sounds like it's going to take a lot of effort to put into practice, but that it'll be effort well spent!

This is something I really struggle with. I think this difference of perspective is one of my greatest strengths, but in the last few places I've been I ended up burning out trying to get others to see the same things.

Have you got any tips or advice for getting better at "persuasive education" or inspiring others to see the same things?

I enjoyed the article, but I found the description of taste a bit nebulous.

I think part of it is the knowledge and experience you base your expectations/perspective on.

I would argue that there is a subjective aspect to taste that is determined by your personal/technical values. Having different values doesn't mean you have bad taste, it means you're optimising for different things.

If you find yourself in an environment where you're unhappy because things don't match your taste, you might value different things. This doesn't necessarily mean anything is wrong or objectively bad.

I think it's useful to frame things in this way because it can prevent you from dismissing the opinions of people that value different things.

Diversity of opinion and perspective is a good thing to a certain degree. Lack of a common set of shared values is probably a breeding ground for conflict though!

> Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it already. If they could have done it but didn’t, it’s because the problem doesn’t matter much.

You talk to customers to better understand the problems they face and how valuable a solution might be.

Not for ideas or suggestions.

Once you've built a thing, you talk to customers to understand _how well_ your thing solves their problem.

None of this necessitates incremental solutions.

`system-ui` can be useful on modern browsers and I'm looking forward to more browsers adding support for the `ui-*` variants: https://caniuse.com/extended-system-fonts

At the end of the day I'm a developer, not a designer, so I'm not confident to speak to the art/design side of typography.

Having said that, I believe that art (and design) requires intention and thus some amount of "reasoning".

Sure, if you put things too close together they will intersect/overlap.

This isn't an inherent problem of the technique though. You should be giving things enough space so that this kind of thing doesn't happen. It should be pretty simple to check that the smallest unit of space used anywhere isn't smaller than the amount being trimmed from the top/bottom of the text box.

We've started trimming the whitespace from the top/bottom of blocks of text so that the bounding box is effectively from the top of the cap to the baseline.

Mark Dalgleish describes the technique in this video (around 9:45) https://m.youtube.com/watch?v=jnV1u67_yVg

It's made it a lot easier to reason about the layout of text compared to other elements on the page and achieve more consistent use of spacing.