taion

Good luck! Those were the behaviors that got you promoted to senior staff in the first place – so I would imagine that your org is actively expecting that you will continue them!

Assuming your leveling matches standard bigtech leveling, it's generally expected at level 7+ that you are doing lots of cross-org work anyway, and have responsibilities at quite a high level. Unless you're one of those rare engineers at this level who is a deep specialist (in which case this team move scenario sounds unlikely), the value you add above someone at level 6 is just that you have breadth of experience and can lead cross-org and/or cross-functional initiatives.

No, nobody is ever fully in charge of his or her own destiny, but the entire point of senior staff engineers is that you have the autonomy to exercise protagonism separate from your org structure, in ways that managers and directors do not. So... do the cross-org collaboration thing – and not because it's what you feel like, but because as a L7, it's literally your job to do that!

You can do that, but now you have a runtime dependency on your analytics system, right? This can be reasonable for a one-off experimentation system but it's not likely you'll be able to do all of your experimentation this way.

The problem with this approach is that it requires the system doing randomization to be aware of the rewards. That doesn't make a lot of sense architecturally – the rewards you care about often relate to how the user engages with your product, and you would generally expect those to be collected via some offline analytics system that is disjoint from your online serving system.

Additionally, doing randomization on a per-request basis heavily limits the kinds of user behaviors you can observe. Often you want to consistently assign the same user to the same condition to observe long-term changes in user behavior.

This approach is pretty clever on paper but it's a poor fit for how experimentation works in practice and from a system design POV.

And in that sense Tillich isn't that far from, say, Aquinas, who is consistent about asserting that existence is not a "real" predicate and that God's existence is outside of the world and outside of space and time.

You don't even need to squint that hard to see a commonality between Tillich's notion of discussing God symbolically and Aquinas's notion of doing so analogically, not to mention the contrast between finite humans and an infinite God who is beyond understanding. And not to mention that apophaticism – the idea that positive knowledge about God is impossible – has been a feature of Christian theology since the beginning.

So much of this can be taken in ways that not only aren't outside the bounds of Christian orthodoxy, but also align with more sophisticated Christian philosophical understandings of God.

That much, of course, is not why Tillich is controversial!

That one is not going to be particularly useful at all. It's a linear probe, which means it's really only for imaging things near the skin. It's one-third of a typical set of probes: https://stanfordmedicine25.stanford.edu/the25/ultrasound.htm...

It's different from the MEMS-based devices this article talks about, which have the novelty of letting you do everything with a single probe. Though of course that comes with trade-offs.

Yes, they still require gel. That's just a matter of physics. Changing the transducer technology doesn't change that.

You're not allowed to buy these without an NPI number. And while ultrasound is relatively easy, it's still not really usable without some training. I think there have been some studies of training users to do ultrasound at home for a limited set of views, but it's not really a "pick it up and look around" sort of thing.

A big part of the point of that Construction Physics Substack is to explore these factors around innovation, productivity, and process change in the construction sector. I don't think it's really quite as simple as you imply: https://www.construction-physics.com/p/why-its-hard-to-innov..., https://www.construction-physics.com/p/sketch-of-a-theory-of...

Sometimes practices do reflect real constraints, rather than just path-dependence.

I'm not sure why this piece mentions deregulation. The drinks limit was in 1956, while the sandwich spat was in 1958 – but deregulation wasn't until 1978, two decades later!

The collusion in question seems to only relate to regulation, which prohibited the airlines from competing on price. The incentives obviously don't work out the same with deregulation!

The Construction Physics Substack had a good piece on the economics of building commercial aircraft a bit ago: https://www.construction-physics.com/p/a-cycle-of-misery-the..., with discussion on HN here: https://news.ycombinator.com/item?id=39339149.

It seems that, on paper, in this case specifically, re-engining rather than clean sheet made a lot of sense. Of course, we all know how things ended up in practice...

But at this point, if Boeing were to spend a lot of money on a clean-sheet design – even if they shipped it on time, would they have customers? It's hard to see how that would play out.

It's also not entirely a technical issue, anyway. In a vacuum the Sourcehut UX might be fine, but if people are used to GitHub-style UX, then they will have a hard time with Sourcehut and end up doing the wrong thing, like emailing the maintainer directly rather than using the mailing lists – through no fault of the mailing lists themselves!

It’s not uncommon for vocal music to have different conventions like this, especially which the pitch isn’t absolute so standard notation isn’t quite correct anyway. Note the use of neums for chant – and those are harder to learn!

This is exactly right. This kind of structured logging is great, but it doesn’t replace metrics. You really want to have both, and simple unsampled metrics are actively better for e.g. automated alerting for exactly those reasons. They’re complements more than substitutes.

You also lose accuracy because of sampling noise.

Matthew Ball had a good essay on this about a month ago: https://www.matthewball.co/all/gaming2024

