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!
628 karma · joined July 14, 2014
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!
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.
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.
Sometimes practices do reflect real constraints, rather than just path-dependence.
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.
The industry as a whole is facing huge financial pressures, Sony included.
Can someone with Kagi check to see if Kagi does better here?
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
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.
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.
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.
It's also great at doing bulk updates, so you get a lot less spam than you do from Dependabot.