hackeryogi

Increasingly I come across software bloated with features. I recently downloaded an app that took me through 4 screens (including a membership upsell) before I could actually use it, and even on the home screen I could barely find my way around.

I read a lot about "taste," but the taste that matters most is the users'. To me, a sharp experiment-measure cycle that measures what users actually value and not just what converts (i.e holistically measures user satisfaction), is the best way to keep what works

I'm curious, how is the data for active building construction and active street repairs sourced?

The A/B test infrastructure is. It’s easy to wire up experiments because there is always a template/recipe to do so. Multiple subsystems can be strung together (eg: Experiment arm XX in subsystem A triggers Experiment arm YY in subsystem B). Analysis is simplified too since all the core metrics are already in place and ready for analysis.

True. This was written with the context of Google which was, to a large extent and up until very recently, a good example of the resilience and magic a slime mold can be.

It is not true today, and as you mentioned "fundamentally incompatible with a next-quarter profit driven.."

To add to this, MCPs usually focus on capabilities. This is especially useful in multi-hop situations.

As an illustration, lets say I ask the agent to “Read the issue Bob posted today from Linear (issue tracker), pull relevant logs from DataDog (log tool) and suggest a fix”

In the MCP world, my agent doesn’t have to spend tokens / time understanding APIs or the protocol (as the parent comment suggests). Instead, it relies on the tool provider for the best way to “read the issue” or “pull logs”.

Same thing, in the API world, would usually involve multiple API hits (and possibly using the wrong APIs or params for them), interpreting the results and hitting few more APIs again.

Thanks for the link. Very succinct. Coincidentally, just a week back, I ordered the book it mentions.

I completely agree with everything you mentioned (And thanks for giving in numbers too!).

Since you’ve clearly thought this through, if I can push you to the hypothetical - at what point would you want to run multiple tests in parallel? Will it be largely a function of your dev team (more productive everyone) or active users (more frequent feature build outs / cross cutting rollouts) ?

Thanks again for the note. Very helpful.

Very well summed up.

In addition, same set of questions can also be asked to people who've recently left the organisation.

I'd use the following criteria to filter ex employees:

- Reliable 1st/2nd level connections

- Folks who have shown stability in the past (generally stick to jobs for > 2 years)

Obviously, they'd come with biases. But, talking 2-3 people should also help reliably gather broad culture patterns. Should avoid listening to evidently disgruntled folks.

Well written article

> DON'T BE AFRAID TO DISMANTLE THE WRONG ABSTRACTION

Couldn't agree more with the statement, though I don't completely agree with the author's suggestion to copy paste. Duplicating code _is debt_. It may help us go faster now, but it'll almost inevitably come back to bite. It is manageable if 1/2 people do it 1/2 times - definitely not manageable if 5/6 people do it 5/6 times.

I believe the general hesitation of not touching a piece of code (or, getting by with that optional param) is due to the fear of fucking things up. Having your code test covered gives an amazing amount of confidence to rip apart old abstractions to yield newer ones that serve the purpose of the _current code_. To me, this route is more preferable to duplicating code.

Even with the best of intentions, Hacking an abstraction with that one optional parameter is inevitable. Tests help in our ability to repay that debt faster - on time & in full.

Basically they make all abstractions a lot cheaper - easier to write and easier to throw away. Thereby solving the problem of having a 'wrong abstraction' too early.