MALE SPEAKER: Welcome, everyone.
It's my pleasure to
welcome all of you
to Professor David
Patterson's talk.
David Patterson probably
needs no introduction.
He's been a professor
of computer science
at University of California,
Berkeley for 40 years now.
And he's made a lot of
pioneering contributions
in computer systems, a lot
of which are technologies
we use at Google and elsewhere.
So RISC, reduced
instruction set computers,
RAID, Network of
Workstations, and a lot more.
He has a pretty long bio here.
I didn't realize he
has won 35 awards.
And all of them are
pretty prestigious.
National Academy of Engineering,
National Academy of Sciences,
Silicon Valley
Engineering Hall of Fame,
IEEE [INAUDIBLE] medal.
And I'm sure I'm offending
some significant award by not
saying that, but he's had a
very distinguished career.
And this talk today,
in his own words,
collects advice that
I wish I had been
given when I started my career.
And given how
distinguished that's been,
I think it's a talk we are
ail going to benefit from.
So, welcome.
DAVID PATTERSON:
Well, this is-- what
happened is I decided-- somebody
wrote me these slides are
about how to have a bad career.
I've been out there
for a long time.
And they asked me if
there was a video of it.
And I couldn't find one.
I actually figured out that
I gave this talk first 20
years ago, but I've
given it over the years.
So I decided to
record it at Berkeley.
And it ended up-- and
I announced my plans
to retire two days before this.
So it got a lot of visibility.
And it's fun to come here.
As far as I can tell, all
of my-- oh, yeah, sorry.
As far as I can tell,
all of my former students
are going to end
up here some time.
Also, I have to ask
them, if they're
leaving, where they are.
I know where they're ending up.
And so it feels like
it's a home week here.
As I said, this is
the advice I wish
I would've had in my career.
This got started
about 30 years ago.
I decided I wanted to
give advice on talks.
So I wrote, "How to
Give a Bad Talk."
And that was a lot of fun.
And about 10 years later,
"How to Have a Bad Career."
And about a couple
years ago, I did "How
to Have a Bad Research Center."
So this is my bad series.
Now I'm just going to put
the-- if you're interested,
these slides are certainly
available as well as the talk.
And there's a lot
of papers and things
that you can cite if you
want to read more about it.
And I'd like to thank a bunch
of people for making suggestions
that I've incorporated, or
their careers inspired them.
One of those two.
So the parts-- there's two parts
to the talk, the kind of tongue
in cheek how to
have a bad career
and then how to
avoid a bad career.
And then I'll open up for
questions and answers,
and then I'll wrap
things up whenever
we have to wrap things up
and take the last 5 or 10
minutes talking about my
story, how I got here,
and what works for me.
So you want to be a
leader of the field,
especially if
you're in academia.
So how can you do that?
Well, invent a new field is
a really good way to do that.
And you want to be the
only person in that field.
So how can you invent a field
and then be the only person?
Well, one way is, different
from other fields,
you want to be the lone ranger.
And a way you can
be the lone ranger,
the only one who is there,
is your personality can help.
If you adopt the Prima Donna
personality-- and some people
don't know what
a Prima Donna is.
But if you adopt
that personality,
nobody will want
to work with you,
and you can drive people away.
And then you'll be the
world's leading expert
because you're the
only one in that field.
In terms of the research
horizons for your new field,
you want to have a lot of
flexibility on success.
You don't want to get too far.
And if you say
it's 20 years out,
then you've got 19 safe years.
And nobody's going to accuse
you of doing engineering
work if it's 20 years out.
And stick to that topic
for your whole career.
Now if I'd only
followed that advice--
my dissertation was
on micro-programming.
If I had stuck to this,
I would absolutely
be the world's expert
on micro-programming
partly because no one's built
a computer with microcode
in 25 years.
And you kind of think of
it like it's like fashion.
Skinny jeans are popular now.
They were popular 25 years ago.
If you had just kept them, you
could reuse your old jeans.
So research is like that.
Wait.
It'll come back to you.
OK.
Let complexity be your guide.
Confuse thine enemies.
The best thing you can
say, it's so complicated.
I can't understand what
you're talking about.
You've done a good job.
One reason is it's easier
to claim credit for things.
If somebody else
has done some work,
you can say, well,
that was in my paper.
And since they
don't understand it,
how can they contradict you?
The other thing that's
surprising-- it's
really a lot easier
to be complicated.
You read the first end
papers, and then you
figure out the next one.
And people publish it.
It's really much harder to be
simple than to be complicated.
So that's the easy way to do it.
And this sentence
captures it, right?
If it's unsimple, how could
distinguished colleagues
in departments around the
world be possibly appreciative
and so on and so on?
There you go.
That's the way to
speak and to talk.
Never be proven wrong.
The first thing you want to do
is don't implement anything.
It's hard to prove you wrong
if you don't implement it.
Now if some out of control
colleague builds something,
then whatever you do, don't run
any quantitative experiments.
If they're not quantitative,
then you can't be proven wrong.
You've got the intuition.
You can just kind of
extrapolate with the results
that there are, put that
in without any experience.
And your job isn't
to help the critics.
That's their job to figure out.
Don't help them out.
Now another reason
is that clearly
the success of the career is
to publish as much as you can.
And it takes time to
build and to measure.
So if you don't do that,
you can get more results
and have a more
successful career.
If somebody does it, the
last thing you want to do
is run any benchmarks,
because then they can compare
your results to other things.
The advice being that
you've got those safe years.
And the benchmarks
can just-- the way you
get out of that is to
say, well, this computer
is for future programs,
not for current programs.
And then these
benchmarks are too
antiquated to run
on my computer.
Now the other thing that
we do in computer science
is we reject all the past.
We're a new field.
We're both science
and engineering.
So we're not hide bound
by old fashioned things
like the scientific method.
We have the computer
scientific method.
Instead of a hypothesis,
we have a hunch.
A sequence of experiments.
We know that sequential is slow.
So what we do-- we
change one experiment,
all the parameters at once.
That's much faster than
the sequential approach.
Parallelism is a good idea.
And rather than prove or
disprove our hypothesis,
we discard if it doesn't
support the hunch.
There's lots of data.
It's a big data.
Throw away the data.
There's still
plenty of data left.
And document for
others to reproduce?
We've already done it.
We'll have more
results of the field
if we don't waste our
time trying to reproduce
each other's results.
That's the computer
scientific method.
Don't be distracted by others.
Avoid feedback.
A big part of that
is conversation.
And if you don't
say anything, people
might think you're
not very smart.
So the corollary of that
is loud is smart, OK?
So be loud in conversations,
even when you don't
know what you're talking about.
People will think you know
what you're talking about.
If you're the world's
leading expert,
you don't really need
to read other things,
because you're
the expert, right?
And you don't have to interact
with others because they're not
as good as you are.
In terms of doing
reviews for paper,
if it's simple and obvious,
insult the prior authors.
If you accepted something
simple and obvious,
they probably thought of
it, so you should reject it.
If they're quantitative
results-- and I've
gotten this review before.
Well, I already knew that.
So there's no
surprise to reject it.
And everything else, you
might as well just reject.
They're kind of competitors
to you in some way.
And if their paper doesn't
get published, then you win.
So that's a good guideline.
Now, publishing journals
is technology transfer.
You're the leading
person in the world.
You're the expert.
All you have to do is
write in a journal.
It's not your job to make
it understandable to others,
to the ordinary engineers.
Going to conferences just wastes
some of your valuable time
that you could be coming
up with new ideas.
And having to interact
with industry and things
like that-- that's
a time waster.
You write the journals.
You're done.
Now clearly, the winner is
the one with the most papers
at the end of the career.
So I've come up with
this pyramid of success
for publication.
It follows the rule of four.
And the guideline is the
LPU, least publishable unit--
the LPU is good for you.
So you start off with one idea.
Then with the rule of four,
you get four journal papers out
of that.
With the miracle of
world processing,
then you can get 16
extended abstracts
and 64 technical reports
from one single idea.
That's 84 publications
gets that.
And then in terms of
getting credit for it,
my advice is to change your
name to the Swedish spelling
of Anderson.
And then there's
the awkward time.
Oh, how are we going to put
the authors on the table?
You'll just say, well, I've
always done it alphabetically.
All my papers [INAUDIBLE].
All right.
Writing commandments
for a bad career.
Thou shalt not define terms.
That's what
dictionaries are for.
And explaining things-- that'll
just insult the readers.
So you want to be a little
bit more mysterious than that.
Thou shalt replace I will
build with I have been built.
Probably by the time your paper
gets published in a journal,
somebody will have
implemented it.
So it's OK to do that.
Thou shalt not mention
drawbacks to your report.
That's not your job.
That's the job of the critics
to figure out the drawbacks.
If you hide that,
they'll never notice it.
Thou shalt not reference
any papers, again,
except for maybe your own
or at your institution.
And if the papers
were any good, they'd
be people at your institution.
So don't do that.
And then you should
publish before implementing
because that's when your
system is the fastest.
OK.
Talk commandments
for a bad career.
This is my bad career talk.
Thou shalt not be neat.
Why take the time to
spend it on your slides
to fix spelling errors,
grammatical errors?
You've can spend that
time on research.
Thou shalt not waste space.
You use up a lot of slides.
That's a lot of kilobytes
being wasted there.
You can save, like,
100 kilobytes a year,
which saves some money.
Thou shalt not covet brevity.
Do you really want to
sustain the stereotype
that engineers can't write?
You want to show full
paragraphs, beautiful English,
and read it aloud.
Thou shalt cover
thy naked slides.
I'll show you what I
mean by that later.
But you don't want to expose
the whole slide to everybody
and shock them.
Thou shalt not print large.
The important people
sit in the front.
So who cares about
the guys in the back?
Thou shalt not use color.
Use of color indicates
uncareful research.
You're emphasizing
some words over others,
and it's just too
showy to use color.
Thou shalt not illustrate.
Confucius says, a picture's
worth 10,000 words.
Who cares about the
wisdom of the ages, right?
And thou shalt not
make eye contact.
You want to be humble, kind
of pretend to be humble
and keep your eyes down and
try not to let anybody see you.
Thou shalt not skip
slides in a long talk.
I guarantee you, in
this room, somebody
has looked at their watch,
seen how many slides they have.
And their solution is,
I'll just talk faster.
That's what people do.
You prepared the slides.
They want to see them all.
And if you have to, just
cut off the conclusions,
the last couple of slides
if you run out of time.
And then this is
the golden rule.
This one can save you, even
if you violate the others.
Thou shalt not practice.
How can you be spontaneous
if you practice?
It'll feel practiced
if you practice.
So don't do that.
That's the last
thing you should do.
So here's an
example of doing it.
It actually says PowerPoint,
but it's using Google Slides.
So trying these commandments.
So print small.
Now these features,
some engineer at Google
put these features in.
So you have to use them to
be a good Google employee.
So you want to hide
your naked slides there.
That's some variety.
But again, no use of color.
There you go.
That's another
dramatic entrance.
And then the next one
is just my favorite.
I'm glad somebody
put the time in
to put this in because
it's very useful.
There you go.
OK.
So that was the
bad career advice.
Let's talk about the
alternative career.
This is taken from my career,
which spanned 40 years.
So it's kind of an academic--
I hope it'll apply to here.
It's in systems, not in theory.
And I'll go through
these pieces one by one.
So advice to writing bad papers.
And again, I put some
writing tips there.
The writing tips actually
have some grammatical errors
in them, following
my bad tradition.
But you can go take a look.
So do the opposite of the
bad paper commandments.
Do define your terms.
Distinguish will
do from have done.
If you're writing
for critical review,
reviewers are very
skeptical people.
They're going to
assume the worst.
They are much more
impressed if you point out
the drawbacks rather than
they have to discover them.
And you have to measure
performance and reference
the work to be a scholar.
And the good news is you guys
built a wonderful service
to make that much easier to do
these days in Google Scholar.
The best piece of
advice I ever got
was to read Strunk and White.
Strunk believed in
brevity so much,
he cheers brevity so much, he
couldn't write a long book.
The book itself is
maybe 80 pages or so,
and it's chock full
of good advice.
Then the advice is basically
go kind of top down.
You write a one page outline
with a tentative title
with budgets, how much
you need to write.
That saves a lot of writing,
if you don't have to do it.
Then a paragraph map, which is
a topic sentence [INAUDIBLE]
all the way through.
And it includes
figures and captions.
Even today in 2016,
it takes forever
on a computer to draw a figure.
And since you're probably going
to throw that figure away--
you'll change it--
the best technology
to do that today is
go to a whiteboard.
You can have colored pens.
Take a little cell
phone picture and stick
that in your document.
That'll take you 1/10
the time as trying
to do something on a computer
because you might throw it
away.
And then write the draft.
I like the Scientific
American style,
which has really long captions.
Not everybody does that.
But you can move text in there
and associate with the figure.
I think that works well.
I really like tables a lot.
There's a lot of dirty facts.
I love putting them into tables.
That works well for me.
Then in terms of when you're
starting to polish the text,
read aloud.
Your ear is better
than your eyes.
When I start reading a
document, and I forget,
and I stop saying it
out loud, I lose track.
But if you hear
the words, you can
hear terrible sentences
and grammatical errors
if you hear it.
There's technology.
In fact, I just learned
about this thing.
It was from an
English professor who
taught a massive open
online course at Berkeley.
I said, why aren't you
using a grammar checker?
And she said, this is
the world's best one,
Pearson Writer.
And it costs you a
whole $20 a year,
and it'll prevent terrible
grammatical errors.
And even it'll help style.
In fact, I was thinking,
you guys should buy this.
It's one of the
things you're missing
from Google Documents
is a really--
and this is the
world's best one.
I'm impressed that
they can pull this off.
And then you get
feedback from friends.
Of course, to get
feedback from friends,
if you're writing to a
deadline, you actually
have to get it done
early, which seems
to be science fiction, for
graduate students at least.
But get it done early.
Then it gives you time to give
to your friends for feedback.
You can iterate.
And if you don't
do that, if you're
writing something for review,
then who's your reviewer?
It's the program committee.
And what I've seen sitting
on program committees
is a lot of the time the paper
gets rejected not because you
didn't do something.
It's because the
program committee
didn't understand what you did.
And if you interact
with outsiders,
you've got this
chance of clearing
that up as opposed to if you
just look at it yourself.
OK.
How to not write bad papers.
Bad talks.
Basically, do the opposite
of bad commandments.
There's two parts,
preparation and practice.
Most people take about
two minutes a slide.
For some reason, I take
one minute a slide.
I don't know why.
You should plan on that, a
minute or a minute and a half,
so you have plenty of time.
And leave time for
questions since that's some
of the most important parts.
Despite Google engineers
putting in spinning text,
don't do that.
And then, it's not
a speech, if this
is the first time you do it.
It's a talk.
So you don't have to memorize
it, but have notes ready.
Practice is the key.
You want to do dry runs with
friends to get feedback.
If you're giving a
professional talk, the way
you make an impression is
not only to give a talk
but how you answer
the questions.
I think for those
of us in the field
a while, when you see
somebody give a dynamic talk,
and they really
nail the questions,
you pay attention to that.
And then so your practice ought
to have really tough questions
so you can practice
tough questions.
And then with modern
cellphones, you
can record yourself,
not only your audio.
You can watch yourself.
I got to tell you, it's going
to be a humbling experience.
You'll hear the crutches that
you have in your verbal speech.
I start a lot of
sentences with so.
I say huh.
You'll be shocked how bad it is.
Everybody does it, and this
is the way you get better.
And I practice everything.
I think of it-- I
practice my talks just
to show the students
that you're supposed
to practice your talks.
But I practice my award
acceptance speeches,
and they tear them apart.
I would think an acceptance
speech is pretty good.
But no, no.
Make them better.
So practice.
OK.
Now the other thing that I
was going to do in this talk
is quote Richard Hamming.
Richard Hamming actually
came to Berkeley
when I was young as a
professor, a larval professor.
And he gave this talk,
"You and Your Research,"
which is more or less how to
do great research like me.
And so Richard Hamming of
Hamming code, you know,
Hamming distance, the reason
memories don't make mistakes,
spent his career
mostly at Bell Labs.
And it's pretty clear
from watching these videos
he's a very opinionated guy.
He's not saying, well,
maybe you should do this.
He says, do this.
But he watched careers
over at Bell Labs.
He saw people fail.
He saw people succeed.
And I'll quote him, show a
one minute segment every time.
So this is him talking about
the importance of communication.
And you'll get his
personality from this one.
[VIDEO PLAYBACK]
-Which brings me to the
topic of communication.
You need to learn to
communicate orally
in talks like this,
written in written reports,
and casual conversations.
In the middle of
a conference, you
have to be able
to get up and say,
that's wrong for these reasons.
Bing, bing, bing, bing.
And you win.
If you sit around
and say, well, I'll
write a report tomorrow
after I've thought about it
some more, the decision's made.
We go ahead, and it doesn't
matter what you do then.
The ability to communicate
at three levels.
Now, how do you learn it?
You can read books if you
want to, but forget it.
The way you learn, as
far as I'm concerned,
is every time you
go to a talk, you
listen, not only to the talk,
but to the style that's done.
What talks are effective?
Why were they affect?
What aspects of the
speaker can you adapt?
[END PLAYBACK]
DAVID PATTERSON: OK.
That's Richard Hamming.
And then--
[VIDEO PLAYBACK]
-Which brings me to the
topic of communication.
You need to learn to communicate
orally in talks like--
[END PLAYBACK]
DAVID PATTERSON: Stop.
Stop, Richard.
And then he-- he gave
this talk lots of times.
This is the one that's
on your YouTube, right?
That's how I found it.
But there was a text one before.
And he said, in my
early days, I think
you should spend as much time on
polishing and presenting as you
did in the original research.
Now at least 50% of it has
to go in the presentation.
Now if you know Hamming's idea
of how do you encode memory,
it's beautifully presented
that almost everybody
can understand.
So that was an example of him.
He not just came
up with the math,
but he laid it out and had a
very simple encoding thing.
It's almost like a parlor trick.
You can put a bit
pattern there, and it'll
tell you which one is wrong
from the way he does it.
He made it very
easy to understand.
And as a result, every
single computer in the world
uses his idea.
But that was an example of
him following his own advice.
[VIDEO PLAYBACK]
---this, written--
[END PLAYBACK]
DAVID PATTERSON:
Come on, Richard.
Right.
I think I can get him to stop.
OK.
OK, leading a project.
Now I'm going to go through
the-- I think I said this.
So academics have
bad benchmarks.
Papers or maybe even
citations rather than impact
is what you're trying to do.
I didn't realize
when I started, I
have six phases for
winning your project.
And we'll go through those.
Selecting a problem, picking
a solution, running a project,
finishing a project,
evaluating it,
and transferring technology.
So let me go through
each of those.
Let's go back to
Richard Hamming again.
He's going to talk
about the importance
of picking a problem.
[VIDEO PLAYBACK]
-And so I said, do you
mind if I join you?
So I sit down.
And we talk about chemistry.
[END PLAYBACK]
DAVID PATTERSON: Let
me set the stage here.
So here's this pretty
opinionated guy
who studies how
people can be great.
It's kind of a hobby of his.
So at Bell Labs, one of the
greatest research institutions
in the history of
this country, he's
been having lunch
with physicists.
But they start winning Nobel
Prizes inventing the transistor
and things like that
and got promoted.
So he had to find a new group.
So he decided to hang
out with the chemists.
So he just kind of
butts his way in
as this outsider to
talk with the chemists.
[VIDEO PLAYBACK]
---and things for a long while.
And finally one day,
I walk in and say,
if what you're working
on is not important,
and it's not likely to
lead to important things,
why are you working on it?
After that, I ate
with the engineers.
That was spring.
In the fall, going down the
long quarter at Bell Labs,
my friend, a chemist, stopped
and said, you know, Hamming?
That remark of yours
got underneath my skin.
I've spent the summer thinking
about the important problems
in my field.
I have not changed my
research, but I think
it was well worth the time.
I say, thank you,
Dave, and walk on.
About two weeks
later, I notice he's
made head of the department.
About 10 or 12
years ago, I noticed
he is a member of the National
Academy of Engineering.
I have never heard of anything
about any other person
at that chemistry
table, not one.
The one man who could
hear, if what you are doing
is not important or not
likely to be important,
why are you doing it?
The one man who could,
did become important.
He did succeed.
The rest of them who
couldn't hear didn't.
It's that simple.
If you don't work on
important problems,
you are not going to
do important things
except by the
dumbest of dumb luck.
[END PLAYBACK]
DAVID PATTERSON: And you realize
when he's giving these talks,
the chemists that
he was sitting with
were still around and could
hear him give these talks.
A charming guy.
OK.
So selecting a problem.
When I started at Berkeley,
I just jumped to it.
I'll tell you about
it in the next one.
Invent a new field
and stick to it.
No.
Try and do real stuff.
Make sure other people think
it's important, not just you.
It's particularly easy
to do that in academia.
You're aiming for this positive
impact, big impact on computer
science and engineering.
And stick to it
your whole career?
I think in this fast--
that's not what I did.
In this fast moving
field, why not instead do
a bunch of short projects?
Because a lot of research
projects aren't going to work.
These things always take
longer than you expect.
And how are you going to
know if you work on something
for 20 years that this is going
to be an important problem
for 20 years?
And what we found by doing
lots of five year projects
is that learning was more
of the number of projects
than it was the number of years.
As you tackle something, it was
the new thing you learned from.
And then a lot of times--
this, I'll say-- research
doesn't work out.
And you'd like to fail sooner
rather than fail later.
What's worked well for
us is multidisciplinary,
multi-investigator
projects, trying
to have somebody from multiple
fields on a single team.
And then try and figure out
the strengths and weaknesses
of your local environment.
Universities are different.
There's strengths that
obviously Google has,
and there's weaknesses too.
So try and figure out something
that matches your environment.
And make sure it's exciting,
that you want to work
on it for several years.
And what I've found is a
compelling prototype-- if we
can build this
thing, it's really
going to be amazing--
is inspirational.
OK, so that's
selecting the problem.
My first project, when I got
to Berkeley 40 years ago,
I spent about a week
thinking about it
and joined some other faculty.
And it was
ridiculously ambitious.
Three hardware faculty were
designing our own instruction
set, build our own chips,
build our own interconnection
network switches, board
systems, operating systems.
We didn't have any
experience in any of it.
We didn't have any
research funding.
We didn't have any
computing or CAD tools.
So what happened from all that?
You know, a couple
of papers, right?
Not bad for academics.
Fortunately, I took a sabbatical
during that time and went away.
And it gave me a chance to
think about things differently.
And I came back and
did the RISC stuff.
Otherwise, I wouldn't
have tenure today.
Picking a solution.
Let complexity be your guide?
No.
Keep things simple, unless
you've got a really good reason
not to.
I came up with this
phrase early in my career.
It's intelligence beans.
On any project, you have a
sack of intelligence beans
that you get to spend.
So decide where you want to
spend your intelligence beans.
And then were it
doesn't matter, you
can use the common solutions.
And the best result
you can possibly get
is afterwards for
them to say, anyone
could have thought of that.
That doesn't seem
so complicated.
Anybody could have
thought of that.
You've achieved things well.
Complexity costs everything.
Longer design, construction,
testing, and debugging.
And these delays lessen
the impact of what you do.
So try and keep it simple.
It's hard to keep things
simple, but that's the goal.
The computer scientific?
Nope.
You want to run experiments
to discover real problems.
And as my friend John
[INAUDIBLE] says,
you use your intuition to ask
questions, not to answer them.
We're really smart people.
We can make up what we
think the answer is.
But that doesn't
mean they're right.
What we need is to figure
out the experiments
to figure out the real answers.
So at Berkeley,
they ask me, well,
how do you pick a
problem and solution?
What we've done
over these years,
these five year projects is
before the end of a project,
we start meeting
for at least a year
to start talking about
what the next one would be.
We spend that much
time thinking about it.
Typically, what
we've done is saying,
what are some interesting
technology trends that
are happening over
the next five or 10
years that will shape
the future of computing
eight to 10 years out?
To see if the mix
of these trends
have some new opportunity.
For RISC, it was probably
computer scientists
being able to do
integrated circuit design.
There was Moore's law
that was taking off.
So a 32-bit microprocessor
was plausible.
What's the right way to
design such a microprocessor?
For RAID, personal computers
were getting popular.
They started building
hard disks for them,
these so-called
small hard disks.
They were inexpensive.
Performance for input,
output was slow.
Processors were getting
faster because of RISC.
Disk performance was slow.
Maybe we could do something
with a lot of them.
For the Network of
Workstation projects,
not only were workstations
getting really fast,
but there were beginning to be
local area networks switches.
Could we just build
a big computer out
of a bunch of these components?
And then how would that work?
Another thing that we've
noticed over the years
is when you're all by
yourself, and you're
going to work in a new
field, it's very scary.
But if there's a group of
you with different areas,
and you kind of go
after this thing,
there's kind of
safety in numbers.
You aren't all
risking your careers
working on machine learning.
But the three of
you working together
seems not quite as scary
to be able to do that.
And a big thing when
you've got these ideas
is to find people whose
opinion you trust and try
and get their feedback to
help you shape your vision.
You don't have to do
exactly what they say,
but you ought to hear
what they're saying.
And then pick a good name.
Apparently in some
parallel universe,
I'm in the marketing department.
But it's not that hard.
I have these
friends who show off
their Latin education who pick
some name nobody can possibly
spell.
And they even have
a word for it now.
You pick the name, and then
you backfill in the acronym.
And so they're called
backronyms, right?
Nobody's ever going
to remember that.
One of the projects my younger
colleagues picked is aspire.
It's actually 11 or 12 words.
Nobody but him can remember.
So if that's true-- if you're
going to use the acronym model,
it's got to be three or
four letters if anybody's
going to remember it.
The way we do it is
put a bunch of words
on the wall that
describe the project.
Vowels are really valuable.
And you want to try, three or
four letters-- three or four
letters that are an English
word that kind of have something
to do with the project.
But I'm available
as a consultant.
Running a project.
You want to avoid feedback?
That's one of the themes.
No.
We do these periodic project
reviews with outsiders.
We've been doing them for 30
years, twice a year, three day
retreats.
How many people here have been
to a Berkeley style retreat?
All right.
That's like a dozen of you.
And the outsiders are valued.
Huge benefits to doing this.
At the end, we get the
feedback from everybody.
And we don't argue
with that feedback.
We try and understand it.
It also creates deadlines,
which are tough everywhere,
but particularly in academia.
It builds team spirit.
And for the people
working on it,
it gives them a chance
to communicate and spread
their ideas,
interact with others.
Consider a mid-course
correction.
Our first project
that I was doing-- it
was a multi-processor.
The RISC ideas were just
starting to catch on,
but they hadn't
been commercial yet.
But by midway
through the project,
there were commercial
chips like MIPS and SPARC.
We should have
redirected our project
to be used in
commercial processors.
But I felt like that was
breaking our promise,
and we should have stuck with
the ones that we did custom.
But we'd have had a
much bigger impact
with a multi-processor
RISC project
then if we'd used
commercial instruction sets.
So that's part of
our culture now.
It's a five year project.
Two and a half years
in, maybe the world
has changed in some way.
And you should take
advantage of it.
An example of that would
have been the RAD Lab, which
was a couple of projects ago.
We were doing internet services.
And then cloud computing
got popular in it.
So we embraced that, and that
became a big theme of RAD Lab.
Pick the size and the members
of the team carefully.
Tough personalities are
hard on everybody, not just
tough personalities for faculty,
even tough personalities
for students.
It can make it no
fun to come to work.
So try and get good people.
I think Berkeley
consciously tries
not to hire Prima Donnas,
which makes it nicer.
And if you have one expert per
area, it's a little easier.
My colleague,
Kathy Yelick-- I've
got opinions about programming
language compilers,
but when she speaks, I listen.
And that makes it
easier to do things.
Don't be distracted by others?
This is not going to be
so radical for you guys.
But about 10 years ago, we went
to an open collaborative thing,
where we got rid
of faculty offices.
What was happening is that
the students were staying home
because the computers were just
as fast, the networks just as
fast at home as
they were at work.
And whether this is good
for a company or not,
I'll leave to you.
But it's terrible for
research because it's not just
put your head down
and plow ahead.
You've got to talk to people
because you're not sure what
you're supposed to be doing.
So we put it into
the open space.
And now that I've read about
it, what you're shooting for
is communication
and concentration.
So people can come in to work.
They have to be
able to concentrate
enough to get the work done.
But you want to have
spontaneous communication, which
leads to innovation.
So bump into each other
and have meeting rooms.
We've got the meeting rooms
optimized for discussions
and phone calls.
Jeff Walz brought us
probably 10 years ago.
And we saw what you guys did
with your conference rooms,
and we imitated that.
And like you guys, we have
kitchens and free drinks.
We can't do food,
but we can do drinks.
And the amazing thing,
it accelerates research.
Who would've thought space
could accelerate research?
It was startling what happened.
We went from faculty offices
that had kind of white boards
there that were filled
with faculty reminders.
And you came in.
You got to work on,
like, one square foot
to put your idea in there.
Instead, we had
giant whiteboards.
There was no writing.
You couldn't reserve it
in the high tech way.
You copied it with cell phones.
It became stimulating.
People came in more.
There were more
spontaneous meetings.
And then we noticed the zero
to 60 time for new people
went incredibly faster by
having that kind of environment.
So Matei Zaharia-- in
his second semester
there, he gave a talk
at Carnegie Mellon.
And we've never had
anybody do that before.
Now Matei Zaharia, who's
the founder of Spark,
did a lot of good things.
But it wasn't
obvious then that he
was going to be that
good, as it turned out.
And so maybe that had
something to do with it.
And so Richard
Hamming has opinions
on this, based on
his experience,
which I'm sure
you're not surprised.
OK.
He's got two opinions.
The first one is open
versus closed doors.
And the only way he
can have this opinion
was to keep track of
all of his colleagues,
which ones kept the doors
closed, which ones were open,
and which ones were successful.
And here's his idea.
[VIDEO PLAYBACK]
-The example I've
given you already
is working with the
door closed or open.
If you work with
your door closed,
you won't be interrupted.
You'll get your work done.
If you work with your
door open, people
come by and stop and
chat and so on and so on.
But I've noticed very
clearly at Bell Laboratories
those work with the door
shut may be working just as
hard 10 years later, but they
don't know what to work on.
They are not connected
with reality.
Those who had the door
open may very well
know what's important.
Now I cannot prove to you
whether the open door causes
the open mind or whether the
open mind causes the open door.
I suspect both.
I can only establish
the correlation.
And it was quite spectacular.
Almost always, the
guys with the door
closed were often very
well able, very gifted.
But they seemed to work always
on slightly the wrong problem.
So you have to get a wide
feeling for what is going on.
[END PLAYBACK]
DAVID PATTERSON: OK.
And then he believed
that so much,
that this is how his patterns--
how he handled Friday
afternoons, about
the importance,
especially for researchers--
you can start work really hard.
But you could miss the
really important thing
by not interacting.
[VIDEO PLAYBACK]
-At the urging of some other
people partly and partly
of my own, I used to set
aside Friday noon and Friday
afternoon for great
thoughts, meaning, yes, I'll
answer the telephone.
Yes, I'll sign a sheet of paper.
But mainly, what is the effect
of computing on science?
What the hell am I doing
with this computing machine?
How is it going to affect AT&T?
What should I be
doing in computing?
What is the nature of software?
My friends all after
a while got to know.
Friday afternoon
is great thoughts.
What's the nature of this,
that, and the other thing?
I spent 10% of my time trying
to answer the question,
what are the important
problems in my field?
10%, Friday afternoon,
straight through.
Don't do it Monday
morning, because you'll
be interrupted immediately.
If you do it Friday
afternoon, some of it's
going to linger over
onto Saturday and Sunday.
If you do it Monday
morning, there's
a hot conference at 10
o'clock, and bingo, everything
is broken up.
I used Friday afternoon
for many, many years.
I recommend that you find a
regular time to stop and think,
what are the important things?
What is going on?
What is the nature of
what you are doing?
What is the
characteristic of the job?
What are the
fundamentals behind it?
So you'll have some idea
of where you're headed,
so you can march in
a uniform direction
and get far rather than
being a drunken sailor
and getting nowhere.
[END PLAYBACK]
DAVID PATTERSON: And you're
free to ignore his advice,
but then your career is
that of a drunken sailor.
OK.
Finishing a project.
I'll talk about this.
People count the number
of projects you finish,
not the ones you start.
And successful
projects go through
this unglamorous hard phase
of trying to finish it.
And it's because design
is a lot more fun.
It's a lot more fun to design
things, to make stuff work.
But some positive things.
Fred Brooks, one
of my heroes, says,
there's no winners on a losing
team, no losers on a winning
team.
If you win, anybody involved, no
matter what they did, they win.
Improve productivity
of team members.
How can you do that?
Organize each day.
Figure out when you're most
alert, when you need a nap
or exercise or sleep.
When, how often should you
be reading and writing,
programming and email?
And what I found, for
successful colleagues,
they always used to do lists,
daily, weekly, and even
every six months to see how
they're doing on their career.
These days, there's this
idea of agile scrum,
where you meet in the same
place at the same time
and do sprints.
I think this is a
pretty effective model.
And then reduce the
project if it's late.
Again, Fred Brooks said,
adding people to a late project
makes it later in his classic
book, "The Mythical Man-Month."
And finishing a project
is how you acquire taste.
How do you get good taste?
If you don't finish it,
you don't know really
what went wrong.
And it helps you
pick good problems
and find simple solutions.
OK.
And then my friend
John Hennessy,
President of Stanford,
said this a long time ago.
You can quickly
tell whether or not
the authors have ever built
something and made it work.
And if you never make it work,
you don't acquire that taste.
Evaluating quantitatively,
never be proven wrong?
Nope.
If you can't be proven wrong,
then you can't be proven right.
And you have to-- we need
reproducible results.
You're trying to get
people to use your ideas.
If they can't reproduce
them, they're not
going to take your word for it.
And for better or for worse,
benchmarks shape our field
and especially in
the commercial world.
If we have good ones,
it accelerates progress.
Bad ones, then there's a
choice between helping sales
or helping customers.
And often, sales wins.
And then transferring
technology.
It's not just you
write the paper,
and everybody starts using it.
You have to go out and stump it.
This last year,
there's RISC-V, which
is an effort to be able to
have an open instruction
set, an open alternative,
kind of like Linux
is to Microsoft Windows.
So I gave talks
at 10 universities
this fall to try and
get the word out.
Then if they kind
of like the ideas,
then they read the papers.
Of course, if you don't
pick a good problem,
people aren't going
to be that interested.
And you can tell if it's a
good problem if more people get
interested over time rather
than yours start to do that.
I think I am persuasive.
The way I change minds is
with believable numbers.
And so you have to collect that
quantitatively and believe it.
The other thing I
learned late in my career
is your personality affects
technology transfer.
There's this person who
I won't name who had
a bunch of interesting ideas.
And people wouldn't use them.
And I talked to people
in the industry it.
They hated that guy.
They hated that guy.
If there was any other
way to do it at all,
they would use it
because that was
the last thing they would do.
So you can be a jerk if you
have the only possible solution.
But it's kind of hard
to do that in computing.
Maybe in biology,
you can do that.
And then product groups.
People don't want to change.
There's risk
associated with change.
It's worked for us.
And this goes back--
so Fred Brooks,
when he was a graduate student,
his advisor was Howard Aiken.
And Fred Brooks says,
I think these people
are going to steal your idea.
These companies are
looking at his idea
at Harvard University,
a drum memory system.
Watch out, Howard.
And what Aiken said
in a southern accent
is, "The problem
in this business
isn't to keep people
from stealing your ideas.
It's making them
steal your ideas."
And that's still true
today, 65 years later.
So what's worked for us is to
find one bold group, often not
the leaders, but some bold group
willing to take a shot on it.
And they are successful.
And then kind of the rest
of the field is-- for us,
it was Sun Microsystems for RISC
and EMC for RAID and Inktomi
and then Google for
Networks of Workstations.
But it's kind of like
the rest of the field--
oh, damn, they tried it.
It works.
OK, we'll change.
Right?
People don't really-- as
much as people enjoy ideas,
they don't want
to take the risk.
And then the other way of
transferring technology
is to start a company.
In my 40 years,
everybody I've talked
to who's worked for a
startup likes doing it once.
Absolutely.
Now, there's some people who
love doing it more than once.
A lot of people, once is enough.
But everybody thinks
it was useful.
They learn a lot.
And then if it works,
if it works out,
you see not just your
ideas but the product.
And of course, you can
potentially make a lot of money
if that works out
and become famous.
The downsides are that
you learn about things
you might not want to learn
about, particularly lawsuits.
My friends have had
a lot of lawsuits.
That's less fun.
And you don't get to do
research and development.
And then only 10% of the
startups make it, right?
But nevertheless, everybody
thinks it was worth it for once
in their life, maybe
when you're younger.
So I didn't really
realize that there
were six roles to being
a leader of a project,
and it changes over time.
But that's what I believe now.
So wrapping things up-- and
there's time for questions
here.
The goal is to have impact.
Does it change the way people
do computing and engineering
in a positive way?
Now, we do these
five year projects.
Now that my career is
ending, I will do 12, right?
They overlap.
So I've been there 40
years, not 60 years.
You can't tell if a project's
successful for at least
10 years.
And the good news
is three of them
look like they're
pretty successful.
They're 10 years old.
So that's kind of 25%
batting average, which I'm
glad I did a lot of projects.
There are two that are finished,
but it hasn't been 10 years.
The RAD Lab did Spark and Mesos.
Those seem promising.
The Par Lab did communication
avoiding algorithm [INAUDIBLE]
and this RISC-V stuff.
But it'll take
five or seven years
to know how significant it was.
So maybe I'll get up to 5
out of 12, which is like 40%.
But most of the
projects don't work,
so I'm glad I did
short projects.
So solve a problem other people
care about, a taste that you
acquire by finishing projects.
And then-- whoops.
So OK.
And I think the key theme
running over my career
is feedback, is figuring
out ways to get feedback.
OK.
With that, I'm
ready for questions.
[APPLAUSE]
I there's a microphone here.
AUDIENCE: Oh,
there's one here too.
DAVID PATTERSON: OK.
Questions.
Without the first
question, there
won't be multiple questions.
Oh, there it is.
AUDIENCE: Since you
asked for hard questions,
which of your projects
did you enjoy the most?
And which of them do you
think had the most impact?
DAVID PATTERSON: Which
did I enjoy the most?
Let me do the most impact.
Because I'm kind of
wrapping things up,
it's plausible RAID
had the biggest impact.
Everybody uses it.
The original RAID paper won
three Test of Time Awards.
It looks to me, if I try
to be a neutral observer,
probably RAID is the
most significant so far.
Which one did I enjoy the most?
I try and always make
projects that I really love.
I try to make projects that
if I was a graduate student,
I'd just die to work
on this project.
You know, gee, that's hard.
Maybe--
AUDIENCE: Which of your
children do you love the most?
DAVID PATTERSON: Yeah, which of
my children do I love the most?
I don't know.
The good thing about all the
projects, whether or not they
were home runs, is they
produced great students.
And I didn't say
that in the slide.
There were almost 300
students in those 12 projects.
I had fun adding that number up.
Jeff.
AUDIENCE: So this isn't really
a problem for most of us here.
But would you give
different advice
to a pre-tenure academic
versus a post-tenure academic?
Or do you think you can
do the kinds of things
you're talking about
and not compromise
your chances of getting tenure?
DAVID PATTERSON: Yeah,
so people ask me this.
So when Hennessy and I did the
RISC stuff, which at the time
was hugely controversial--
if you think
deep neural networks
are controversial--
a faculty member at
another institution
wrote a hit piece
on me personally.
Dave Patterson's a bad person.
We were talking about
instruction set design.
But at the time, Hennessy
and I are were saying,
Digital Equipment, one
of the leading computer
manufacturers in the world,
had a pretty stupid design.
So yeah, we didn't
worry about that.
Also, you have to believe
in what you're doing.
I just can't give the
advice to do something
that you don't believe in
and work on that, because--
in fact, when I've
visited universities,
and I've seen that-- this
assistant professor is telling
me, well, I don't really
like what I'm working on,
but this is what I have
to do to get tenure.
And then I go talk
to the chairman.
This guy's just doing
incremental stuff.
He's never going to get tenure.
There's that gap there.
When you're larval, you need
to make sure you publish.
You need to go around and give
talks and stuff like that.
But I think you got to do
projects you believe in.
Otherwise, life's too short
to work on other things.
Yeah.
Question here?
AUDIENCE: So you
mentioned a couple times
not to be a Prima Donna.
So it's easy to identify other
people being Prima Donnas.
But how do you tell if
you're being a Prima Donna?
DAVID PATTERSON:
Are you married?
My family's really good
at pointing out my flaws.
Well, I think feedback
is the one-- I go out
of my way to get feedback.
If somebody hates my papers,
I send them new papers
because they tell me
the honest thing to do.
I would like to think if
I'm acting like a jerk
that I'm pretty sure
my friends or my family
would tell me that.
I think you could ask.
I think you can ask, right?
Geez.
People are afraid to
tell you something.
But I think if you asked, did
I handle that well or not-- I
think some people in academia
think that's the way people
know that you're famous.
You've had some success.
You start acting differently.
It's just bad career advice.
OK Other questions?
AUDIENCE: So full disclosure.
I went to Berkeley
and experienced
one of these projects.
So I'm--
DAVID PATTERSON: Amin
was on the Network
of Workstations project.
AUDIENCE: I'm biased
toward the model.
My question is, given the
successful of the model,
why do you think more
universities haven't
adopted it?
I mean, even though it seems
like the stuff you're saying
is really obvious, it's
also somewhat rare.
DAVID PATTERSON: Yeah.
I got that exact same
question at Berkeley.
I think-- this time
I'll be less humble.
You have to have somebody
who's willing to lead.
For some reason, even the
wrestling-- as I'll tell you,
I wrestled in high school and
college as an individual sport.
I had great
wrestling coaches who
realized we'd be more successful
if we bonded as a team,
even though it was
an individual sport.
So I had that kind of
role model going up.
And so I think I'm good at
kind of organizing teams.
So you have to have somebody
who's willing to do that.
The institution itself,
Berkeley, told me, day one,
have impact.
They didn't have any problem
with multiple people working
on it.
When you're an
assistant professor,
you make up rules, like I have
to have only solo authored
papers.
Otherwise, I don't get credit.
But yeah, that's not true.
So the institution
let it happen.
I think it was helpful.
But I'm a good leader of people.
But there's lots of good
leaders of people around.
I don't understand why
that doesn't happen more.
It seems common sense.
It's not like I've kept
this a secret for 40 years.
I've been telling people
at lots of institutions.
So I'm not sure.
But we're a lunatic
fringe, right?
We put a group together.
It's a different group
with interdisciplinary mix
and match.
We tackle a problem.
We've already visited you
guys on the next project
to get some feedback on it.
I don't know why more
people don't do it.
You have to ask them.
Why don't more people--
you should ask them.
Why don't you guys
act like Berkeley?
I'm sure they'd love that.
There's probably a
nearby university.
FEMALE SPEAKER: Yeah, I
think we have about five
or six more minutes
for questions.
DAVID PATTERSON: All right.
With that, then I need to
quickly give my life story.
OK.
So I'm an accidental CS student.
I was a math major and wrestler
in high school and college.
At the end of my junior year,
the math class was cancelled.
I had to take a course.
There was no CS major.
So I just took intro to computer
science, and I was hooked.
That was it.
My senior year, I took every
computer course I could.
I'm an accidental student.
I went to UCLA,
graduate student.
I just casually
mentioned at the end
of one of those
courses to a new PhD
that, boy, I'd sure
rather do this than work
in a factory to pay my college.
And he on his own
went and found me
a job as undergraduate student.
While I was an
undergraduate student,
even though it was near
the end of my senior year,
that wasn't too late to
go to graduate school.
And I asked my wife
about a master's degree.
She said, sure.
It's only four of rive quarters.
And then when I got
into the office,
everybody else in my
office was getting a PhD.
So I thought, maybe
I should get a PhD.
So I decided to do that.
We lived on research assistant
salaries, my wife and two kids
and I. We were at poverty
level at that time.
And then the project ended,
and I lost my RA-ship.
My adviser helped get me a
job at an aerospace company.
He's aircraft.
And then it was touch and go
whether I'd ever finish my PhD
because I was working
20, 30, 40 hours.
But I did make it.
I'm an accidental
Berkeley professor.
My wife grew up right
next door to Berkeley.
And when I was graduating, on
the interview tour, she says,
I can't help but think you're
going to end up with Berkeley.
And I said, look,
Berkeley's up here.
UCLA's down here.
I'm graduating.
This is never going to happen.
But she forced me as
a graduate student
to call the chairman of the
department at Berkeley computer
science to find out
about my application.
So I called this guy.
He said, well, Dave,
you're in the top 10,
but not the top five.
And at the time, I'm
thinking, that wasn't so bad.
So it turns out he said
that to anybody who called.
But then he took my application.
Yeah, that seems interesting.
Handed it to somebody
visiting southern California.
We had a good conversation.
They invited me back to
interview and got a job offer.
I barely got tenure.
The first project, I
already told you about.
It was way too ambitious.
I did the sabbatical,
and I did the RISC stuff.
Tenure wasn't easy.
I was one of those
guys that was using
conferences, where the whole
campus used journals but us.
So I was the Guinea pig
that went through that.
The RISC stuff was
pretty new, but I got it.
After that, things got better.
But I still get papers
rejected by those jerks
on the programming committee.
And so what have I learned?
What works for me?
For me, it was maximizing
personal happiness
versus personal wealth.
That's always been my guideline.
In this country, you
think wealth is happiness.
There's unhappy
billionaires in this world.
They're not the same thing.
Family first, especially
in that kind of a job.
People ask you to do things.
Your family can
go down the list.
I made my family first.
So I did-- my wife
and I had two sons.
So I did Indian guides.
I was the Cub Scout leader.
I was the soccer coach on
their field trips out there.
So when my rebellious
teenage boy grew up,
ah, you were never there.
Then I said, Indian
guides, Cub Scouts.
So I went down the list.
He said, oh, OK, maybe.
Passion, courage, and optimism.
You might be able to tell
I'm a passionate guy.
I have to believe the
thing I'm doing is going
to possibly change the world.
My optimism story goes
back to high school.
I started dating this girl who
was dating older guys who had
Corvettes and stuff like that.
Nevertheless, after
a couple dates,
I asked her if she
would go steady with me,
as we would say at the time.
She'd just been
dating older guys
and didn't now
what to say to me.
She says, well, I don't
know how to say no.
So me being an optimist
and a logical person,
not a no is a yes.
So I said, great,
and I hugged her.
And she said, you know, I'll
let this guy down later.
But we've been
married 48 years now.
So I think that's OK.
And then, yeah, I think
we swing for the fences.
Right?
That's that thing.
Now another thing--
this is a saying
that a colleague told
me that's actually
a couple hundred years old.
Friends come and go,
but enemies accumulate.
So ironically, the
physical courage
that comes with wrestling has
to me been intellectual courage.
So when I was president of ACM,
the person in charge of DARPA
was cutting back on
academic funding.
So I decided to take
him on with my friend Ed
Lazowska in Washington.
We tried to get people from
other universities to join us.
But they were afraid this guy
would be vengeful and cut him
off, I think with good reason.
So it was just us taking him
on with editorials in "Science
Magazine" and stuff.
So this guy was not a fan of us.
But we hadn't quite realized--
this was unintentional.
But the other saying is, the
enemy of my enemy is my friend.
So we made a lot of friends.
But keep that in mind.
Winning as a team
versus an individual.
In my DNA, I believe a
team of average people
can work together
and beat superstars.
And then I've already quoted
Fred Brooks about that line.
Seek out honest feedback
and learn from it.
It's easy to avoid feedback.
But that's how you get better.
The one warning sign I can
pass on from my 40 years,
always dangerous
is when somebody
thinks they're the smartest
person in the room.
There's a person in
my field who thinks
he's the smartest
person in the room,
and everybody hates that guy.
There was a president
of a university who
thought he was the smartest.
That person was fired
for doing a lousy job.
The people who
founded Enron thought
they were the smartest
people in the room.
They went to prison.
And I even have a
relative who thought
he was the smartest
person in the room,
and he's a convicted felon.
So why would that be?
Why would this person--
they're probably smart.
And if they think
they're the smartest, why
would it be such a bad sign?
I think it's that they don't
want feedback from anybody.
If you're the smartest
person in the room,
you don't need to talk to
anybody about your idea.
So I think-- but
anyways, run away
if you find somebody like that.
This thing happened to me.
It was like God spoke
in my ear one morning.
And I remember waking up.
And it's not how many
projects you start.
It's how many you finish.
It was like in my
head, like somebody
was telling me what to do.
So ever since that,
that's what I've done.
So what I do is one
big project at a time.
I do other things.
But there's one big
thing at a time.
So when Hennessy and I
were doing our textbook,
that was the big thing
that I did that year.
When I was president of
ACM, I took a sabbatical.
So that was the one big
thing I did that year.
And so it turns out, if you
do one big thing a year,
over 30 years, you can
get a lot of things done.
But a lot of
academics particularly
will work on 1,000
things at once
and not finish
very many of them.
And then have fun.
To be successful, you
do have to work hard.
Our long lost colleague
Jim Gray-- even in his 60s,
he'd do one all nighter a month.
So you have to work
hard to be successful.
But you have to have fun.
As far as we know, you only
get one chance of this.
And if you get to the end
without having any fun,
you've wasted a lot
of opportunities.
I can put up with a
lot of stuff as long
as I play soccer every Sunday.
I can have a good time.
So that's my advice.
Thanks very much.
[APPLAUSE]
