Google Play IAB_PERMISSION_ERRO, code=12

We've been working on adding in app billing to our Android app, and everything worked through development. We prepared the release, and billing stopped working!

In the logs, I saw:

ERROR/Finsky(891): [1] CheckoutPurchase.setError: type=IAB_PERMISSION_ERROR, code=12, message=null

Turns out the issue was that our Store draft app versionCode was 78 while the version we were testing was 87. From http://developer.android.com/guide/google/play/billing/billing_testing.html - "Also, the version number of the uploaded application must match the version number of the application you load to your device for testing" - not less than or equal to, but only equal to! It takes some time after upload to work though.

Simplifying speech

“I'm sorry I wrote you such a long letter; I didn't have time to write a short one.” - Blaise Pascal

Recently, I decided to reduce my use of the following words, along with others that aren't coming to mind.

• very
• like
• really
• extremely
• incredibly

The reason? I believe my overuse of emphatic adverbs decreases the emphasis. "I really enjoy that painting" imparts less meaning than "I enjoy that painting." Even though I've said that I really enjoy the painting, I believe it sounds as though I don't enjoy it as much as if I omitted really. "That dress is very beautiful" doesn't mean as much as "that dress is beautiful." I believe overuse of emphasizers also decreases memorability. When I think of the most persuasive people I know, they tend to speak simply and focus on a few concepts, instead of giving lower emphasis to more concepts. Their focus drives home a clear message - something to remember the conversation and the topic by.

There's a few other words I'm trying to say less often:

• thing
• stuff

These words require more mental engagement of the reader or listener. "Would you bring those things over here?" (and pointing) requires the listener to determine the meaning, whereas "would you bring the plate and glass over here?" puts the burden for my request on the speaker. Even when the noun is obvious to speaker and listener, replacing the noun with "stuff" or "thing" frees the listener from determine the speaker's meaning.

Twitter has trained me to be more precise in my statements. The Twitter service, with its limit of 140 characters, pushes users to retype their tweets to impart maximal meaning in finite space.

The landlord game

Helen and I have been on the lease for our apartment since September 2007. The landlord had us sign a 2 year lease, with a $50/month rent increase after 12 months (in September 2008). There hasn't been another rent increase since then.

The rent is low for Palo Alto. I joke to friends that our approach has been to not contact our landlord at all - if she forgets about us, then she won't remember to raise our rent! Seems that our landlord thinking about us may have caused a rent increase!

Our downstairs neighbors changed about a month ago, and over the past month the landlord has been involved with coordinating repainting the house and repairing the back steps. This week, I had to contact the landlord when a pipe rusted out and we started dripping water onto our downstairs neighbor's yard.

Today, I got an email notifying us of a rent increase of $50/month, effective January first. The rent is still fair, so I have no complaints. But it seems that our stay-out-of-the-landlord's-mind approach had been working!

iOS from an Android user's perspective

I'm starting at Strava at the end of the month - a cycling and running data company that has iOS and Android apps. I already have a Google Nexus S Android device. I wanted to be able to try out Strava's iOS app, so I picked up an iPod Touch 4G last week.

I had an original iPhone and iPhone 3G. While working for Google, they gave me a G1, a Nexus One, and a Nexus S. The G1 was terrible, not worth switching to. It was slow, Android then was clunky, and it didn't engage the user the same way that the iPhone did.

I liked the Nexus One better than the iPhone 3G (more responsive, widgets, etc), and I happily switched over to T-Mobile and the Nexus One in December 2009. When Google gave me a Nexus S, I upgraded to that. When on Android, I've always used phones that were latest-release-track, carrier-software-less.

Every once in a while, I read iPhone users' responses to trying out Android, and invariably they're frustrated, disappointed, and certain iOS is the better platform. Every time a friend asks me iPhone versus Android, I wax on about how Google Voice is amazing, the Gmail and Google Calendar integration are great, and I summarize "Android is a better phone that does other things with less polish, whereas iPhone is a device that happens to make phone calls. If you live a Google life, use Android and Google Voice. If you like your music and well polished devices, and happen to make phone calls once in a while, buy an iPhone."

