brechin

My guess is connectivity. I was only happy with the Steam Link when it was using a wired connection. This isn't an issue in my home, but most homes don't have wired Ethernet all over.

I did not love the v1 Steam Controller, but it's easy to use with other controllers.

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.

I see a lot of requests to label and possibly remove content, but I see no description of how social media companies were compelled to do so.

Is there any example of a social media company being impacted by refusing to comply with one of these requests?

My interpretation (not a crypto buff) is that it's like he accidentally buried a locked suitcase of cash in concrete at the bottom of the ocean.

It might be recoverable, but would require extraordinary efforts.

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!

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.

> 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.

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.

Hamilton?