anupamk

This is really neat!

The main thing that stood out to me was, unlike many other micro/minimalist blogging platforms, textlog has individual notes (as opposed to blogs) as the primary unit. I feel that this choice often makes it psychologically easier for users to post something quickly without getting stuck on managing their blog’s brand and identity. Nothing wrong with the latter, but it comes with a trade-off.

And I really like the visual design: very clean and minimalistic, but also pleasant.

Oof :)

The irony of OP championing for “taste” in the age of mass produced slop, only to then post something that was likely produced by repeatedly reprompting with “no, again”

> In an era of mass production, taste moves up the market, but it never quite goes away.

I agree with the points in your version, and the part above is the “meat and potatoes” for me.

I too am unsure about how much did the author intend to say something similar.

The main area where I disagree with the original post is this apparent fusing of subjective/personal taste driven value and market rewards driven value.

To summarize/clarify my view using the Aeron and Eames chair examples from your version

1. I agree that someone had to pursue their taste/vision for those products even when they could’ve “gotten away” with producing something mass produced and mediocre. And that pursuing their taste/vision likely became more feasible once the technology allowed them to focus on the “taste” while taking care of the boilerplate.

2. But, I will also add that the market actually saw value in Aeron and Eames chairs and rewarded their creators. It would’ve been incongruent for those creators to assert that their chairs were superior merely because they chose to pursue their taste/vision.

I found this post a bit too verbose and incoherent. It does read like AI slop to me, but the bigger issue is that its core argument itself seems flawed.

The author seems to be advocating for choosing to "carry the burden" of one's taste (or aesthetics, judgement, standards, etc) while bemoaning that the market may not sufficiently reward for doing so.

IMHO, the core flaw is in mixing these two things 1) the market rewarding what it chooses to reward; and 2) individuals choosing to pursue some external/internal rewards.

I broadly agree with the premise that Gen AI has lowered the cost of software development and, as a result, the quality of the idea and its execution have become more salient differentiators than just the ability to bring an idea to reality. I also agree that pursuing one's own sense of taste/judgment or "objective function" is often intrinsically rewarding and worth it. But ultimately, an individual has to decide how much they want to (or need to) play for the external market rewards vs their own intrinsic rewards/motivations.

But I don't think it's coherent to argue that the market "ought to" reward one for their oh-so-special but mysterious, amorphous, and unmeasurable way of doing things, or that pursuing one's own taste/judgement is somehow automatically an exercise in greatness.

This is definitely a feasible approach and I agree that it has some advantages, but I also think there's a noteworthy trade-off which should be considered.

A dedicated external orchestrator decouples application servers' API and implementation from that of the orchestrator. This comes with some advantages. It becomes easier and more natural for the application servers to organize their APIs and implementation around a stable set of domain areas (instead of operating along two different layers of abstraction -- the workflow orchestration plane, and the underlying application domain logic). It also becomes easier to understand and update workflow logic when it's managed separately as a first-class citizen as opposed it being fragmented and diffused across multiple application servers. In my experience, these advantages tend to matter more in highly distributed system involving multiple semi-independent teams owning multiple application servers and data-stores. After a certain point in terms of the size and complexity of the distributed system, the aggregate cost of handling orchestration and checkpointing workflows often starts to provide stronger justification for having dedicated centralized orchestrator.

So while I agree that letting go of the central orchestrator (and letting the application servers and data-store do that work on their own) can sometimes be the pragmatic/preferred option, I'd argue that the fit is context dependent and there doesn't seem to be a one-size-fits-all solution available.

Good points but I wonder if this applies for all the big corporations.

Yeah, the current dating scene seems complicated than it needs to be. I'd love to see a minimalistic approach, and also know how you handle the matching task.