Hello. You all know Catherine.
We've been making the course together.
Today, we have a really special guest for you.
Alice works for Google and has been working there for-
>> 11 plus years.
So, we're going to talk about Alice's journey in terms of her first interview,
how she solves bugs, and some advice Alice would
give herself, from way back when, when she was wanting to learn programming.
Shall we begin.
>> So, Alice, can you tell us about your role at Google now?
>> Sure. So, right now, I'm a TL for
a new project.
TL is for tech lead.
>> Oh, okay.
>> For a new project on Android.
It's in the very early stages so
I can't really talk about exactly what the project is.
>> [LAUGH] >> Wow.
>> But I can tell you a little bit about
what I've been doing the last few years.
>> So, let's start at the very beginning.
>> The very beginning.
>> So, you come in and what happens the first few years.
>> So, the first six years at Google, I was in AdWords, AdWords front end.
So, AdWords is basically how Google makes money.
So, when you do a Google search,
all those ads that pop up on the right hand side.
So, I worked on, and AdWords back then,
it was like the first group at Google who was doing Java,
all the other engineers were C++ engineers, like on search.
>> Oh, I didn't know that.
>> Yes, so, we were the first Java team.
And we set a lot of standards about how Java was going to,
setting the Java coding style, for example, and what tools to use.
So yeah, it was very fun.
I think it was, back then, it was small.
I remember carrying the pager for AdWords.
On weekends, all the engineers take turns carrying the pagers.
So, if a server goes down, you have to be prepared to log in,
reboot the machine.
It was before we had SREs.
SREs means site reliability engineers, I believe.
>> Okay.
>> So, yeah, it was very different from- >> I had never imagined that
when a server goes down there are literally pagers
going off- >> Oh yes.
>> In the background where people are sort of hustling to try and
get the machine up again.
>> Yes, they can go off like any time of the day, 4:00 AM.
>> Mm. >> So,
it's kind of like a doctor being on call.
>> Mm-hm.
I'd imagine that as thrilling as it was for
you to get the job, some parts of the job may be stressful.
Like this idea of this pager is going to go off and
interrupt the fun that you were perhaps having.
Do you recall any instances where you felt like this is really stressful and
hard work that we are doing?
>> So, I think when I was on Android Gmail,
I think that was actually pretty stressful time of being TL.
>> Okay, so we moved on from AdWords, so you're now doing Gmail, but for Android.
>> Android, yes.
>> Okay. >> So, actually, Catherine and
I worked together on Android.
>> Oh, nice! >> That's how we met,
that's [INAUDIBLE] together.
But, yes, so, Android is very different from AdWords.
I think mainly because it's a consumer product, so
it's just a different set of users, it's a lot more users.
And on Gmail particularly, because it's one of the most used apps on Android,
just the pure number of bugs that we get is just insane.
At Google we have this thing called dog fooding.
That means if your app is ready to release, your new version,
then you test it internally, among all the Googlers.
So you kind of dog food your own products, eat your own dog food.
And for Gmail, every time we dog food a new version people will be so
passionate and found so many bugs.
We move one button from top right corner to the bottom right corner, and there
will be like 20 people complaining about it changes their work flow, for example.
So I think making those decisions was really tough,
because it's hard to find a solution that pleases everyone.
>> So, it may be surprising for some of our students to understand, but
this idea of feeling frustrated because a bug has been encountered,
is not something just the novice programmers are feeling.
Even expert programmers like you Alice can get bogged down by them.
Do you have a strategy or tool you follow when you say come across a bug?
>> So, it depends on the type of bug.
So, bugs can be very different, the most I
guess important or high priority bugs are crashes, for example.
Your app is just not functional.
And those are probably ones that will get looked at first.
They'll flag that as P0s or P1s, and
also it depends on how reproducible it is.
>> P, in that stands for priority, I imagine.
>> Priority, exactly, yes.
P0, P1, P2, >> An engineer who received the bug,
think of a bug, and
what would be your strategy to going about fixing something like that.
>> Bug fixing is one of the most, it's like a very easy way, or
quick way to feel like.
You fix this bug and it's very rewarding because I can mark it as fixed and
it's like I accomplished something.
I think usually, first off, is trying to reproduce it.
So, if it's reproducible, then it's much easier to fix.
>> Mm-hm.
>> The hardest bugs are the non-producible ones,
something that on Catherine's Android device you saw, but
then on my phone I was never able to reproduce.
So, that's much harder.
So, if it's reproducible, then I can easily just look at the logs,
ADB logcats on Android devices.
And then see what happens.
If it's a crash then there would be a very obvious stack trace.
>> So, you're like an investigator, you're looking at clues for
why this thing might be breaking?
>> Exactly. Yes.
And Android bug reports are actually notorious for
being really cryptic and hard to read.
Yes.
>> It's not just us.
[LAUGH] Oh no, yes.
>> I find them to be very verbose and cryptic also.
>> Yes, I think it's one of the big challenges actually.
So, that's where experience comes in.
So, if you're an experienced Android programmer,
you know exactly which keywords to search for.
It's impossible to just read line by line by line.
I usually just like prep for or search for certain keywords.
>> I see. So,
you're scanning through the entire log and you're looking for
keywords that you can Google.
>> Yes. >> Okay,
why are you Googling these things?
>> Well, I do a search locally, just like a find.
But Google comes in handy because often if there is an error and
it's something I'm not familiar with, it could be like Android Framework doing
some illegal state exception or something that I've never seen before.
>> Mm-hm. >> So, the first thing I would do is
actually Google it.
>> Okay.
>> And yeah, and usually on let's say, stack overflow,
there's almost always somebody else who has encountered the same.
>> Is to follow similar processes.
>> Yeah. >> Where they find a bug,
they try to identify a key word that they can search on Google?
>> Yes.
>> And try and interpret those results, and try and fix the bug.
Now, what's really satisfying, at least for me as a teacher,
here to learn is that the process that we're teaching our students is being
followed by an expert 11 years into their program.
>> Yeah, yes.
[LAUGH] >> And you mentioned a statement which
was really emphatic to me, which is, if I don't know something.
>> Mm-hm.
>> And that's really important to understand, that even after 11 years of
expertise, there are so many things that one might not know.
>> Yes, it's impossible to know everything.
And, yeah, I realize, there's something new to learn every day actually,
and at my job I feel like I do indeed learn something new every day.