The industry as a whole is facing huge financial pressures, Sony included.

That makes sense. So first they have to go closed-source before that attack vector is even feasible, and doing so would be sufficient on its own to raise alarms.

One thing I’m curious about here is how BlueSky can credibly commit to only use the open portions of the protocol. BlueSky appears to be de facto quite centralized – given that, it seems like there’s no technical reason why first-party BlueSky clients have to be ATProto clients. Obviously it would be a major betrayal of user trust to do so any time in the near-to-medium-term future, but it seems like the de facto decentralization of ActivityPub gives stronger guardrails here.

A fun bit of Bluesky trivia is that it’s also named after a person, apropos that post from a bit ago – the CEO’s first name is literally “blue sky” in Mandarin.

This feels “truthy”, but I wonder how much of this is selection bias. Organizations that do solve their problems tend to cease to exist or be relevant. In that sense you would expect only the organizations that have not (yet?) solved their problems to persist. It may not exactly be an incentive in the sense that most organizations behave in this manner, depending on how you sample across organizations.

Google are already indexing Reddit, so this might reflect the incremental value of direct API access plus keeping everyone happy. I would be surprised if Reddit’s threats to block Google’s crawler were all that credible.

The framing of this as a Google issue would suggest that other search engines wouldn’t have this issue, but I’m not sure that’s true? The “air purifier” search on DDG seems to give the same set of blogspam results: https://duckduckgo.com/?t=h_&q=best+air+purifier+for+pet+hai...

Can someone with Kagi check to see if Kagi does better here?

Or less kept secret than not written down, especially before the early modern period, especially outside of things like war horses, just based on who was engaged in that activity.

In fact a quick glance at the Wikipedia page for medieval horse breeding shows documentation for quite deliberate, centralized, and successful operations quite far back! https://en.m.wikipedia.org/wiki/Horses_in_the_Middle_Ages

The premise of the argument seems wrong. Even in just Europe, there’s evidence for an increase in animal size during the Roman period, a decrease during the early middle ages, and then an increase into the high middle ages, e.g. https://link.springer.com/article/10.1007/s12520-021-01426-w

These correspond to economic changes which made different sizes of animal more appropriate. Size and productivity aren’t the only criteria anyway – disease resistance, hardiness, or ease of feeding seem like they’d be just as important to subsistence farmers.

Earlier techniques may have been less good than modern ones, but they quite evidently worked to some extent. Specialized horse breeds had gotten to the point where they needed to be specially fed way before the start of the period in the book reviewed here!

Instead of positing a lack of understanding, the observed phenomenon is likely more a factor of limitations in documentary evidence (how many people engaged in stockbreeding were actually writing books anyway?) and in the actual goals of the people involved around optimizing for robustness and practicality over pure productiveness.

It's not really "fixed" for other languages in general. The support in Node for multiple different versions of transitive dependencies is actually quite nice. In Python, for example, you simply can't have multiple versions of transitive dependencies, and this can lead to issues with commonly-used utility packages. I've seen issues like this come up with utility libraries like six or boto and its variants. Likewise with larger libraries like numpy.

As someone who's worked pretty heavily in both ecosystems – it's definitely not something I think about every day on the Python side, but Python dependency conflicts are very annoying... while in Node they're mostly not a big deal except in a small set of cases where peer dependencies show up.

The argument here is correct as far as it goes, but the “yes but”s are somewhat severe.

For a minimal MVP deployment, as a client likely you’re not going to have anything like that Kafka setup, but instead have something like a single polling worker, which means you have similar issues with potentially falling behind if that worker can’t keep up with the data. By contrast, with webhooks, you can take advantage of your existing load balancing logic since you’re doing this for incoming HTTP calls anyway.

At scale it seems like you’d need to integrate some kind of ad hoc sharding to this `/events` API, as otherwise you have no ability to scale out the reader. Hopefully a non-issue with third-party API integrations, but there are limits on both ends.

Strong recommendation for Zena Hitz's book _Lost in Thought_. As an engineer, it's hard to take a step back and enjoy the pure intellectual pleasures of my work and hobbies, but I found it quite worthwhile to do so, and her book did a lot to encourage me here.

Renovate gives you links to diffs on the published npm package: https://app.renovatebot.com/package-diff?name=hookem&from=1....

It's also great at doing bulk updates, so you get a lot less spam than you do from Dependabot.

I’m curious how accurate this reporting actually is. It seems to focus almost exclusively on smaller producers, but what about the larger ones? As I understand it, most hospitals use PPE from larger suppliers like 3M or Halyard for logistical reasons and face logistical hurdles in sourcing things like N95 respirators from smaller manufacturers, as they’d need to re-do certification for users. Is this really a place where the startup model makes sense?

There's a Times obituary. It was cancer: https://www.nytimes.com/2020/03/03/nyregion/matvey-natanzon-...