Lewisham

I'd love to live nearer the Googleplex, but I wouldn't move into Mountain View.

Disclaimer: I work for Google, but I had this opinion of MTV far before joining them, and I have no voting rights in MTV politics. I live in Santa Cruz and much prefer it.

It would certainly put the jumper cables on Windows Phone.

I personally subscribe to The Matrix theory: post-Sigularity any reasonable AI will conclude that humanity has been a poor custodian of the planet, and will simply delete us. Everything I've heard so far about sandboxes for containment and such ignores the fact that the democracy of computation is ultimately the weak point here: anyone sufficiently deranged, will, at some time, be able to release such an AI to the Internet by themselves. And we have plenty of people sufficiently deranged and intelligent enough to do it.

Because writing code which contains a large number of checks and balances is generally orders of magnitude more expensive than human trust/judgment on the Ops team. Reading the postmortem makes me think that this sort of failure could have happened to anyone, and no-one really did anything wrong. The mistake was the blob store config flag not getting flipped, which is just a natural human error. The engineer who did the roll out could have been any of us. Given what he/she knew, he/she thought they had a good soak test (and a couple of weeks is a pretty good soak test) and made a call, similar calls he/she makes a number of times every day. This one didn't pan out.

I would hazard that most companies have a big red rollout button that is reserved for trusted engineers that will do a rollout without all the checks you're requesting.

Two apps using the same backend data (you can switch between Gmail and Inbox if you like) seems a better fit.

FWIW, I really like it, and use it exclusively for my work and personal accounts. Inbox functions very much more like a ToDo list than it does an email client. Here are the workflows I have:

Work:

I filter all mailing lists into different clusters that I have appear at 7AM every morning. I then scrub through the subject lists to see what happened yesterday, pinning things that require my attention, and then sweeping the rest. At this point, everything pinned in my Inbox is now "something I need to look at". I then read the email, and decide if it has an action item or not. If it's actionable and I intend to do it today, I'll leave it pinned. If it's not something I'm going to do today, I'll Snooze it until I think I'll have time to do it, or at least evaluate another Snooze time.

To make sure I don't miss important emails, I have a cluster that I put all email that has myself explicitly in the To: line, and have that appear whenever anything arrives. I do occasionally miss things that didn't have me in the To: and went to my 7AM clusters, but this is few and far between, and I hazard happens less than my Gmail inbox where I had far more cognitive load on managing the emails there.

Home:

The defaults are tuned well for home, and I use the clusters (like Travel, Purchases etc) like I do for work, having them appear at 7AM each day. Most things get swept immediately, and again I pin things that require my attention and are maybe ToDo items.

Inbox is really opinionated about its workflow: if you struggle against it, you'll have a bad time, and you'll prefer Gmail's flexibility. However, if you are Inbox Zero or GTD minded, I think you'll love Inbox. Inbox is my ToDo list, and replaces Wunderlist/Things/Evernote/Google Tasks for me. I set reminders to myself for work items that don't have an email attached.

