jbmsf

Love it.

I've been using MotherDuck as a data warehouse for some time now. No regrets.

Especially, don't do this for interactions that aren't core to your business. Under the real world constraints where I work, this kind of design thinking causes non-core features to explode in complexity, cost, etc.

Spend your complexity where it has an impact!

Hallelujah.

Thanks for the pointer to SLOs; I've read more than a few posts about them but it never clicked, will look more closely.

My point, I think, is still that the overwhelming focus of the tools I've seen focus on the kind of fine-tuning/setup you are describing and not the things that I find most valuable. And I think that part of the problem is that it's easy to build technology around mechanics than judgement.

I have some thoughts here.

I work for a startup; we have what I think is a fairly typical setup: metrics ingested from a variety of sources, fed into industry-standard metrics/dashboard solutions, triggering escalations to humans. It's fine and I'm happy we have it, but...

The highest value source of alerting right now is one of our growth marketers who pays close attention to our CRM and product analytics tool and notices when key product funnels are underperforming.

Our next highest value signals are a handful of ad hoc alerting channels, mostly in Slack, either directly from a partner telling us that something suspicious happened on their side (think: fraud) or from in-product instrumentation sent to a channel for non-engineering visibility. Members of our business/product/operations team pay attention in these places and make decisions based on their business context.

After that, our support team is increasingly able to filter customer issues and differentiate between bugs, missing features, etc.

I know someone is going to argue that these are all a sign that we haven't instrumented the right things. Fair, but also misses the point. The decision makers in these flows don't (and won't) live in traditional alerting systems and wouldn't have helped us understand breakages without these other, ad hoc processes.

My theory is that it's relatively easy to offer a technical product that moves alerts around or that manages escalation paths. It's quite hard to design a product that surfaces detail to a non-technical export and that makes it easy to build systematic rules.

We stumbled across much the same thing building out a query layer of composable join clauses. In previous efforts at something similar, I've used CTEs, but found the ergonomics worse because the query layer had to differentiate between cte clauses and regular ones.

Basically, I reached out to existing relationships. A few had needs I could fill. A few referred me to others.

I'm not sure about "without changing code" but I have definitely seen the believe that Figma represents something authoritative about the product instead of, say, the product being authoritative for itself.

Perhaps because I have a similar bio to yours, I am allergic to this view.

I laughed hard at the IV part.

That was my first thought as well.

QA should exist.

QA should not be forced into an engineering or automation track because the incentives are wrong. You end up with test code becoming the goal and then it usually rots due to most QA not having the experience to create a codebase that scales.

I don't think the industry today understands how to treat QA and I think that leads to a lot of assumptions that it's not useful.

I get excited because I went to school with one of Vaughan Jones' children and was (and still am) into math and was blown away when I understood that he was significant.

Years and years ago (pre-smart phone), I built a mobile map and navigation product. Labeling streets was one of the more interesting side quests and the solution I found took a similar approach of generating a large number of candidates, picking one solution, and iterating. It worked quite well in practice.

Thanks. I've been meaning to write one of these for a long time, but you went into detail in a very effective, organized way.

I also reached a lot of similar decisions and challenges, even where we differ (ECS vs EKS) I completely understand your conclusions.

I can't speak to the accuracy, but I just integrated stripe's offering for our product (which involves banking). We were small enough for a while not to need it, but eventually the fraudsters find you.

If you don't take these measures, you will lose money to fraud. You may also lose your business because you aren't meeting your AML/anti-terror obligations. (I also just had to take my annual training course).

There are a bunch of mitigations, of which identity verification is just one, and all of them are lousy for our good customers. I wish the banking systems were better and we didn't need to do any of it.

I like the idea but I think it's going to be hard to put this particular genie back in the bottle. As an engineering leader, I prefer low fidelity designs early on, but practically no one else in my company wants that.

Designers have learned figma and it's the de facto tool for them; doing something else is risky for them.

Product leaders want high fidelity. They love the AI tools that let them produce high fidelity prototypes.

Some (but not all) engineers prefer it because it means less decision making for them.

I feel this way now, but with companies.

I started in this industry before cloud was a thing. I did most of the things RDS does the hard way (except being able to dynamically increase memory on a running instance, that's magic to me). I do not want that responsibility, especially because I know how badly it turns out when it's one of a dozen (or dozens) of responsibilities asked of the team.

Meh. The end of the company many of us admire was a combination of the founders giving up control to the usual villains and the venture business model failing for developer tools. I don't think the specific departure date matters very much; things started to degrade earlier.

As for "slapping a company on it", I agree, but also I don't think we've developed a viable alternative. Python has been limping along with one toolchain or another for my entire career (multiple decades) and it took Astral's very specific approach to create something better. It's fair to ask why they needed to be venture backed, but they clearly are and the lack of successful alternatives is telling.

You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.

We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff.

It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.

I assume they want us to pay for their orchestration and also push customers back to using their compute so everything is stickier.

But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.

I see: a page offering something interesting but vague.

If you tell me more, I might sign up. If I have to create an account first, I'm walking away.

It looks a lot like a CloudFront error we randomly saw today from one of our engineers in South America. I suspect there was a small outage in AWS but can't prove it.

I agree. I find LLMs a bit overblown. I don't think most people want to use chat as their primary interface. But writing a few agents was incredibly informative.

As an engineer, I like this framework but can think of approximately zero PMs who could use it to build a product.

Bartleby was right.

We have a recent hire who comes from a background where a) the user base was much larger and b) metrics were the best way to understand outcomes.

Our company is smaller and earlier than that. I enjoy the focus on metrics, it's a good push for us, but sometimes you just have to do the obviously good thing for users without trying to build a metrics framework around it.

This was always the case.