9,464 karma · joined December 17, 2013
> I know, it's Meta, but they can't be that blind.
You've not actually seen the kinds of decisions corporations execute on in the interests of shareholder value, have you?
Tech companies are better at using data to drive their decisions than non-tech companies; they are no better at using data -sensibly-.
If this actually happens (it's Blind), with the policy listed (it's Blind), the rationale is quite easy to explain - clearly, the one whose productivity didn't suffer -fired the right people-. The one whose productivity suffered -fired the wrong people-. The option you present, that some teams are actually sufficiently lean already, runs against the broad generality the CEO gave of "too many employees, but few work", ergo it can't be true.
Google, collectively, may be among the best (I'm not hazarding an opinion) at solving technical problems.
I, however, expect good engineers to help with product vision, understanding and addressing customer pain points, and amongst the senior engineers especially, be effective at communication and helping manage upwards to achieve those ends. Somewhere, Google engineers are dropping the ball there, or are so detached from those problems that their abilities in those skills are untested.
You can decide you -disagree- with the ideas of 'social justice', or the implementation, or whatever, but I think you'll need a stronger case than "it's political" to warrant the dismissal of an educational institution trying to incorporate the term.
Not saying there wasn't a way through this that could have led to a positive outcome, but the key takeaway isn't "do the dirty work", it's "make sure what you're doing has an impact, and has visibility from the people in charge of personnel decisions affecting you". Less work but greater visibility > more work and worse visibility. Part of your job is ensuring visibility or you will get shafted.
You know, having known and being related to multiple teachers, I've not heard any of them express it as -fun-. Meaningful, important, challenging, yes, but not 'fun'. The two college professors I know have expressed it a such, but that's it. Of the teachers I had, I could see some of the advanced placement ('gifted') teachers viewing it as fun, because we were generally well behaved and smaller class sizes, but even there a common through line was taking advantage of the class' temperament and offloading the curriculum back onto us (i.e., "pick a topic in (X) to teach to everyone").
There is a tradeoff in lesson planning; there are resources around the proscribed curriculum (i.e., teach to the book), but that is decidedly not fun or interesting and the kids -will- misbehave more; the alternative for most classes (the advanced placement as mentioned above notwithstanding) is to prep something more interesting, but that requires using more time outside the classroom for 'work'.
Outside of the workday, which runs from 7-3:30 or so (and sometimes both before and after, if there are faculty meetings and things, or if they recruit from the teaching pool to help with kid drop off/pick up), there is grading, so it is not uncommon for a teacher's workday to run close to 12 hours.
You do, as you say, get summers off, but again, nearly all the teachers I know use that time to look for summer jobs, because the pay is so poor. Sometimes it's summer school or just independent tutoring, sometimes it's service industry work; nothing quite like running into your students from the prior year while handing their mom their McDonald's from the drive through. The only teacher I know who didn't (recently retired) do that had inherited their house, so had no rent/house payment to make, and -could- live, frugally, on a teachers' salary.
Yet another counter counterpoint - there are still companies and government jobs with defined pension plans that pay far more than teachers. Even without those, there are still many, many jobs requiring a comparative amount of education, far fewer hours worked, and pay more even once you subtract maximizing 401k contributions yearly (let alone considering the added costs of buying school supplies).
The point is that the mother is being charged with aiding her daughter to have an abortion due to evidence collected from chats they thought were secure, but which were still susceptible to a warrant.
Now, there are other charges. And the time the abortion happened it occurred while the 20 week ban wasn't being enforced, because the state knew it wouldn't hold up under Roe (and is only illegal and chargeable now, with the court having overturned Roe). So, yes, it's super interesting.
But the point is that police are charging someone for aiding an abortion due to texts the sender thought were secure. That's the entire relevancy. Anything else about this particular incident isn't germane.
They can send a letter asking for documentation for everything the automated system flags. The automated system detects "simple" cases at a far higher confidence ratio, which tends to be lower income. Once you get upper income, with all manner of complicated itemized deductions, the confidence of the automated system is much lower, and the effort to ask for appropriate documentation, and verify it, is much higher, for a much lower expectation of return (since, again, low confidence from the system).
A lot of the instances in the post even show the NSA giving a why. It's not a particular convincing why, but it was enough to sow doubt. The reason to make all discussions public is so that there isn't an after the fact "wait, why is that obviously odd choice being done?" but instead a before the fact "I think we should make a change". The burden of evidence is different for that. A "I think we should reduce the key length for performance" is a much harder sell when the spec already prescribes a longer key length, than an after the fact "the spec's key length seems too short" "Nah, it's good enough, and we need it that way for performance". The status quo always has inertia.
This might be somewhat unique in that the perjury charges relate to hiding evidence as well (rather than just running counter to the evidence). And, obviously, that Alex Jones isn't a cop, so that particular fetishism of law enforcement the US operates under doesn't apply.
That is, why bundle functions with the data and encapsulate it as a new type that ties them together? It invites the very thing you're saying not to do; if you want to think of it as just data...then make it just data. Nouns only; no verbs. Even if you have a verb as data, treat it as a noun (i.e., a higher order function).
It's all translatable; you can break an object into functions and data, and create an object bundling functions and data, but, as you say, it's about how you think...and objects do not encourage you to think about the underlying data, but about the abstraction. And abstractions are leaky, don't translate well into new domains, and are much harder to communicate (both at an API level and between humans) than data.
Sure it was. While it didn't force devs to stop using mutable state, you just called out that it -did- force them to move that state out of the service and into something with ACID guarantees, and write their server code in a way that was far more stateless. That sounds like a win to me?
Only to a point. Many desirable geographic locations have a lot of local factors that prevent additional housing from being built with the intent of housing more people (think homeowners defending their "property values", zoning laws, etc). Similarly, homes being "investments" means there's a self-perpetuating cycle; builders build luxury homes instead of multi-tenant buildings, because they know that's what companies want to buy (being flipped the easiest with the highest rate of return), so even when there is new land being developed, market forces push it to being an "investment" rather than housing people. Income inequality furthers this; why use the land and sell a modest home to a worker, when you could use the home and sell a luxury home at a much larger markup to the rich?
Cars are an example of that. Even when scarcity has driven the cost of cars up (such as during the recent pandemic), everyone recognized that more could, and would, be produced, and so no one viewed them as an investment vehicle, that adding time in somehow increased the value over the initial purchase price.
Housing is viewed that way. Part of that is due to location; there is innately a level of scarcity (not everyone can live in (insert city)), but there is also massive artifical scarcity. Even where there's room, there is NIMPYism and zoning regulations and etc that keeps enough housing from being built in areas people are able to live (i.e., close enough to civilization to be able to buy groceries without an hour long drive each way, for instance), forcing pricing up, in a positive reinforcement loop (scarcity = pricing goes up = people buying for the 'investment' rather than a place to live = more scarcity)
It's basically a license that was created in response to how Amazon has been operating, co-opting open source technologies (whose business models focused on creating SaaS offerings of their open source tech) and creating their own managed services, directly competing with the creators (Redis even called this out a few years ago when they changed their license, see https://techcrunch.com/2019/02/21/redis-labs-changes-its-ope...).
They also indicate that at some point the license will change to Apache 2 ( https://github.com/redpanda-data/redpanda/tree/dev/licenses ); it's BSL right now likely to give them enough legal protection to keep competitors who'd operate Redpanda as a SaaS away, while they build up the enterprise (paid) features (which has a separate, far more wordy, license). I'd imagine they'd look to make the switch when they feel they have enough value and customers of the enterprise features.
I don't work on open source, or anything licensed by BSI, and from such an outsider perspective you sound...very dogmatic.
The fact that it's impossible to comply with "who wrote -this- review" is probably sufficient, but "and we don't even readily have access to who wrote -a- review" can help prevent fishing expeditions, since presumably a judge will be less amenable to such fishing expeditions if you can show it will have negative material effect to comply, while still not providing any legal path forward to sue for the prosecution.
But that also makes assumptions both of user counts, and rounds of hashing. 50 million users (seems reasonable with Glassdoor), with a sufficiently slow hash that takes a second to compute (easily done) means you'll have to wait a year and a half for results for a given company, or start to parallelize things, and, oh, look, now you have dev time and CPU resources and, well, this has a materially adverse effect on our business, and we'll be left with usernames we still can't release since this discovery order only is valid for this -one- review, and we have no way of knowing which it is.
But even if you want one account to not write multiple reviews, you can flag that an account wrote a review for a company without tying it to -what- review.
You can even disassociate that; hash usernames with the company and store that to track who has written a review. Then, you can only confirm that a given user account has written a review for a company, but not which review is theirs, and given a company you can't determine what users wrote those reviews without attempting to hash every username against it.
And that's if you -absolutely- have to try and prevent an account writing more than one review (again, noting that you can just create another account).