How about this comment from Senate Majority leader Schumer?
This argument of "It's ok to meddle as long as you do not compel." is atrocious. People, especially those in high positions in social media companies, indeed fear government capability from many angles.
Regardless of the permission to meddle but not compel, why is the government paying for agents to act as moderators in the first place? Isn't there more important crime to allocate resources to?
So your argument is that it's coercion through implied threat, or that social media companies are so complicit that they will just do anything the "right" government official asks of them? Is that government censorship, or a problem of weak service operators?
I don't think there's a compelling case for government agents' top priority to be moderating online speech, but ensuring that the American people are not being subjected to massive mis/disinformation campaigns is a legitimate cause.
This reminds me of the "Lock In" series by John Scalzi. In it, a pandemic virus causes lock-in in about 1% of the population which drives immense investment in technology to improve the quality of life for those folks.
https://en.wikipedia.org/wiki/Lock_In
This is a very misguided take, seeming to support that people saying terrible things should be left to their own devices because _some_ people "get it."
I knew this author's approach was doomed when I read:
> So, to defend privacy we need to accept shared norms of behavior.
At least in the US, this simply doesn't appear to be possible. Look at how our lives have changed (or not) during the COVID pandemic. Look at the recent debate between 2020 POTUS candidates. We don't DO shared norms in the way that would be required to make true/complete/meaningful privacy a reality.
My expectation is that if it's on the Internet, if it's outside, if it's in a crowd... it's public (or can be made public). Everything you express can be observed and used, and that sucks. Does that have a chilling effect? Of course!
> So it is a A versus B for those people - people who are having to commute for hours to work, mandatorily sit at their computer screens . Versus others who wake up late (because no commute) and can walk about the house in their pyjamas.
It's a false dichotomy. It's not commute + "mandatory" screen time vs. sleeping in and wearing PJs.
When I worked in offices, I enjoyed commuting, it gave me time to listen to podcasts and transition between home and work. Working in an office with other people brought many opportunities to socialize, get pulled into impromptu conversations, take long lunches, and leave really early (to beat the commuters) if I needed to get home for some kid's after-school activity.
I work remotely now, and I still have to wake up on time, get dressed (hello video chat!), and be accountable. If I step away for a measurable amount of time, then I let people know in chat. It's far easier for a remote person to engage in overwork because there's not a clear boundary for when you're "at work" vs. "at home" (unless you create one). For better or worse, I "work more" as a remote employee than I ever did in an office.
The office folks who commute sometimes get to work late (traffic, train/bus issues, etc.), are pulled into random conversations and are unexpectedly unavailable just as much as any remote person. Are they contributing more by being in the office, or is the value just in their "presence", that you could literally tap them on the shoulder?
IMO, It all comes down to communication and empathy. If you're experiencing a major issue because you have to wait 10 minutes for someone to finish walking their dog, then imagine that person were in the office but in the bathroom. Would you still sneer at them because they were holding you up? Very few conversations are _SO_ urgent that you absolutely need an answer immediately. Having remote coworkers allows us to engage more thoughtfully with each other, and often pushes us to write more (and more useful) documentation so that we _aren't_ expecting immediate answers from any specific human.
>Having remote coworkers allows us to engage more thoughtfully with each other, and often pushes us to write more (and more useful) documentation so that we _aren't_ expecting immediate answers from any specific human.
this is very interesting - is this emergent behavior or have you guys figured out some todos that makes this an effective tool ?
for example, do you consciously allocate more time for documentation by developers, than you did before remote workers ? is there a particular way you do this that makes it better, etc ?
This is my experience at the company I'm currently at which has offices in SF and other US locations, as well as a significant number (as a % of the Eng team) of remote people across the country. I don't know the origin story, as the practice was in place when I joined this team, but it's proven its value time and time again. We do consciously make time to document and discuss how to make that information more useful/discoverable/accurate.
* Use the tools - ticket tracking, chat rooms, wikis or other documentation repositories
* Own it - engage in the conversation, do the work, help the whole team get better, accept responsibility, acknowledge your own mistakes, and acknowledge others' wins and contributions
* Do it in public - @mention people in tickets, etc., use PUBLIC chat spaces, use org-wide sharing of documents
A company I worked for in the past, which had a SF office and a smaller number of remote engineers, did not embrace the value of thoughtful written communication, and ultimately didn't see the value of remote engineers. It fostered a culture of "need-to-know" conversations where they felt if you couldn't be "in the room" then you simply weren't going to have the information you needed. They didn't value recording (video, text, etc.) the agenda, discussion, or outcomes of these discussions, so it only lived on in the individuals involved. This artificially stunted the remote engineers, and in turn it backfired on the entire team's productivity.
In my experience, this has been both an emergent behavior that has worked out well, and subsequently a culture/process that has been encouraged by management for new members (both remote and in-office) of the team.
There hasn't necessarily been a need to allocate more time for documentation, except for everyone getting in the habit of default communication modes being easily accessible documentation (common wiki/docs that all decisions, specs, and proposals go into) ... so it's not a "more time" thing, as much as it's a "don't send an email, but instead update the docs"
MnDoT also added it to I-35E northbound out of St. Paul. There's talk about adding it to I-35W northbound out of Minneapolis, too. I think MNPass entirely managed by the state of Minnesota, though, which may help keep the prices down.
IMHO MnDoT has actually been doing a pretty good job over the last 15-20 years at smoothing out traffic flows considerably in the north metro without adding much in the way of metering/tolls. SW Metro traffic flows still suck from what I hear, although to be fair the topography has something to do with that (i.e. HOW many bridges do we need to build over the Minnesota River?)
As someone who worked at a company that used almost all of the GCP products, I agree with just about everything in this article. GCP is pretty amazing (and simple) to deal with. They offer so many features that work very well within their platform. They have a similar 99.95% SLA on most of their services, and they often automatically apply credits for missed SLAs (YMMV, this may only apply when you have account reps paying attention).
The major downsides that I've noticed are:
1) Documentation is lacking (but improving!)
2) Issues that aren't affecting a lot of customers can sometimes take a long time to resolve.
3) Many services (including App Engine Flexible Environments) are still in beta, meaning no SLA, and they recommend against using them in prod. Unless you have a big paid support contract you'll have no clue how soon (if ever) things will reach GA.
I agree with all of your point except for the beta woes. If I'm building a production product I would much rather they be upfront about when products are still "beta" and under heavy development as opposed to shipping a buggy and unreliable product that I only realize is in that state after I stick x GB of data in it or start making x req/s.
For example at a previous job we were "early" adopters of Amazon Redshift and it gave us no end of troubles. That should definitely be labeled "beta" until they sort those issues out.
The Subscribe box near the bottom of the page doesn't work. It tells me that I'm entering an invalid email address (it's a standard gmail.com address, nothing tricky).
Is there any example of a social media company being impacted by refusing to comply with one of these requests?