I encourage everyone to give it a week to see if it suits them, but I'm afraid I'm all out of invites for now :(

Disclaimer: Engineer on Cloud SQL team

We are developers and you are developers, and we're all trying to work towards making cool things :) I don't see that changing any time soon, everyone from in Cloud from Urs down gets it. We have to earn your trust, and we do that be providing the best product we can, interacting in communities directly, providing great support, and not creating vendor lock-in. I wouldn't work on this team if we didn't do those things, because I believe in them as being necessary parts much as you do.

[1] I can't speak to the rest of the company because I don't have experience with it, but I had very good support experience with Play too, so it's my hope that support in general at Google has turned a significant corner in recent years.

And then I heard he had upped and left to Florida with his family, which is a big change. He has the rap sheet [1] to do pretty much whatever he wants, so I took his move to Florida as a big sign that Magic Leap exists (moving to Florida is no joke, and he's not a pump-and-dump kinda guy) and whatever does exist is cool (he wants to build cool things, and there's plenty of that in the Bay Area).

[1]: http://en.wikipedia.org/wiki/Graeme_Devine

This is where, say, Google's Made With Code initiative came from.[1]

[1] https://www.madewithcode.com/

As far as "Why Go for shell scripts?" I actually think Go is pretty well suited to shell scripts (aside from no or die): getting stdout/stderr pipes set up is pretty trivial with the exec package. There must be anecdotal law somewhere that states that all shell scripts tend to Turing completeness over time: what starts with "oh, a small shell script would do this" always ends up growing to a full blown 1000+ line program with multiple code paths. Writing the first script in Go is a piece of defensive programming so that when it inevitably grows, it's growing into a language that better supports its size (static typing, readability, libraries etc.) It's probably overkill for personal stuff, but it is probably the right hammer for the job over time when it comes to corporate work.

1. People who are fit (or want to be)

2. People who are technical (or are interested in quantified life in general)

Technical people who commute from SC to Silicon Valley have far less bus options and routes than SF (SC has three each way for Google which ends at 9:25). That forces a lot of the number 2 people awake earlier than they otherwise would be.

I think SC is probably the same, if not average getting up later than other Bay Area places, due to the large student population and short walk/bike commute for those who work in the town.

So if we assume that people will go looking for intrinsic motivation in even the most tedious jobs, then we can design structures that provide feedback to enhance that motivation. The key to metrics is that they need to provide feedback on the things that the employee cares about and helps them to understand how they are doing in whatever motivates them. For our car mechanic, maybe we want to do things like:

* Show a timer with how long it's taking him to make them, how he's doing over the day, how he's doing in comparison to yesterday

* Show him the cumulative effort, illustrating how many widgets he's put together

* Show him how his work is important to the company (providing him with purpose), maybe with how many cars he's allowed to be built, and which dealerships they go to

None of this is really "gamification" as you'd think of the term. They're means to support the gameful context that the employee can choose to, or not choose to engage in (e.g. the stock market is basically gambling, you choose whether you treat it as a game or not). It is, however, going to help get the sort of output that you wanted when you went looking for gamification.

Notice the risk here: If he's building things faster to play his game, his work might get sloppier. That's why such things need really careful monitoring and tweaking before being deployed. Same thing with the Target checkout thing where it shows how quickly the checkout person is pushing people out the door. My guess Target's real goal isn't getting people out the door, but getting happy customers out the door. If a checkout person is being incentivized to actively not help out customers with problems that require more attention, then it's possible it's working to harm the overall goal.

EDIT: As far as gamifying education, you might be interested in "Punished by Rewards", which is a book about intrinsic motivation in schools, and was published long before gamification appeared on the scene. The book has it's critics, but it's an interesting take.

[1] http://en.wikipedia.org/wiki/Flow_(psychology) [2] http://en.wikipedia.org/wiki/Overjustification_effect

The OP hits on two key points. The first is that employees know bullshit when they see it. The second is that the wrong metrics were often chosen, and that anything that didn't have a easy metric was thrown out.

These two points are symptomatic of the root issue at the heart of this: enterprise gamification companies don't, and never did, care about employee well-being. This was true of every gamification salesperson and author (Zichermann in particular) that I ever came across. They were all snake-oil salesmen selling stuff to CEOs who read about gamification in an airplane magazine. And to be fair to them, they were very good at it, and I guess the smartest ones also took the money and ran.

Gamification used buzzwords and metrics to provide feedback about employee productivity, but never provided any meaning because no deeper motivation was ever attempted to be tapped. Zichermann was infamous at misrepresenting or ignoring the psychological literature that ran counter to the nonsense he was spouting [2]. He particularly rejected intrinsic motivation, which is pretty much everything anyone ever wants out of their employees, in favor of the extrinsic motivators, which creates this arms race known as the hedonic treadmill [3], where employers would have to offer more and more motivators in order to keep interest. Note that paying people more is a classic extrinsic motivator.

So you have a whole bunch of points and badges and such, but to what end? What do they represent? What do they mean to those that hold them? The value of an Xbox 360 achievement, of a Boy Scout badge, of a Weight Watchers token, was never about the thing at the end, but about the meaningful trip they represented and reminded holders of. Gamification never bothered with that, and enterprise gamification, in particular, couldn't have cared any less. Making employees more productive was never the goal, it was selling stuff while the buzzwords were hot.

Gameful ideas can and do work when employed in a thoughtful, meaningful way that supports the intrinsic motivators of the given task. However, that's very tricky, as it's way too easy to misalign incentives (e.g. giving a badge for archiving email quickly, what's the result going to be?) which is why actual game designs take years to perfect before they are released. There are often simpler, quicker wins for improving employee motivation.

[1] More easily digested book - http://www.amazon.com/Irresistible-Apps-Motivational-Web-bas...

Free dissertation - http://www.soe.ucsc.edu/~ejw/dissertations/Christopher-Lewis...

[2] http://gamification-research.org/2011/09/a-quick-buck-by-cop...

[3] http://en.wikipedia.org/wiki/Hedonic_treadmill

So the curiosity and talent is just drained out of them. That's the issue.

But as I don't have the study to hand, of course I could just be making this all up :/

Because they've done such a bang-up job of that thus far..? It's no secret that at comparable advertised speed, Netflix on Comcast was far worse than Netflix on other ISPs.

I'm not sure if they're really so deluded to think their enforcement is super great, or if they're just delivering placating sound bites.

My read is that kiwis tend to come back when they're ready to start a family, but during those vital 18-25 years when the entrepreneurial spirit is strongest, they're simply not in the country. They're elsewhere.

The kiwis I talk to that are in that demographic here at Google all seem to be want to go back to NZ, but only if the prospects are there, such as Google opening a real-deal engineering office. But it's hard to convince companies that that is a worthwhile venture when Australia and NZ have freedom of worker movement.

Without the population to lead NZ forward, and with no companies willing to invest to drag it forward, I don't think we'll ever see NZ be richer and more productive. But as other commenters have noticed, I think NZ is perfectly happy with that, because they're happy with their lot, which is something to be envied.

I think for many users the Chromebook does fine, and I think for many others the Chromebook is too limiting. I would personally be very happy if, say, Chrome OS was built as a dual-boot solution for Microsoft Surface. Chrome for general case, and an escape hatch to Windows for games or whatever. A VM solution hosted in Windows would also work here.

However, my last attempt at running Chrome OS in a VM indicated that the open-source version of Chrome OS (at least as downloaded by VMWare) was running at a significant lag behind what's being pushed to Chromebooks right now, so I stopped investigating it any further.

a) That's what is written in the contract

b) I think you should be able to migrate off the platform within that timeframe, and you shouldn't join our platform if you don't think we're making it easy enough for you to leave again (I deeply believe in initiatives like Google Takeout)

I didn't make any comment, nor will I, on whether I perceive that time frame to be long enough. I think it's smarter to stick to the facts when it's my own job I'm talking about. I would like to continue engaging with the Hacker News community (which, you'll see from my history, began many years prior to my joining Google) and offering context and information. But I can't do that if I don't stick to facts, lest my opinions be bent around to imply something I didn't mean that could put the job (that I enjoy very much) in jeopardy.

FWIW, the Google products that are subject to the deprecation policy [1] will give a year's heads-up before they are shut down.

We aren't doing our job well enough if you can't easily transition off Cloud Platform (at least for the components that have obvious competitors... something like BigQuery is necessarily less simple). You should stick with us because you believe in the product, not some sort of lock-in, so you should find it easy to leave within that year.

As for whether that deprecation is likely, it would require a sea change. In the Wired article that came out yesterday [2], the quote is '“We will spend the majority of our development efforts on this New World,” wrote Hölzle.' And this is true, Google really is throwing Technical Infrastructure behind Cloud Platform. That's not to say Cloud Platform going away can't or won't happen, but I feel confident in my job sticking around.

[1] https://developers.google.com/cloud/terms/deprecation [2] http://www.wired.com/wiredenterprise/2014/03/urs-google-stor...