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!
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.
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.
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!
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.
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.