FWIW, users will have the option to hide gender later this week: https://plus.google.com/106792630639449031994/posts/5kt9TpEb77m While this isn't a feature that most folks would need, it is very important to some users. On my account at least, the setting is already available.
The UI is imperfect -- selecting the target for a post is in a separate menu, so it's not obvious who your current target audience is, and selecting from the menu is a little awkward.
Can you expand on that a bit? When I go to post, there's a readable list of the circles right below the post. I can type circles or user names with tab-completion or select from a drop-down list. Is that what you are seeing?-- if not please submit feedback. If what I describe is what you are seeing, can you be more specific on how you'd like it to be easier?
(I work at Google, but not on G+. I can help pile on the feedback if something is broken)
The best way is to talk with friends and try to brainstorm something that helps us power users, but that can work for normal people too (longshot) or at least stay out of their way to avoid complicating the interface. If you come up with something good, share it on G+ and if it gets reshared the right devs will notice.
Do note that as much as we all want some of these power features, unless they can be really simple and widely usable, they have to go to the end of the list below the current missing features (groups, events, org/business pages, games).
P.S. Personally I don't like games, but a lot of folks have come to expect them.
FYI: At Google almost everything is developed using mandatory pre-commit line-by-line reviews, but they are of the "informal" style where it's normally just one other developer. Unit tests and regression testing is also pushed pretty hard, though coverage there varies depending on the project.
After seeing reviews catch various horrific bugs, I would probably not work anywhere that didn't have mandatory code reviews for all production code. It also radically improves internal code documentation, and makes sure at least two people have seen any given part of the code.
I work at a company with mandatory line-by-line pre-commit code reviews, and reasonably high standards for test coverage. I have a motto that I think matches well with your explanation:
I write feature code for free; I'm paid to write tests, review and document that code.
FWIW, even rooftop solar kills more people per terawatt-hour than nuclear. We know mdsolar has seen those stats, as he's been pointed to them many times. Yet he only posts stories about nuclear, while ignoring the coal and oil elephants. Why? Because he can profit more from overhyped fear than actual statistics. IOW, FUD in place of science. Regular readers have grown tired of this.
"Android is outselling the iPhone! We count every one, because openness is what makes Android great!"...
Market share is important simply to make a viable platform to ensure app development. It's not really important beyond that. Interestingly, Apple was the one originally crowing about the size of their market and app count. I've noticed they don't bother to bring up app count anymore. The news is that Apple's chosen metrics of the past aren't so much in their favor anymore.
Of course from a practical standpoint it is meaningless. Having 45 Twitter apps or 10 doesn't make much of a difference to anyone, except some marginal quality improvement from being able to choose from more options (making the big assumption that ratings are accurate).
"Android has more support issues? Well, we really shouldn't be including the crap ones..."
No we should include them all, but report the average by what folks actually buy, which is individual models or at least at the individual manufacturer level. The mistake is not that they are included in the study, but that they are included in the same average.
Should we predict the reliability of Apple phones by averaging across all "proprietary OS" phones and reporting that number. When determining the historical reliability of Mac desktop machines, should we include cheap clones in the same average as Apple hardware?
Those people get to choose whether or not they put pictures on the internet. They do not get to choose whether google puts pictures of them on the internet.
There are lots of geotagged or labelled images on the web now, and the trend is clearly upward. Lots of people over-shard on Facebook, and yes that includes people who might take your photo and not ask you before uploading it. Google may have good coverage, but open photo sites are easier to scrape and make no attempt to blur faces. Facebook has just-enough-to-be-reasonable controls, but now it's actively scanning for faces.
Say what you want about "righteous standards of behavior", but the horse left the barn a long time ago.
The numbers are probably from here: http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html The blog author does a pretty good job of citing all the sources. The thing that makes it interesting is that many of the data points are *so* far apart that even large inaccuracies in the source studies would not shift many of the conclusions you'd draw.
The researchers who broke the story were not surprised that apps could use location services, they were surprised that: (1) this data is retained for over a year. (2) it was accessible to desktop machines when the phone was docked and in backups (using default settings). (3) that it still logged this data when location services were turned off.
It's true some people are now getting upset about the location service itself, but I think that the media response on that is overblown and the cases are unfounded. It's unfortunate, since it covers the real issue (which Apple will fix soon).
The general impression I had gathered before was that to work there you had to be under 40 (preferably under 30),
Don't get your general impressions from Slashdot comments. Google needs people who can code, and does not hire pure architects which is one thing that I think leads to this misconception that you can't go there if you're older. If you've been writing UML for 10 years while your 15 underlings write the actual code, have an accomplished resume, but you forgot how to write and analyze code, you probably won't make it past the interviews. That kind of position is correlated with age.
No software methodology is intrinsically good or bad, so don't jump on my if your an architect; it's simply that Google's approach isn't set up that way. The way we use does work ok, and we hire to that. I have several gray-haired coworkers, and at least half of my coworkers have kids. It may have looked like a college dorm 10 years ago, but it's not like that now.
and intimately conversant on the difference between a latte and a frapachino.
The San Francisco Bay Area consists of more than just San Francisco. South Bay has never really been a hipster place (it had Hewlett-Packard, not Haight-Ashbury), and other than a somewhat geeky bent from an overabundance of engineers, its a pretty normal place. Like most places though, we do enjoy a good coffee.
None of that matters for a non-practicing-entity (aka patent troll). All you need is one successful patent to sink the ship. For example, i4i is much smaller that Microsoft, but that didn't help MS any, did it?
I have been working on android framework code and testing it since around an year now. I believe that the problem is with the CPU sleep. The DHCP lease time which android measures is based on the system clock. The system clock stops when the CPU goes to sleep, and restarts when CPU is woken up. So if you connect to an access point (lets say it gives a lease of one hour) and then just put your phone idle without touching the screen, the phone will not even try to renew the lease. So basically, whether your phone will or will not renew the lease depends on if it is awake or asleep. That perhaps explain why the behavior is somewhat random and not so easy to reproduce with normal usage. Perhaps, android should use the RTC (real time clock) instead of the system clock to measure the dhcp times, so as to make sure the lease is renewed in time.
IOW, an app that thinks it can use uptime to estimate elapsed time is broken. This doesn't come up for devices that tend not to sleep while they are using the network (even laptops don't wake up and sleep nearly as much as phones). That said, it really ought to have been fixed faster in the repository. Unfortunately many carriers will just sit on the update containing a fix anyway.
Absolutely; with google+ita, here are just a few of the things that are possible: Gigolo Tea A Legit Goo Agile Goto Go Toil Age I Go Eat Log Igloo Gate
The possibilities that these could entail are almost endless.
You are an excellent example of the kind of arrogant revisionist who has knocked Google off the top of the "want to work there" lists.
What did I say that was revised or untrue? We've been through this before, and it really does seem like your group went through quite a bad experience. However, when you start painting the whole company that way, I'm here to point out that the experience was not universal. I really don't understand how you claim that every problem you experienced was pervasive, and describe the motivations and shortcomings of executives as if you worked directly with them. If all of what you say were true, the company would have failed by now.
Better you should admit there are serious problems in paradise and try to address be part of the solution than mindlessly waving your Googly.
Perhaps you missed the part in my post where I mentioned some problems? I'm certainly not portraying Google as a problem-free paradise, and to suggest otherwise is inconsistent with what I said. There are definitely some pretty steep challenges facing the company, though not the ones you've mentioned for the most part. Around 2008 a lot of growing pains and economy-driver fear came to a head. I was happy that I helped my team get through some of them. Tough choices had to be made.
I'm sorry if this comes off as arrogant, but packing up and leaving is not being part of the solution either. If it is indeed hopeless (and you seem to truly believe it is) that is the only reasonable option. However it is a bit odd though to sit there and say that someone who stayed behind is not part of the solution.
Shall I post something about the rampant alcoholism that repeatedly landed Googlers in hospital and wore out our welcome at a number of offsite venues? Would that conflict with your rose colored views?
I'm not sure how we got here from open source relations, but: a company with >10k employees will have people with problems. Company-wide parties are a bad idea for a huge company, as it can be hard to keep a lid on things -- after all no rock concert ever goes by without an ambulance coming for someone. Since you left though: no more company-wide parties -- the lesson was learned. While I can only speak for the ones I've attended since then (maxing out at ~500 people), they've been tame and grown up while still staying fairly entertaining. Then again, perhaps you're still talking about the group you were in; if there were major alcoholism and venue problems at that level, then I can only reiterate how unfortunate a situation that must have been. Hopefully there have been changes in that group since your bad experience.
Now that we've gotten that out of the way, you seem to have skipped over some stuff: Did your project get cancelled? Did you leave in response? Do you think that might color your views about Google?
Rose-colored glasses are not the only kind. Cancellation of something you've invested a lot of effort in truly does suck -- everyone in the industry or on LKML has been there at one time or another. However when you subsequently look around and see that you are the only "unbiased" person around, it's worth taking a step back to evaluate why that might be.
The way I see it: Gen3 now, LFR tomorrow, LFTR soon, Fusion when practical.
There's not much "throwaway" research here even with all of these steps, as each of the latter three need research from the former to be practical. Sadly, our current policy seems to be something akin to the Wright Brothers saying "let's just go straight to building Moon rockets!"
Slashdot Mirror
FWIW, users will have the option to hide gender later this week:
https://plus.google.com/106792630639449031994/posts/5kt9TpEb77m
While this isn't a feature that most folks would need, it is very important to some users. On my account at least, the setting is already available.
Google+!=facebook
Perhaps I've been programming in C++ for too long, but that was way too hard for me to parse.
The UI is imperfect -- selecting the target for a post is in a separate menu, so it's not obvious who your current target audience is, and selecting from the menu is a little awkward.
Can you expand on that a bit? When I go to post, there's a readable list of the circles right below the post. I can type circles or user names with tab-completion or select from a drop-down list. Is that what you are seeing?-- if not please submit feedback. If what I describe is what you are seeing, can you be more specific on how you'd like it to be easier?
(I work at Google, but not on G+. I can help pile on the feedback if something is broken)
The best way is to talk with friends and try to brainstorm something that helps us power users, but that can work for normal people too (longshot) or at least stay out of their way to avoid complicating the interface. If you come up with something good, share it on G+ and if it gets reshared the right devs will notice.
Do note that as much as we all want some of these power features, unless they can be really simple and widely usable, they have to go to the end of the list below the current missing features (groups, events, org/business pages, games).
P.S. Personally I don't like games, but a lot of folks have come to expect them.
Please submit this as feedback. Everything gets counted, so the more votes for a feature, the more likely it will get prioritized.
It's not a database science problem, it's a logistics problem.
You hit the nail on the head right there.
FYI: At Google almost everything is developed using mandatory pre-commit line-by-line reviews, but they are of the "informal" style where it's normally just one other developer. Unit tests and regression testing is also pushed pretty hard, though coverage there varies depending on the project.
After seeing reviews catch various horrific bugs, I would probably not work anywhere that didn't have mandatory code reviews for all production code. It also radically improves internal code documentation, and makes sure at least two people have seen any given part of the code.
I work at a company with mandatory line-by-line pre-commit code reviews, and reasonably high standards for test coverage.
I have a motto that I think matches well with your explanation:
I write feature code for free; I'm paid to write tests, review and document that code.
How about stats?: Historically, rooftop solar kills more humans per terawatt-hour than nuclear. I know you've seen the source data.
"Fukushima reactor #4 was shut down and still caused big problems"
http://en.wikipedia.org/wiki/Decay_heat#Power_reactors_in_shutdown
Read up on decay heat; there's a huge difference between "shut down an hour ago" and "shut down a month ago".
Can your children tell the size of squares?:
http://sethgodin.typepad.com/seths_blog/2011/03/the-triumph-of-coal-marketing.html
Which one is bigger? Now which one does the media talk the most about? Does that make any sense?
FWIW, even rooftop solar kills more people per terawatt-hour than nuclear. We know mdsolar has seen those stats, as he's been pointed to them many times. Yet he only posts stories about nuclear, while ignoring the coal and oil elephants. Why? Because he can profit more from overhyped fear than actual statistics. IOW, FUD in place of science. Regular readers have grown tired of this.
"Android is outselling the iPhone! We count every one, because openness is what makes Android great!" ...
Market share is important simply to make a viable platform to ensure app development. It's not really important beyond that. Interestingly, Apple was the one originally crowing about the size of their market and app count. I've noticed they don't bother to bring up app count anymore. The news is that Apple's chosen metrics of the past aren't so much in their favor anymore.
Of course from a practical standpoint it is meaningless. Having 45 Twitter apps or 10 doesn't make much of a difference to anyone, except some marginal quality improvement from being able to choose from more options (making the big assumption that ratings are accurate).
"Android has more support issues? Well, we really shouldn't be including the crap ones..."
No we should include them all, but report the average by what folks actually buy, which is individual models or at least at the individual manufacturer level. The mistake is not that they are included in the study, but that they are included in the same average.
Should we predict the reliability of Apple phones by averaging across all "proprietary OS" phones and reporting that number. When determining the historical reliability of Mac desktop machines, should we include cheap clones in the same average as Apple hardware?
Those people get to choose whether or not they put pictures on the internet. They do not get to choose whether google puts pictures of them on the internet.
So you're saying that this guy got the permission of the ~400 people in this photo?:
http://www.flickr.com/photos/wesbs/5273648283/
There are lots of geotagged or labelled images on the web now, and the trend is clearly upward. Lots of people over-shard on Facebook, and yes that includes people who might take your photo and not ask you before uploading it. Google may have good coverage, but open photo sites are easier to scrape and make no attempt to blur faces. Facebook has just-enough-to-be-reasonable controls, but now it's actively scanning for faces.
Say what you want about "righteous standards of behavior", but the horse left the barn a long time ago.
The numbers are probably from here:
http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html
The blog author does a pretty good job of citing all the sources. The thing that makes it interesting is that many of the data points are *so* far apart that even large inaccuracies in the source studies would not shift many of the conclusions you'd draw.
Unfortunately, iPhone Tracking Even When Location Services Disabled. Your "fix" won't work until the next patch comes out.
Here's a tip: to turn Location Services off, slide the toggle to the off position
And imagine your surprise when you find out iPhone Tracking Even When Location Services Disabled .
The researchers who broke the story were not surprised that apps could use location services, they were surprised that:
(1) this data is retained for over a year.
(2) it was accessible to desktop machines when the phone was docked and in backups (using default settings).
(3) that it still logged this data when location services were turned off.
It's true some people are now getting upset about the location service itself, but I think that the media response on that is overblown and the cases are unfounded. It's unfortunate, since it covers the real issue (which Apple will fix soon).
The general impression I had gathered before was that to work there you had to be under 40 (preferably under 30),
Don't get your general impressions from Slashdot comments. Google needs people who can code, and does not hire pure architects which is one thing that I think leads to this misconception that you can't go there if you're older. If you've been writing UML for 10 years while your 15 underlings write the actual code, have an accomplished resume, but you forgot how to write and analyze code, you probably won't make it past the interviews. That kind of position is correlated with age.
No software methodology is intrinsically good or bad, so don't jump on my if your an architect; it's simply that Google's approach isn't set up that way. The way we use does work ok, and we hire to that. I have several gray-haired coworkers, and at least half of my coworkers have kids. It may have looked like a college dorm 10 years ago, but it's not like that now.
and intimately conversant on the difference between a latte and a frapachino.
The San Francisco Bay Area consists of more than just San Francisco. South Bay has never really been a hipster place (it had Hewlett-Packard, not Haight-Ashbury), and other than a somewhat geeky bent from an overabundance of engineers, its a pretty normal place. Like most places though, we do enjoy a good coffee.
What Apple is doing also fits the definition of "permanent log file."
Google is short on adult supervision, that's a fact.
Though I can't speak for your old group, overall things have changed quite a bit since you left.
None of that matters for a non-practicing-entity (aka patent troll). All you need is one successful patent to sink the ship. For example, i4i is much smaller that Microsoft, but that didn't help MS any, did it?
There is no issue in shipping implementations of h.264 in free systems. Just that nobody wants to pay the licenses.
If you have to pay, it isn't free anymore (in either sense of free).
Comment 46 on the bug explains it pretty well:
I have been working on android framework code and testing it since around an year now. I believe that the problem is with the CPU sleep. The DHCP lease time which android measures is based on the system clock. The system clock stops when the CPU goes to sleep, and restarts when CPU is woken up. So if you connect to an access point (lets say it gives a lease of one hour) and then just put your phone idle without touching the screen, the phone will not even try to renew the lease. So basically, whether your phone will or will not renew the lease depends on if it is awake or asleep. That perhaps explain why the behavior is somewhat random and not so easy to reproduce with normal usage. Perhaps, android should use the RTC (real time clock) instead of the system clock to measure the dhcp times, so as to make sure the lease is renewed in time.
IOW, an app that thinks it can use uptime to estimate elapsed time is broken. This doesn't come up for devices that tend not to sleep while they are using the network (even laptops don't wake up and sleep nearly as much as phones). That said, it really ought to have been fixed faster in the repository. Unfortunately many carriers will just sit on the update containing a fix anyway.
Absolutely; with google+ita, here are just a few of the things that are possible:
Gigolo Tea
A Legit Goo
Agile Goto
Go Toil Age
I Go Eat Log
Igloo Gate
The possibilities that these could entail are almost endless.
You are an excellent example of the kind of arrogant revisionist who has knocked Google off the top of the "want to work there" lists.
What did I say that was revised or untrue? We've been through this before, and it really does seem like your group went through quite a bad experience. However, when you start painting the whole company that way, I'm here to point out that the experience was not universal. I really don't understand how you claim that every problem you experienced was pervasive, and describe the motivations and shortcomings of executives as if you worked directly with them. If all of what you say were true, the company would have failed by now.
Better you should admit there are serious problems in paradise and try to address be part of the solution than mindlessly waving your Googly.
Perhaps you missed the part in my post where I mentioned some problems? I'm certainly not portraying Google as a problem-free paradise, and to suggest otherwise is inconsistent with what I said. There are definitely some pretty steep challenges facing the company, though not the ones you've mentioned for the most part. Around 2008 a lot of growing pains and economy-driver fear came to a head. I was happy that I helped my team get through some of them. Tough choices had to be made.
I'm sorry if this comes off as arrogant, but packing up and leaving is not being part of the solution either. If it is indeed hopeless (and you seem to truly believe it is) that is the only reasonable option. However it is a bit odd though to sit there and say that someone who stayed behind is not part of the solution.
Shall I post something about the rampant alcoholism that repeatedly landed Googlers in hospital and wore out our welcome at a number of offsite venues? Would that conflict with your rose colored views?
I'm not sure how we got here from open source relations, but: a company with >10k employees will have people with problems. Company-wide parties are a bad idea for a huge company, as it can be hard to keep a lid on things -- after all no rock concert ever goes by without an ambulance coming for someone. Since you left though: no more company-wide parties -- the lesson was learned. While I can only speak for the ones I've attended since then (maxing out at ~500 people), they've been tame and grown up while still staying fairly entertaining. Then again, perhaps you're still talking about the group you were in; if there were major alcoholism and venue problems at that level, then I can only reiterate how unfortunate a situation that must have been. Hopefully there have been changes in that group since your bad experience.
Now that we've gotten that out of the way, you seem to have skipped over some stuff:
Did your project get cancelled? Did you leave in response? Do you think that might color your views about Google?
Rose-colored glasses are not the only kind. Cancellation of something you've invested a lot of effort in truly does suck -- everyone in the industry or on LKML has been there at one time or another. However when you subsequently look around and see that you are the only "unbiased" person around, it's worth taking a step back to evaluate why that might be.
The way I see it: Gen3 now, LFR tomorrow, LFTR soon, Fusion when practical.
There's not much "throwaway" research here even with all of these steps, as each of the latter three need research from the former to be practical. Sadly, our current policy seems to be something akin to the Wright Brothers saying "let's just go straight to building Moon rockets!"