If that many people support the changes, couldn’t they just vote for them? I can’t imagine that fully 75% of the non-striking 66% would turn out to vote against whatever changes the strikers are proposing
3,134 karma · joined April 15, 2011
If that many people support the changes, couldn’t they just vote for them? I can’t imagine that fully 75% of the non-striking 66% would turn out to vote against whatever changes the strikers are proposing
If there are any outstanding debt obligations (which I expect there are), then those would be senior to voluntary severance even if the company hadn't spent its literal last dollar.
You don't always have to create new paradigms; integrating existing ideas can work wonders.
I fail to see why that's superior to a universal childcare subsidy, which can be used for childcare or retained if someone wishes to care for their child themself. Or better yet, a universal child allowance that parents can use to defray whatever child raising costs they see fit.
And I say that as someone whose current plan is to be a stay-at-home dad while my (female) partner continues to work.
"ˈθʌrə"'s was interesting to me, I'd render "thorough" in my ideolect (Southern-inflected General American) "θʌrow". Is your pronunciation "standard" in British English (or whatever the prestige variant where you're from is)?
Also, I think you meant "ðə ˈmɛtᵊl Pb lɛd"
My naïve guess is high performance data structures with reference cycles?
A company I worked at had a O(1 MLoC) React frontend with no JSX at all for a long period of time due to the Typescript compatibility issue, just `export const El = React.createElement`
I cook a fairly standard south Indian dinner of daal stew, rice + stir fried veggies a couple times a week in ~30-45 minutes of total work. Nothing preprocessed, premixed, or premade other than (and these are really stretching the definitions thereof):
* Asofoetida powder that's been preground and dried for me
* The rice has been polished and debran-ed (ie, turned into white rice)
* pressure cooked lentils (I make a big batch every weekend or so and freeze it into dinner sized portions)
1) An endpoint returns a superset of the data any client may need, which means more data is loaded than any given client needs (which means wasted bandwidth/compute)
2) An endpoint returns a subset of the data all clients need, which means any given client has to tack on additional queries to get everything it needs (which means more roundtrips)
(There's the third option of tacking on "includes" or "excludes" parameters to endpoints, but at that point you're evolving an ad hoc, informally-specified, bug-ridden implementation of half of GraphQL, to massacre Greenspun's tenth rule).
How important solving this dilemma is to your application may be a function of your team or system topology, and the type safety that GraphQL happens to come with is a nice bonus, but this dilemma is the crux of things.
The writing system on the other hand... IMO the worst used by any major language in the world. Graft a logographic system (already a bad choice to start) from an isolating language onto a highly synthetic verb system, necessitating a whole extra syllabary. Evolve numerous "readings" of each logogram, depending on etymology and history. Then tack on a 2nd syllabary for abstruse historical reasons.
Eg, given even the type:
{"aLongerKey": "value"}
The generation prefix: {"a
would by your algorithm produce the following invalid output: {"a}I imagine closing the loop (using the TS compiler to restrict token output weights) is in the works, though it's probably not totally trivial. You'd need:
* An incremental TS compiler that could report "valid" or "valid prefix" (ie, valid as long as the next token is not EOF)
* The ability to backtrack the model
Idk how hard either one piece is.
Software development is a very segmented world. In the various social circles I'm connected to, I know devs who were thrilled to finally be making 6 figures 7 years out of college (in line-of-business software in a regional hub) and devs who were disappointed not to have crossed 400 k$/yr in that same time span (at FAANG in the bay area).
Saying anything at all is "to deal with words". Discussing anything at all about your internal state is "to deal with... consciousness".
Yes, it is deeply human to put to words internal thoughts and share them with others (that's what I'm doing in this comment, after all). But there's nothing special about dreams in that regard.
And unlike most ideas we attempt to communicate, dreams are by their nature fragmentary and illogical (or perhaps "pre-logical" is better phrasing). While humans love imputing meaning and profundity to obscurant musings (whole academic careers have been built on that fact), that doesn't mean they are actually meaningful and/or profound.
It feels like the dominant style of programming in the companies I've worked at (YC startups and FAANG) is "functionalish" procedural, with a sprinkling of objects-qua-objects to interface with libraries and frameworks (Eg, react class components or rails ActiveRecord models).
Note I'm distinguishing between objects-qua-objects (data coupled tightly to methods that operate on them) from structs-implemented-via-objects (eg, ruby's `Struct` or Java "beans") or modules-implemented-via-objects (like a class with a bunch of static methods used as a namespace). I only see the first one as "object-oriented".
If by "big tech" you mean FAANG cos (and assuming "startup" means bay area YC tier), then a more accurate analysis is something like:
Stability: Lower likelihood of being laid off than the median startup in any given economic conditions. Way lower likelihood (I'd estimate <1/20th the risk) than early stage (series A/B)
Base pay: Higher than early stage startups, around the same for later stage (series C/D)
Stock: Much lower variance than startups, slightly higher EV
Fulfilling work: YMMV hugely depending on what you find more fulfilling. Making O(100M) users' lives 0.1% better? Big tech. Absolutely making the day of O(10) people? Startups