After a few days poking around on iOS, I'm disappointed by the ease of use of iOS. I believe I gave Apple too much credit.

There are things that I like better on iOS / the iPod Touch:

• The screen has better colors than the Nexus S. The iPod Touch screen is brighter and crisper.
• The iTunes integration is perfect. Musically, I live an iTunes life. doubleTwist is an inconvenience versus staying in iTunes. I've never synced a podcast to my Android devices - I have no clue how.
• In the same vein, automatic conversion of high bitrate songs to 128 kbps AAC is convenient.
• The iPod Touch is thin. Sure, the iPod Touch lacks phone hardware, but darn, every time I pick it up I notice its thinness.
• The touch responsiveness is better. Every once in a while, I need to lock-and-unlock cycle my Nexus S to have it recognize when I lift off my finger. No such issues on the Touch. (Maybe I haven't dropped the Touch as often as I've dropped the Nexus S!)
• Software consistency. It sucks that carriers put their own layer over Android - software I think doesn't make user experience better. It sucks that carriers and manufacturers don't upgrade older devices quickly or often.
• Availability of third party devices for iPods is high. (eg: iHome, hotel alarm clocks, in car integration, Garmin ANT+ adapter)
• Many applications are iOS first or iOS only. (I wish Android had a Chipotle app.)

Things that have annoyed me on iOS:

