Working at Google: Maps Continued
Working at Google: Maps Continued
When you have too many resources
This is a continuation of the first article on my time working in Google Maps. In that one, I gave you a detailed explanation of how to create your own custom MyMap, a feature I worked on. Now we continue…
Marissa Mayer and Zagat
At some point while I was in Maps, the famous Marissa Mayer, who later became the CEO of Yahoo:
became the head of “Local,” which was a name they gave for Maps plus local ads and shopping. She is generally credited with the Google search page’s clean and sparse appearance, and for quite a while before Local, she had the final word on the look and feel of Search. I don’t have any inside gossip for you on why she left that position; sorry.
I think the local ads and services were what she was really interested in, not Maps, but I could be wrong. I always suspected that she was just marking time until she could be a CEO somewhere, and that was proven correct when she took the top job at Yahoo.
Marissa’s office was right around the corner from me for a while. I think I could count on my fingers the times I actually saw her sitting in there. Note that this was also true when I was down the hall from Eric Schmidt when I was in Ads: he was almost never in his office. That’s probably a good thing. You need to be out talking to the troops.
Zagat and the Perils of Being Acquired
Tim and Nina Zagat started the Zagat Survey in 1979, concentrating on New York City restaurants. It was published in book form, of course, this being before the Web. It had expanded to over 70 cities by 2005, and was generally considered the best restaurant guide around. They had a very sophisticated system of recruiting reviewers, editing their reviews, and judging when it was time to review or re-review a restaurant.
It’s still being published.
There were at least two reasons why Tim and Nina wanted to sell to Google:
The Internet made their book publishing model obsolete.
They were getting on in years, and wanted to protect their employees by giving them a good corporate home before they retired.
Marissa championed the acquisition of Zagat. I went to several meetings about it, where she talked about how their goal was (paraphrasing) “a professionally written review for every business on the planet.”
I also went to a Q&A by Tim Zagat (by the way, it’s pronounced “za-GAT” not “ZAG-it”). He was very straightforward and honest. He invited any of us to stop by his office if we were in New York and wanted to find a good place to eat. I liked Tim a lot.
Being Acquired by a Behemoth
The fate of Zagat within Google follows a corporate tale often-told: their sponsor (Marissa) left the company, and they were nibbled to death by internal resistance. Other groups in Google felt that they owned the “review” space, and in 2018 Zagat was spun out to another company. I never found out if the long-time employees of Zagat continued to be employed, as Tim and Nina had hoped.
Most big companies cannot consistently pull off a successful acquisition where the acquirees continue to have their way. Frequently, the top managers are committed to the acquisition, but the middle managers are not. They continually peck at it, demanding that it “align strategy” with the big company, regardless of the acquiree’s considerable expertise. Eventually the acquiree’s top management quits.
Of course there are many exceptions: Google acquired YouTube back in 2006, and it remained proudly independent for a long, long time. Google also acquired DoubleClick and Keyhole and integrated them into its business. In the case of Keyhole, it got Brian McClendon, who managed Google Geo for 10 years. If a company acquires in order to get into a new line of business, it may have a chance to work. That was not the case with Zagat. Small companies tend to get smooshed.
MyMaps Progresses
When I left off in the last article, we were deep into a full-fledged rewrite of the MyMaps feature, and I was coding on the server side, in Java.
Vector Database
The old MyMaps used a service built on top of BigTable, a Google database that’s been publicly described. As I mentioned earlier, the original plan when I transferred there was to port it to Fusion Tables, which has since been discontinued.
However, with new management and a new desire to create a monetized Geo service, we were told that we had to use a new database, called the “Vector Database,” which was, supposedly, custom-built for vector information in geographical databases, i.e. lines, polygons, shapes, borders, etc. I was sure this was published somewhere, but I’ve asked everyone and looked everywhere I can think of, and I can’t find it.
The design of the “vector DB” was already set and we were not consulted, except that Igor Benko and Chris Ouk, our manager and tech lead, went to the meetings. Questioning of the decision to use this was not welcome, and neither was criticism. It was a top-down decision, in other words.
Why exactly we needed this, and what was wrong with the old database, was never really explained. Of course, the vector DB was not ready yet. As I recall, there were no “data definitions” as in a traditional database, where each field is a specific datatype (string, integer, floating point, etc.). Rather, any data item could be anything. I spent an ungodly number of hours getting all this to work.
User Testing
In case you’re thinking I’m negative on everything, let me describe something we did right: user testing.
How often have you heard some developer or marketer demo a software feature like this?
So then you just simply press this one button, and magic happens!
Why is it that you can’t find that magic button so you can just simply press it, when you try it?
For MyMaps, we brought in people from outside Google who were (plausibly) going to be users, and put them in front of the software as it was then. No instruction was given. They were videotaped and encouraged to speak their thoughts out loud, e.g. “Now I’m wondering what this button is going to do” or “I want to give it my CSV file but I don’t know how.”
If something like that doesn’t teach you humility as a user interface designer, I don’t know what will. When that demo guy is telling you what you can just simply do, he or she already knows it! Those test users don’t.
One of the characteristics of “the autism spectrum” is an inability to imagine anyone else’s mind. Not being able to read faces or deal with unfamiliar people is certainly a characteristic of that, and as Temple Grandin said in her talk at Google, people in tech are especially prone to this tendency.
When someone approaches your software, they don’t know it. For most of us, it’s nearly impossible to un-know something you know. Giving the software to someone who really doesn’t know it is the only way to get past that. The “alert marker” in MyMaps that I describe at the very end of the previous article is the result of lots of user tests, where something that was absolutely clear to us was not at all clear to them.
The first issue you can have when you conduct a test like this is that some “user experience” designers refuse to accept the results. They’ll object, “Oh, that person’s not typical!” or “The Help button would have answered that question!”
It’s very hard to design something so that people just look at it and know what to do with it, with no manual, no instruction, no Help button. Don Norman wrote about this principle in his classic book The Design of Everyday Things. It takes a certain amount of psychological insight to just take a screen you designed and ask yourself, “If I know nothing at all and look at this, what do I think?”
Patents
Starting around 2002, before I joined Google, I got interested in software patent law, and I actually took the test and got certified as a patent agent (many people don’t even know there is such a thing). That means I’m legally qualified to write your patent application and argue for it before the Patent and Trademark Office, even though I’m not an attorney. (But no, I’m not going to do your patent.)
At Google, I got connected with the Patents group, and as my reward (heh, heh), I got to be the Engineering interviewer for patent lawyer candidates. I actually loved doing this, and I was able to stop interviewing engineers, since I was contributing to the hiring process in a different way. I liked to explain it by saying, “Hey, who wouldn’t enjoy torturing lawyers?”
So that’s what I was doing instead of interviewing software engineer candidates (SWE’s, in Google parlance), which I hated doing. There was one similarity, though: since Google was famous for giving applicants puzzles and programming tests, I asked myself, “What test would you give a patent lawyer?”
What I finally came up with was this: a patent lawyer, at least on the patent-writing side, has to listen to an engineer explain his invention, and then write a patent or direct an outside lawyer to do so. So I took a patent I was very familiar with from a previous job, and explained the technology to them. Then I said, “OK, now write the first claim for that.” This tests their ability to comprehend a new technology on the fly, ask the relevant questions of the engineer, and translate it all into patent-ese. You could say it’s unfair to ask someone to do this on the fly, when in reality they’d have plenty of time to ponder it, but that kind of test was the Google Way.
I’d expect some criticism of this practice for engineers, and it is fair. I might counter that a “test” like that is not like a quiz question in college; it’s more like a discussion topic. A good interviewer encourages the candidate to think out loud, ask questions, try out solutions, etc., and offers hints if they need them. It’s a test of their thought processes, not a test to see if they can do something under pressure. In theory, anyway.
If you like to make fun of lawyers: most of them did amazingly well at this. A patent lawyer has to be able to learn new stuff on the fly, and most of them can do it. On the other hand, I gave this test almost 40 times, and I was getting pretty good at explaining the technology, so everyone was doing well.
How Much Would You Pay?
In 2011, there was an auction for 1,000 patents from Nortel. Google bid but didn’t win. At the time, “acquire a lot of patents” was conventional wisdom in the industry, and Google bought into it. So we were interviewing a lot of lawyers who specialized in this branch of the patent business, which is quite different from writing patents. A new interview test was called for! Here’s what I came up with:
“Google has the chance to bid on a package of 1,000 patents in the wireless space. You have 24 hours to decide whether to bid, and how much. You can call on any resources within Google. How do you do it?”
I think I gave this test 13 times, and I got 13 different answers. The odd thing was, most of them were perfectly OK! The answers I can recall were:
I’d pay $300,000 per patent. This is an average based on long history. There isn’t time to evaluate each one.
I’d apply some published metrics based on the patent’s being cited by other patents, and other quantifiable metrics. This can be done by computer and there are companies who sell software to do them.
I’d get a whole bunch of people to read them all (Hey, it was stated that they could call on any resource within Google!)
Google isn’t hiring such people now, as far as I know, and anyway, someone else is doing the interviewing, so I doubt that my divulging this gives away any secrets.
Is This Idea Any Good?
Another patent-related activity I took on while in Maps was evaluating new ideas for patents about Geo technology.
The Legal department offered a small bonus for merely submitting an idea for a patent; not even a complete invention. You can probably imagine that there are a zillion things you could do with geographical data, many of which are not being done yet. It’s quite possible to get a patent on an “invention” that is never reduced to practice, and there are good reasons to do so. A trick question:
Q: A patent gives you the right to practice your invention, true or false?
A: False. It gives you the right to exclude others from practicing it.
The group I was in evaluated each idea, and classified it into one of four categories:
Definitely file a patent on this. Usually it would be something that Google was actually doing.
Quite possibly file a patent.
Probably no patent, but nice try.
No patent, and this is so bad we won’t even pay the bonus for it.
I especially enjoyed classifying something as a #4. Some people just made up random junk to get the bonus, so being able to say, “No bonus for you!” was very satisfying.
Over and Out
I hated being in Maps. I had thought I was going to be working for Chip, and instead it was a bunch of other people I didn’t sign up to work for, submerged in a giant project that seemed devoid of any rationale.
The Older Programmer
You may have picked up here that I was (and still am) most interested in business and psychological and legal issues, and not so much in the pure Computer Science stuff. In my 20’s it was different, as I recall.
Most of the people in corporations who actually decide such issues are older, have been managers for decades, and have had all the rough edges of their personalities sanded off by responsibility and years of management conflict. Or maybe they never had a personality in the first place. They’re boring and stuffy, usually.
That’s not me. In my whole career, I’d usually managed to find companies where everyone’s opinion was considered, not just that of the people with “manager” in their titles. Or maybe I concentrated on areas where creativity, economic sense, and psychological insight were valued. There really are such areas, believe it or not.
However, as a regular engineer, I was now on an equal footing with lots of 20- and 30-something engineers, and over time, my perspective on programming came to differ radically from theirs. At the beginning of my career, there was no formal review process for “checking in” code. Sure, people would read your code from time to time, but you rarely had to get any formal approval for every single thing you did.
Code Reviews
That’s changed over the years. “Code reviews” have become the norm. You have to get someone to read every line you write, and comment on it. I don’t know if every company does it this, but in Google it was institutionalized. When someone was satisfied after reviewing your code, they’d write “LGTM” for “Looks Good to Me.” There was actually a food station in one of the cafes called LGTM. Separately, someone would have to do an Approve on your Change List. All this was taken very seriously, not to say “religiously.”
In principle, it’s hard to argue with reviews, and that’s why they’ve become the norm in the industry. If a reviewer can spot a bug in your code, why not fix it now, instead of after it brings down the system? If some patch of code is unreadably obscure, it’s perfectly reasonable to point that out and ask the coder to make it clearer.
However, reviewers can object to anything: “there aren’t enough spaces in your Python header,” for instance. There was a Python Style Guide that governed that, and a style guide for every language in common use. You could argue with the reviewer, but the easiest course was just to do what they asked. Arguing that this change had negligible value but imposed non-negligible costs on you (and thus, on Google) was merely proving that you didn’t care about quality.
“What they asked” was often “Make this as good as it could possibly be. If you could replace those three lines of code with one, you must do it.” They use terms like “technical debt” and “code smell” which express the fear that someone, someday, will have to perform the odious task of dealing with this.
For most of my career, I’ve had to take someone else’s code and fix it. They invariably had their own style, usually not at all my style. I just accepted that as the way the world was. Things have changed. Now people take code they don’t like as an affront to their identity.
A true story: my last Project Lead in Maps, Chris Ouk, actually was so bothered by two lines at the end of my unit test (this was not the actual code that ran, mind you; it was the code that verified it) that he went behind my back and changed it to one line, without telling me. It could have been “better code,” you understand.
I ripped him a new one for this. He didn’t even understand why it was an issue. His “explanation” was that he just “wondered” if those two lines could be reduced to one.
Perfection, Not
Take all this as a voice from the past, if you like. I recognize that things change, and the younger generation gets to impose its own standards, just as we did 40 years ago. You can’t stand in the way of it. That having been said, some cynicism:
I think it’s a fool’s errand to insist that every piece of code be perfect. Very, very rarely does anything last as long as you think it will. The Xerox Star effort, which I wrote about in Inventing the Future, suffered enormously from the sense that we were writing code for the ages.
Especially at Google, the half-life of most code is about two years. A new engineer comes on and wants to earn his stripes, so he pronounces the current system hopelessly inadequate and in need of a complete rewrite. Then every other system that uses it also needs radical revision to use the new thing he did. And so it goes.
Respect Your Tools
It’s also true, being fair, that I was becoming bored with programming. This is not a happy state of affairs, and I really can’t blame anyone for criticizing this. They take the job seriously, and so should everyone.
One peer review complained that, as a Java programmer, I should have been aware of a new Java framework that Google had introduced. They were right; I should have.
Onward
Supposedly at Google, you had to spend at least 18 months in a project before transferring, but Louis and Igor let me go early, on the premise that I was “on loan” to the Patent Litigation group. So I became a “technical advisor” in the Litigation group, which was not a programming task, but provided the engineering talent that the lawyers needed. I’ll talk about this in the next post.