FWIW, I'm _not_ interested in discussing this from a socio-political standpoint. I'm just curious to hear opinions about the ruling from a legal perspective.
43 karma · joined January 8, 2019
FWIW, I'm _not_ interested in discussing this from a socio-political standpoint. I'm just curious to hear opinions about the ruling from a legal perspective.
- if oncall is a part of the gig, you compensate _somehow_ (demonstrably above market salaries, explicit extra pay, time in lieu, etc); oncall culture (or the lack thereof) should be explicitly mentioned in any hiring process and employment contracts
- the team should be striving for 8 or more engineers in the steady state; temporary vacancies should be temporary
- primary should be handling 80+% of pages in the steady state; if this is not the case on average across the team, you are not building enough resiliency into your oncall culture, or relevant tech debt should be high priority
- relatedly, kpis/incentives should be structured such that as call gets worse, progressively more immediate investments are made to address technical root causes (a la SRE error budget)
I'm tinkering with that last one my head. It's easy to say, hard to execute
My interpretation of the statement is that compounding interest applies to education as much as it does to bank accounts. Missing 5k in contributions to retirement accounts at 25 and then making up for it with extra at 26 is very different than making up with an extra contribution at 46. Same applies to education, and if you're trying to make up missed "contributions" in 6/7th grade, you're already the educational equivalent of a 46 year old.
At risk of stretching a thin metaphor even further, this is to say nothing of Social Security (long-term structural impact of system-wide attempts to catch up half a generation of students on 12+ months of education).
edit: formatting/proofreading
It is conceivable to execute a Flow entirely locally yet achieve @step-wise "Batch-like" parallelism/distributed computation by, in the relevant @step's, `import dask` and use it as you would outside of Metaflow, correct?
Although, as I think of it, the `parallel_map` function would achieve much of what Dask offers on a single box, wouldn't it? But within a @step, using dask-distributed could kinda replicate something a little more akin to the AWS integration?
Tangentially related, but the docs note that data checkpointing is achieved using pickle. I've never compared them, but I've found parquet files to be extremely performant for pandas dataframes. Again, I'm assuming a lot here, but I'd expect @step results to be dataframes quite often. What was the design consideration associated with how certain kinds of objects get checkpointed?
To be clear, the fundamental motivation behind these lines of questioning is: how can I leverage Metaflow in conjunction with existing python-based _on-prem_ distributed (or parallel) computing utilities, e.g. Dask? In other words, can I expect to leverage Metaflow to execute batch ETL or model-building jobs that require distributed compute that isn't owned by $cloud_provider?
As an aside: hot damn, the API - https://i.kym-cdn.com/photos/images/newsfeed/000/591/928/94f... Really cool product. Thanks for all the effort poured into this by you and others.