• The keyboard always displays capital letters, even when shift isn't selected. (I miss Swype a lot too, which isn't native Android, but replacing the keyboard isn't possible on iOS.)
• Lack of turn-by-turn directions in Maps.
• When an app loads, and it has multiple prompts, I see the first prompt, then immediately see the second. I have to respond to the second prompt before I see the first prompt again. It's a jarring user experience; the prompts should be serial instead of going over each other before a user can react.
• Prompting users for permission for push and location services on first app load is distracting. I'd much rather do that on app purchase/download like on Android.
• The iPod connector insertion is awkward. I keep thinking I'm breaking something.
• iOS presents the ability to sync with Gmail and Google Calendar from the phone, but not Google Contacts. (This is way better than it was on the 3G, where I had to do IMAP and iCal syncing manually, but still sub awesome for the legions of Gmail+Calendar+iOS users)
• Calendar and Gmail didn't background sync by default. They're pull systems - I understand that they could be push if I dug deeper, but that's annoying.
• At some point, the home screen instructed me on how to rearrange the apps. However, I'd already done that a few times.
• To change settings on some apps (and most iOS apps), you have to go to the Settings application. Why do I mentally have to context switch do change settings in the app I'm already in?
• I miss the hardware back button. Each app seems to have its own convention about how to go back. (On the other hand, at least in iOS it's clear what back goes to.)
• The screen doesn't get bright every time I turn the display on.
• The address bar / search box differentiation on the mobile browser is silly. Apple: please steal that from Android or Chrome.
• I need to authenticate repeatedly. I had to type my password to download a free app.
• There was no way to discover what "iTunes Match" was from the settings dialog asking me if I wanted to turn it on. (Much of the iCould stuff seems slapped on)

And here are some design decisions I disagree with, but aren't clear iOS problems:

• I miss widgets - desktop items that aren't simple app launchers.
• Apple charges money to take songs you've already purchased and crop them to ringtunes.
• App store policies and platform rigidity / control. Why can't I replace the keyboard? I wish it had deep Google Voice integration.
• Where's Siri? Why is Siri iPhone 4s specific?
• Fanboys. Actually, that could be true for both iOS and Android.

My conclusion? The iPhone has become more complicated since the 3G, and the user experience hasn't kept pace. Apple did a good job with Visual Voicemail - but Google Voice and its deep Android integration makes Android a better phone. I can place and receive calls and text messages from my computer or phone, and I can listen to my voicemails on my computer or phone. I'd give my mom an iPhone, but she'll still be confused for a while. The device for anyone who's frequently using the phone as a phone, or someone who wants to highly customize their device? Android.

The Matt Test

In 2000, Joel Spolsky (insightful software engineering blogger) introduced The Joel Test. It tests the bare minimum for a dev team with 12 easy questions:

Do you use source control?

Can you make a build in one step?

Do you make daily builds?

Do you have a bug database?

Do you fix bugs before writing new code?

Do you have an up-to-date schedule?

Do you have a spec?

Do programmers have quiet working conditions?

Do you use the best tools money can buy?

Do you have testers?

Do new candidates write code during their interview?

Do you do hallway usability testing?

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems.

It's not a perfect test of an engineering organization, but it's a great minimum. It's great for being over a decade old - but at a decade old, some of these seem painfully basic to me now (source control and bug database).

I would add a few:

1. Do you use Google Apps, or at least Gmail and Google Calendar?
2. Do you deploy at least once every other week?
3. Do you love your and respect your designer?
4. Do you have a Twitter account that replies to users?
5. Do you have design docs for major components that resembles reality?
6. Do you have a wiki that employees use?

More to come, I'm sure. This is a living document. 1-6 were added on November 2, 2011. I'll annotate the addition date for new ones.

INTP grieving

I've been playing with Myers Briggs types lately to understand myself and my relationships with others. I've been trying to understand where I come up short and where I excel, trying to figure out what my strengths are and what I would be better suited for in life.

One test said I'm INTP - Introverted (versus Extroverted), iNtuitive (versus Sensing), Thinking (versus Feeling), Perceiving (versus Judging).

My uncle (father's brother) Roger passed away this morning.

Roger is 10 months younger than my dad - and they have some scarily similar mannerisms. Roger and my dad shake their heads the same after swimming, they ski the same, their speech has the same cadence, heck, they even swear the same.

Roger, his wife Diane, and my cousins Mike and Nicole live in Truckee - under four hours from Palo Alto (where I live) and close to great skiing. I've become close with them - I've spent dozens of nights at their home since I moved to California. Roger and Diane are great hosts - they've even opened up their home for my friends. Every meal with them is engaging, and love is palpable around them.

He was diagnosed in April of 2010 with a stage 3 GBM tumor - basically a badass brain tumor that had a 5% survival rate at 6 months. He had incredible doctors, nurses, and surgeons, and in the summer of 2010 it appeared the cancer was kicked. He did chemotherapy but there was no sign on the MRI of cancer anymore.

In March of this year, the cancer came back. Roger underwent surgery, but nothing seemed to work. This summer, he had a ruptured appendix surgically excised. Roger had to pause too much of his cancer medicine while the wound closed. The cancer had been crawling stubbornly to kill him, and after the surgery it was running.

I got the call Sunday that Roger was doing poorly. He passed away this morning at home - a few hours after the 4.7 quake 20 miles northwest of Truckee. He was 62 - too young.

I got the call from my mom at about 7:45 this morning to tell me. And I didn't cry. I bet my mom heard a robot on the phone - I was close to my uncle. And my voice showed no emotion, heck, I didn't feel much.

I didn't feel numb, I don't feel much except when I think about the loss. Just thinking "My uncle is dead" doesn't make me sad. Thinking "I won't be able to talk to him again" makes me sad. When I go visit his home and Roger's not there, when I see family pictures of my aunt Diane and my cousins without Roger, when I see my Dad with Diane and without Roger, that's when I'll grieve.

I feel weird about how I don't seem to grieve - but that's my personality type. I struggle to feel what his death means until I think through the scenarios that are different. And when I do feel what his death means, I struggle to express it others. I think that's part of the curse of being an INTP - we grieve - but we grieve on our own schedule, we grieve when we are in the moment where something is lost, and we don't express our grief well to others.

I'm happy that Roger lived for 18 months when he was given 6. I'm better for having gotten to know him better than I know my other aunts and uncles. But I will miss him - something won't feel right for a long time when I'm with his family or even when I'm in the greater Tahoe area.

Algo interviews are overrated

Google loves algorithms interviews. Palantir loves algorithms interviews. Pretty much every tech company who prides themselves on hiring smart people spends at least half the dev interview time on algorithms questions.

I think algo interviews are overrated. Useful to some extent, but not the only thing and not as important as most engineers think. I think Steve Yegge (mentioned yesterday) would agree.

In my opinion, these are the important things in hiring a new member on a dev team. They are not priority ordered or of equal weight.

1. Ability to translate a problem into components.
2. Ability to reason through a problem and feel the solution.
3. Ability to keep trying and go deeper on problems unlike ones she's seen before.
4. Ability to translate these solutions into code.
5. A bag of tricks (data structure knowledge, technical knowledge) and the intuition that says "I bet there's a better way to solve this problem, I just don't know it yet."
6. Ability to build stuff.
7. Technical flexibility (can a SQL expert adapt to NoSQL? Can a Java person learn Ruby?).
8. Attitude. Is the candidate going to mesh with the team? Are they going to make coworkers' days better or worse? At Google, this was "Googliness".

Good algorithms questions can address points 1 through 5, though algo problems and every day coding problems don't map perfectly. Algo problems are too neat - they're like bowling with lane bumpers whereas everyday coding is like bowling without gutters or even lanes.

The real kicker: algo interviews don't gauge the ability to build stuff. Some companies get this and ask for you to build something for them. Airbnb and RockMelt ask candidates to spend time building something on their own. Square does pair programming so you can build something together (I interviewed at Square and feel that I was at a significant disadvantage because I don't know Ruby.).

Companies are wary about having candidates build something on their own time because it adds hours to the candidate's time load. Companies and candidates alike perceive asking a candidate to spend their own time (as opposed to shared interviewer-candidate time) as arrogant and pushing too much onto the candidate.

I think it's important to gauge how good someone is at building things ahead of hiring, but I haven't figured out a method to do it that isn't burdensome.

Another problem with algorithms interviews: the distribution of questions makes it possible for a candidate to have heard 80% of the questions you're going to ask before the interview. I'm not saying the candidate knows 80% of all the problems asked on interviews, but there's effectively a finite set of questions interviewers ask in a 45 minute interview. Algo questions need:

• Simple set up. The question needs to be intuitive and you can't spend 15 minutes for the problem set up.
• Bounded solutions. There's probably going to be one or two efficient ways to solve it.
• Non-esoteric solutions. Priority queues are awesome, as are tries, but they're rarely used outside of algorithms classes and algo interviews. Questions mostly come down to: divide and conquer, dynamic programming, hashing, merging, binary search, sorting, and iteration.

If you paid attention in your 100 level courses, and solve some example problems, you can probably pass your Google onsite with 10 hours of preparation. Steve Yegge (yep, I have a thing for him today) tells you how. Google has an internal list of banned questions that have become affiliated with Google, but even those are still often asked. Good algo questions are hard to find.

I've concluded that algorithms interviews can be gamed and I've concluded that even if they couldn't be gamed, they aren't the only thing to gauge during the hiring process. So where do we go from here?

• Find a way to have candidates build something during the onsite. I don't have the answer yet, but the closer to real work candidates are doing, the better the interview will be.
• Ask design questions. Not design patterns esoterica, but problems that almost beg the candidate to say "This is like something I did before! We solved it doing ..." and then asking about the other tradeoffs the person has made.
• Ask questions that speak to grey (technical) issues. Ask when they'd choose between GWT and jQuery. Ask when they'd take their HashTable and throw it into MySQL, and when they'd go from MySQL to NoSQL and MapReduces. See if they've gotten the feel for products they've developed before instead of simply hacking at them.
• Get a feel for the candidate. See if it's someone you'd enjoy working with when the server's been down for 3 hours and you still haven't figured out why.
• And yes, still ask some algo questions. See if the candidate has the gut feel of when to use HashSets, or if they're only into brute force solutions. Ask for the runtime - if someone really gets the solution, runtime is trivial.

Too many tech companies are measuring in great detail something that has poor correlation with career success. I haven't noticed it change much in the past half decade.

Five things every Carnegie Mellon student should do before graduation

If you spend more than a year in Pittsburgh, you should try to do all of these:

1. Visit the Frank Lloyd Wright houses Fallingwater and Kentuck Knob. (I've never been to Kentuck Knob - it's a shame since it's 7 miles from Fallingwater)
2. Visit Kennywood. It's the best old-time amusement park in the United States. Their halloween evenings ("Phantom Fright Nights") are great.
3. Visit Sarris Candies in Canonsburg. The ice cream parlor is old timey and the milk shakes are fantastic.
4. Visit Phipps Conservatory. Heck, go several times. They do a great job changing the flowers for the seasons - I love the Christmas poinsettia display, I love the butterfly exhibit - I pretty much love it whatever they do. And I'm not a flower guy.
5. Go down by Heinz Field at night - preferably when there's nothing going on across the river. The city by night across the river is serene.

Things Google does poorly

You may have read Steve Yegge's Google-sucks-at-platforms rant. I have no real opinion on it since platforms are not my forte. And I agree with him on a lot of positive things he says about Google in the run-up to the rant bit. It's easy to write about what Google does poorly because of the huge number of things they do well.

This isn't meant to pile on, but I do have criticisms about the way some things work at Google.

• One product, many leaders: Product teams usually are functionally aligned instead of product aligned. The PMs report to a PM VP and the engineers report to an engineering VP. The eng VP and PM VP have different priorities. And there are other roles: marketing, communications, support, design. There won't be a clear, unified product vision that management and employees are on board for - so teams can't be nimble and push forward. (Google has always had YouTube as a "business unit" where people across roles report up to one VP/GM/Director, and they've expanded it to other products, but it's not universal.)
• Too many cooks in the kitchen: The New York Times wrote an entire article about this: The Auteur vs. the Committee. Google does a great job of listening internally - every employee is encouraged to give feedback on every product. But at a certain point, a product needs to do some things well and figure out, in the future, what next to add. And that hurts feelings - employees often felt unseen and unheard when a product goes in a direction they don't like. I believe that before a decision is made, employees should work to make sure the best outcome happens and after a decision is made, employees (from CEO to individual contributor) should fall in line behind it.
• Managing out poor performers: Google is too easy to remain at. If you're a bottom 5 percentile performer, why would you chose to leave? You probably got in through a mistake in hiring, and you're probably not going to get as good a paying or perked job elsewhere. So you're going to milk Google until you can't milk it any more. High performers, who could go anywhere, hate working with low performers. Google knows they do a poor job managing people out, but is timid about getting rid of people. There's a delicate balance - cull the herd too hard and employees start getting stressed.
• Industry isolation (technology): There's too little knowledge of what else is going on in the industry. This argument and complaint has been made by many Googlers before - most Google internal technologies are a generation behind what the industry has come up with in terms of features. C++, Java, and Python are Google's 3 big languages. But none turn on the 20-something startup-bound engineers. Sure, Google infrastructure can scale, but it can't replicate the speed at which engineers at other companies can add features.
• Industry isolation (products): It's a company with hundreds of products and 31,353 employees (pre Motorola). It's hard to keep up with what's going on just in the company - and many employees don't have the energy to figure out what the trends are in the rest of the industry.
• Good but not great products: Google products are guaranteed to have many users. That's keeps new products from having tons of users. The PMs and management are playing it safe - trying not to fail - instead of making pure products that might win and might crash and burn. Instead of building intuitive, simple, useful products that do a few things, they're making products that do many things without engaging the user. Yelp, Foursquare, Strava, Gmail, and Google Search all started by doing one thing extremely well. What did Hotpot or Plus launch doing extremely well? On the other hand, Google is doomed by high expectations and high attention in this space - launch early with few features, and users may be disappointed. Those users won't give the product a second chance.
• Listen to their own support people: maybe this is because Helen is in consumer operations at Google, but I still think it's true. If Google's billion users all had one customer service request every three years, and each request took 10 minutes, Google would need over 20,000 support employees. But the issues that Helen deals with are the same issues, day in day out. They're fixable if the engineering will were there to fix recurring customer issues. But product people generally don't like blending engineering resources across new features, bug fixes, and customer enhancements. I love working at engineering centric companies, but I love more having happy users and customers.
• Hiring (employee side): Each interview took about an hour and a half - 15 minutes of set up (read resume, tweak questions), 45 minutes of actual interview, and a half hour of feedback. Doing full interview feedback on someone who bombed the interview was painful and demoralizing - at one point, I was allowed to write two sentences about why the person was a poor fit and moved on. Eventually, I was asked to do full feedback even for the worst candidates - I saw no benefit to it, and boy was that sucky.
• Hiring (future employee side): Want to pick what you work on? Nope. You'll get slotted. Start at Google, wait 12-18 months, and hope to transfer projects. I hate most ads (Google text ads for products usually excluded). I'm not working to put more ads out there. Ads are distracting and dehumanizing. During the recruiting process, candidates often don't know what's going and probably feel like a number. I recognize hiring at scale is a hard problem, but why isn't there a JobScore equivalent where candidates can log in, see whether they're waiting on recruiter communication, interview scheduling, interview feedback, hiring committee, etc?

I hope Google figures it out and can make better products. Change is painful, but out of the right pain comes something great.

Friends for different seasons

Today, Helen and I hosted the fifth annual Laroche Oktoberfest at our apartment. We cook wurst (usually from Dittmers, but Dittmers had a fire in January and still isn't open!), provide beer, and ask people to bring their favorite German themed food. This year, I provided an Oktoberfest homebrewed beer as well - my first homebrewed lager!

One of my friends mentioned "I made a faux pas - I asked [former coworker] if he was coming today - and he didn't know about it." The former coworker is an awesome guy, someone I like talking to and seeing in situations like this. But I know a lot of people - I would have loved to invite about 20 people today - and then there's Helen's invitees too! But there's two problems with inviting everyone I want: First, I like events at about 6-12 people. It's enough to have 1-2 conversations going on, give everyone a chance to speak, and get to know each other. And second, I try to pick groups of people who I think will match well to the event - there's grill guys and German food guys. There's loud folk and contemplative folk - and I want a different type of friend at different events.

It's hard to avoid hurting feelings, though - I want to put things on Twitter and Facebook, but I don't want people hurt that I didn't invite them, especially if I invited them last year.

One solution: host more events!

Becoming more conscious on food

I am a terrible moderators. If I tell myself "I can only have a little sweets today," I end up having a croissant, a bag of peanut M&Ms, and cake with dessert. If I tell myself "I will only have a little cheese" I'll have a ton of it. I ... I don't understand moderator. I'm all or nothing. To eat properly, I can't moderate bad foods - I need to abstain.

Most of us spend some time at a not quite conscious level. It's those times where we can't articulate what we're doing, or have some kind of breakthrough when we explain the problem to a friend.

When I lost weight, I logged what I ate into a food notebook. Technically, this was to show my trainer - but effectively, writing food in my notebook kept me honest to myself. Logging what I ate created a consciousness that I lacked. I stopped writing down what I ate because my weight was low, I was exercising strenuously, regularly, and I was eating perfectly. Then I had surgery and gained some back. I'm back on a writing-down-what-I-eat-kick, and I already am finding myself not eating something because I know I will have to write it down later. I find this silly - the log isn't reality, the food and the effect on my body is the reality. However, it works, so I'll keep at it!