bt848

They didn't give the two examples that are most common inside Google: Google I/O is coming up, or annual performance reviews are coming up.

Strangely they also list as "not an emergency" rollbacks of clearly broken code, but that's an exception to review rules inside Google. Anyone can do a pure rollback of a change without getting the approval of the owners of the code, and there are automated tools that will roll back changes that appear to have broken at least 1000 tests, without human review.

Edit: There's even a button right in the code review web UI to roll back a committed change.

I'm not saying you should write code in a performance-oblivious fashion. I am saying that if you want to do something non-canonical, or you want an exception to style guide or other established guidelines, or if you write a comment in your code that says "This function is faster than std::foo", then you must have evidence. In the absence of evidence, adhere to normal rules.

I came across a comment in google base libraries that said "This is faster because cache line is 32 bytes". It had been written by a very famous engineer, and it was even true in the days of the Pentium III processor. But at the time I found it it was not only false but the code as written was slower on modern CPUs than the shorter and totally obvious equivalent.

There's no reason you can't incrementally develop your change over time and then send it when it looks right. You don't need review for every edit. At Google you only need review to commit your change to the mainline repository. For long-running projects it's also permitted at that company to check in whatever you'd like into //experimental/users/<your_username>/...

I'd add two things, from a decade of experience at Google:

Review code in this order: protocol buffers, unit tests, headers, implementation. It's common for a new employee to be an expert on C++ or Java or whatever languages but it's very uncommon to meet anyone who knows how to define a decent protocol message. The tests should give the reviewer a very clear idea of what's happening in the code (and this should be congruent with the description of the change), if not send back to author at this point. The headers should contain clear interfaces, types, and comments and should not contain anything that's not part of the API (when this is technically possible). Finally look in the CC file; at this point the reviewer should see things they were already expecting and no funny business.

Any claims about speed, efficiency, or performance whether in comments or during the review must have accompanying microbenchmarks or they should be deleted. Wrong ideas about software performance abound, and even correct beliefs become incorrect with time, in which case the microbenchmarks are critical to evaluating the continued value of the code.

When sending a changelist for review, always clear all automated warnings or errors before wasting the reviewers' time. Nobody wants to see code that doesn't build, breaks a bunch of tests, doesn't lint, etc.

The actual question on the Pew survey is "Homosexuality should be discouraged by society." agree/disagree. The fraction of people agreeing with this statement has fallen greatly in the last 25 years, mostly due to demographic replacement.

Data on political polarization in America is really interesting. One feature of the data I find fascinating is that in 1994 many people were not "consistently liberal" because they opposed gay marriage. With the big shift toward acceptance of gay marriage these people are now considered "consistently liberal" and by Pew's reckoning this means that liberals have become "more polarized". In my opinion there is no morally defensible compromise position on whether homosexuals deserve their natural rights, so I find this quirk of the survey interesting.

If you look at the ten questions of the Pew survey, it seems to me that anyone who can answer on the conservative side of all ten questions (in order to earn the "consistently conservative" epithet) must be the biggest jerk on Earth, whereas someone who answers on the liberal side of all ten has sensible and morally justifiable views, hence I take all the hand-wringing over polarization with a grain of salt.

https://www.people-press.org/2014/06/12/political-polarizati...

"Always" seems like a stretch. I just selected a random month of the google.ai blog archive and 5 of 5 were written by non-PMs.

GSM phones don’t send anything at all in the first phase of registration.

OK, here's another test. A common way to end up with a dead battery is to leave the lights on overnight. The lights on a car draw over 100W (standard halogen headlights and incandescent tail and marker lights). But you can leave your lights on for hours and still start the car. Therefore it stands to reason that the same battery could power a GSM radio for hundreds of hours.

Get a refund.

I leave a phone plugged into my car's USB port 24x7 and the car has its own GSM modem too and obviously it starts right up every time.

The bit about the cell phone discharge seems pretty unlikely. A charged car battery has at least 2MJ of stored energy. GSM in its highest-power mobile station state draws 800mW. Add maybe another 150mW for the GPS, call it 1W total. The battery should power such a phone for weeks.

You should be able to smell-test this fact by considering that your mobile weighs nothing and runs all day whereas a car battery weighs 20kg.

Sounds like we should all get out our old copies of Descent.

Sure. I mention the 5C because it was the real budget device. On the day it was released it had internals the same as the previous year's 5, instead of those of the 5S released on the same day as the 5C. The SE, by contrast, had the same guts as the 6s. People seem confused about this.

The 4.87" x 2.31" x 0.30" envelope arose with the 5, a year before the 5S.

When the SE was released it had the same 2GB of RAM and A9 CPU as the 6s and 6s Plus, the latter of which was "the flagship". An iPhone with better internals wasn't released until 6 months later.

Yes, the hacks that Apple added to work around the fundamental usability problems of the > 4" iPhones do work, but they don't turn them into 4" phones in all respects.

People don't remember that when the SE was released it was state-of-the-art. It wasn't the slow iPhone, it wasn't the cheap iPhone. That's the 5C.

I don't agree. With the 4.7" screen I can't reach e.g. the P key an other keys on the right side of the keyboard with my left thumb while holding the device in my left hand. I also can't, for example, focus the URL bar of a browser tab while holding the phone in a normal typing position.

I only have the one hand so don't try to give me advice about how to hold the thing.

How many cameras did they think the world would buy? Digital went through a rapid period of technological improvement but it has slowed. My Olympus m43 body is an amazing camera about which I have few complaints. A new camera would need to be radically superior before I would spend the money. Before that I was planning on just keeping my Nikon D70 forever, but it was stolen. My father shot a Canon AE-1 for decades, until film finally became too hard to find. I don't think just being on a treadmill of buying new cameras was common in the film era.

C++ is noticeably safer than C but C is still more widespread. Safety doesn't really sell.

It says in bold type at the beginning "The IgushArray class fully implements std::vector interface" but it's clear it cannot provide an equivalent of std::vector::data.

That doesn't have anything to do with what I'm talking about. I'm discussing data from TNC driver organizations like https://www.ridester.com/how-much-do-uber-drivers-make/

“Unique niches” of the job market that exploit the people filling them must be regulated out of existence. Uber drivers who very carefully manage their overhead generally still earn a pittance, near minimum wage or even below it. Uber mostly relies on the ignorance of their drivers who essentially accelerate the conversion of stored value in their vehicle into short-term earnings. Then when the first bill comes for brake pads, tires, shocks, CV joints and tie rod ends they pack it in. This is why their driver turnover rate is astronomical. The other side of the issue is the drivers who ignore such things and drive all over the place in under-maintained, under-insured cars, converting a public nuisance externality into Uber revenue and prolonged starvation wages.

Also “distracted walking “

You're high. In industry C and C++ are very widespread. Go and Rust are ... not. You'll have an easier time finding a job that requires FORTRAN than one requiring Rust, and Go is only a bit more popular.

I think your blog looks great. The color palette you are using for text is very pleasing.

I map it to lock the screen which makes so much more sense!

In the easy-to-clean category MS Natural wins easily. I never used the 4000 but my Elite (still work after more than 20 years) can be washed in the dishwasher.

For decades the most prominent CR criterion for car reviews was whether a folded wheelchair would fit in the trunk.

Neat. Your code actually contains the issue I was curious about. Why do you log at level ERROR? As I understand it this causes glog to synchronize the output stream after every message.