►
From YouTube: Fireside Chat with Bret Taylor - GitHub Universe 2016
Description
Join host Alex Handy, Senior Editor at BZ Media, in a fireside chat with Bret Taylor. Bret is currently the CEO and cofounder of Quip, a productivity platform for teams which was acquired by Salesforce in August 2016. Prior to founding Quip, Bret served as the first CTO of Facebook and saw the company through its successful IPO in 2012. Credited with the invention of the original "Like" button, Bret joined Facebook in 2009 after it acquired his social networking company, FriendFeed, for $50 million. Bret's product acumen extends to his time at Google, where he co-created Google Maps, Google Local, Google Maps API and Google’s first developer conference, Google I/O.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
How's
everybody
doing
out
there
yeah
right.
So,
yes,
I
am
a
senior
editor
at
SD
time
software
development
times
I'm
a
big
enthusiast
for
computer
and
software
history,
so
I
thought
I'd
share
a
very
small
piece
of
computing
history
with
you,
since
this
is
one
of
the
only
rooms
that
would
appreciate
it
right
across
the
street
there
in
the
big
red
brick
warehouse
on
Third
Street
is
where
new
hack
city
was
founded,
and
you
may
not
know
what
that
is.
A
That
was
the
first
hacker
space
in
San
Francisco
in
about
1997,
founded
by
some
cult
of
the
dead
cow
members
and
some
hasty
pastry
members,
and
they
used
to
reverse
engineer
software
and
they
would
go
to
the
companies
and
say
hey.
We
found
a
bug.
Companies
like
son
would
say
get
out
of
here.
Don't
bring
me
that
that's
that's
horrible
I,
don't
want
these
bugs!
Well.
A
Son
doesn't
exist
anymore,
but
a
lot
of
the
companies
they
used
to
bring
stuff
to
now
have
bug
bounties
just
to
show
you
the
kind
of
180
that
can
happen
in
this
industry.
I
thought
that
was
a
little
interesting
piece
of
history.
Now
I
have
the
extraordinary
pleasure
of
introducing
Brett
Taylor.
You
will
be
familiar
with
his
work.
He
is
one
of
the
co-creators
of
Google
Maps.
After
that
he
went
on
to
found
FriendFeed,
which
was
acquired
by
Facebook
and
brought
in
the
like
button.
A
He
then
went
on
to
be
their
CTO,
and
now
he
is
the
CEO
and
co-founder
of
quip,
a
business
productivity
application
company
that
does
spreadsheets
documents
and
collaboration
tools.
Brett
is
also
a
gentleman
who
did
a
masters
and
bachelors
at
Stanford
in
five
years,
while
working
at
Google
in
2003.
So
that's
a
rather
impressive
feat,
I
think
so
without
further
ado,
let
me
bring
out
Brett.
B
First
computer
I
used
my
dad
was
a
mechanical
engineer,
so
we
usually
had
computers
in
the
house
growing
up
in
the
80s
and
the
first
that
I
remember
using
was
a
I
think
it
was
called.
The
compact
portable
I
was
about
the
size
of
a
suitcase
and
like
the
lid
of
it
flipped
out
into
a
keyboard
and
I.
The
main
memory
I
had
was
the
only
game
that
I
played
on
it
took
up
all
the
space
on
the
hard
drive,
so
every
time
I
would
play
it.
B
My
dad
would
delete
it
and
then
every
time
I
wanted
to
play
the
game
I
had
to
reinstall
it,
which
took
about
two
and
a
half
hours.
I,
just
remember
vividly
because
it's
been
two
and
a
half
hours
to
play
the
game
for
about
40
minutes.
Until
my
dad
needed
the
computer
again
and
then
he'd
delete
it
and
I
have
to
start
all
over
again.
B
B
B
Been
a
little
maybe
understand
a
little
bit
slower
than
I
expected.
We
actually
just
equipped
now
are
finally
converting
our
code
base
to
Python,
3
and
large
part
because
of
the
support
for
co-routines
and
async
and
a
weight.
But
to
date
there
just
hasn't
been
enough
sort
of
like
super
compelling
and
I
think
feature
reasons
for
people
to
switch
over
and
I'm
really
happy
that
things
like
co-routines
and
other
things
are
sort
of
making
their
way
into
to
the
modern
language.
B
B
Think
almost
every
early
project
I'd
stayed
up
late
at
night
working
on
just
because
I
think,
like
most
people
who
first
discovered
programming
and
you
kind
of
get
infatuated
with
the
project's
you're
working
on
I,
would
the
project
I
spent
the
most
late
nights
working
on
it
was
probably
Google,
Maps
I
think
I
most
most
of
2004
was
me
late
at
night.
Working
on
that
project
said
you.
B
A
Right
well,
let's
get
into
some
deeper
questions
when
you
were
working
on
Google
Maps,
you
were
basically
building
out
a
paradigm
for
modern
application,
design
that
at
the
time,
was
dubbed
Ajax.
Can
you
talk
about
a
lot
of
the
sort
of
the
changes
in
paradigms
that
the
the
process
shifts
the
development
practice
shifts
that
have
really
changed
that
Ajax
into
what
we
sort
of
have
now
yeah.
B
So,
just
to
contextualize,
for
those
of
you
who
maybe
this
was
sort
of
like
before
your
time
getting
into
technology
I'm
at
the
time
web
applications
where
it
wasn't
really
a
term
there's
websites
and
they're,
mostly
static
web
pages,
some
of
which
were
somewhat
dynamic.
But
at
the
time
in
Google
there
was
a
few
different
product
groups
that
were
really
interested
and
truly
making
interactive
applications
within
the
browser.
So
the
Gmail
team
I'm
a
product
called
Google
Suggest,
which
my
co-founder
helped
make,
which
was
sort
of
like
as
you're
typing
search
queries.
B
B
But
just
no
one
you
know
had
sort
of
like
had
the
insight
to
you
know
actually
leverage
JavaScript
objects
as
like
a
data
transport.
So
as
a
consequence,
we
ended
up
sort
of
like
writing
and
rewriting
in
the
Apple
like
three
or
four
times
as
we
discovered
ways
of
actually
making
it
work
within
the
web
browser.
And
there
are
points
where
we
would
just
crash
the
web
browser
over
and
over
again
and
we'd
have
to
go
up
to
the
team.
B
B
It's
really
neat
how
we've
sort
of
taken
the
set
of
really
immature
technologies
and
developed
things
that
feel
really
modular
and
scalable,
and
you
can
really
imagine
a
team
of
hundreds
of
engineers
actually
being
productive
and
making
these
applications
as
opposed
to
the
kind
of
like
cargo
cult.
You
know
style
of
discovering
how
to
implement
these
things
that
we
started
with
I
JA.
B
Think
it's
good
I
still
think
that
if
I
have
one
critique
of
the
sort
of
JavaScript
ecosystem,
it's
just
how
there's
a
lot
of
innovation,
but
it's
also
very
trend
driven.
So
you
know,
I
meet
various
startups
and
I
can
almost
identify
the
year
that
they
were
founded
by
like
what
JavaScript
framework
they
decided
to
use
and
and
it's
and
you
can
do
it
down
to
like
the
month
of
the
year.
You
know
just
because
they
they
change
so
rapidly
and
so
I
do.
B
I
am
as
much
as
I'm
really
excited
about
all
the
ideas
and
innovation,
I'm
kind
of
looking
forward
to
us
sort
of
settling
on
some
best
practices.
Just
so
that
you
know,
companies
don't
need
to
sort
of
like
write
and
rewrite
their
front-end
so
frequently,
which
is
definitely
something
I.
Think
a
lot
of
companies
are
encountering
now,
but
on
the
upside
I
think
things
like
you
know
real
modules,
things
like
react,
which
I
think
are
enabling
larger
teams
and
code
reuse
in
a
way
that
I
think
was
really
just
not
tractable
before
when.
A
B
So
we
mobile,
really
impacted
Facebook,
I,
think
more
than
a
lot
of
different
companies
just
because
the
product
was
so
popular.
So
we
there
were
many
parts
of
the
world
like
sub-saharan
Africa,
where
98
plus
percent
of
people
had
never
actually
used
Facebook
on
a
PC
before
so.
Essentially,
we
knew
very
early
on
that.
If
we
didn't
implement
a
feature
in
our
mobile
interface,
it
would
actually
literally
not
exist
to
most
of
the
people
who
used
Facebook.
B
So
it
was
a
really
stark
realization,
but
at
a
company
with
thousands
of
employees,
a
company
that
was
in
the
middle
of
going
public,
it's
a
really
awkward
transition,
because
you
have
a
group
of
very
talented
engineers
from
you
know
some
of
the
best
in
the
industry
and
you
essentially
have
to
retrain
an
entire
workforce
in
a
new
set
of
technologies.
So
we
had
a
lot
of
sort
of
false
starts.
There.
B
We've
made
a
lot
of
temps
to
do
a
lot
of
stuff
in
html5,
some
of
which
worked
well,
some
of
it
didn't
we
had
to
sort
of
like
build
up
a
bunch
of
Technology
around
in
iOS
and
Android
and
train
kind
of
our
entire
engineering
team
on
how
to
do
it
and
I
would
say,
was
a
really
awkward
transition
for
like
a
year
and
a
half,
but
on
the
upside
I
think
the
one
thing
that
we
did
really
well
that
I
really
believe
in
from
a
technology
approach.
Standpoint
is
when
we
identified
the
platform
shift.
B
We
just
like
powered
through
the
awkwardness
and
even
if
we
failed,
we
just
sort
of
garbage
collect
the
bad
idea
and
like
move
on
to
the
next
one
and
by
the
end
of
it,
I
think
you
know
Facebook.
That
team
is
one
of
the
best
mobile
engineering
teams,
I
think
in
the
industry
right
now
and
I
think
it
was
in
part,
because
we
didn't
sort
of
dwell
on
our
failures
and
just
move
forward.
Technologically.
A
B
I
think
Google
and
Facebook
are
really
really
different
cultures,
and
this
is
very
reductive
and
simplistic,
but
I
think
Google
was
shaped
in
large
part
by
its
academic
heritage,
so
Larry
and
Sergey
were
grad
students
at
Stanford
when
they
started
the
company
and
even
the
layout
of
the
offices.
When
I
was
there
looked
like
the
inside
of
the
gates,
Computer
Science
Building
at
Stanford.
B
You
know
the
office
layouts
were
the
same
same
number
of
people
per
office
where
the
common
areas
and
the
as
a
consequence
to
like
a
lot
of
the
engineering
processes,
were
sort
of
based
in
academia.
So
there
was
a
really
rich
sort
of
design
document
culture
and
everything
was
really
like.
Well-Designed
and
reviewed
ahead
of
coding
and
and
I
would
say.
Almost
formal
and
academic
Facebook
was
started
out
of
a
dorm
room
as
a
hobby
project,
and
you
saw
that
in
Facebook's
culture,
where
that
sort
of
move
fast
and
break
things,
culture
was
truly
genuine.
B
People
would
generally
check
in
code
and
ship
something
their
first
day
on
the
job,
I'm
and
I
realized
like
being
at
both
companies
that
both
produced
remarkably
successful
products
and
remarkably
successful
companies,
and
if
I
learned
one
thing
from
it,
is
there's
no
formula
for
how
to
build
a
really
good
engineering
team.
But
when
you
choose
your
engineering
processes,
you're
sort
of
choosing
the
culture
that
you
have
so
I
would
say.
B
Well
you
compete
and
I
think
in
general,
we
don't
put
it
enough
spot
it
into
that
in
our
industry
and
it's
and
I
also
just
think
it's
a
it's.
A
set
of
trade-offs,
as
opposed
to
a
right
way
in
a
wrong
way,
which
is
the
way
I,
think
it's
sort
of
incorrectly
portrayed
in
a
lot
of
like
the
blog
posts
and
articles
that
I
read,
I.
A
One
thing
that
I've
noticed
that
is
similar
between
Facebook
and
Google
is
the
amount
of
time
and
money
they
spend
on
getting
development
environments
up
and
running.
I
know:
Google
Facebook
has
an
a
tremendous
amount
of
infrastructure
just
to
be
able
to
have
it,
so
you
can
make
a
change
and
see
that
change.
Is
that
a
reason
for
engineering
success
also
that
that
focus
on
the
pipeline
yeah
absolutely.
B
I
mean
one
of
the
things
that
is
I
wouldn't
say
unique
to
Facebook
and
Google,
but
certainly
for
code
bases
of
their
size.
Is
that
they're
monolithic
repositories,
so
everyone
at
the
company
is
sort
of
checking
things
into
a
single
monolithic
repository
and
to
do
that
at
that
scale
requires
to
lean
that
I
think
is
really
robust.
You
know
everything
from
sort
of
unit
testing.
A
B
And
then
a
lot
of
the
rest
of
the
UI
is
implemented
differently
at
every
platform.
Just
so
it
feels
as
fast
and
as
native
as
possible
and
I
think.
The
thing
is
now
because
you
know
that
there's
so
much
diversity
and
mobile
being
I
think
just
sort
of
a
key
word
for
lots
of
different
devices,
form
factors
and
operating
systems.
How
you
choose
to
architecture
product
is
a
really
meaningful
decision
up
front
and
I.
Think
that's
something
that
I
really
don't
think
was
a
factor
earlier.
B
In
my
career,
like
when
I
started,
FriendFeed,
it
was
a
web
browser
was
it
that
was
the
only
platform
we
were
targeting
as
a
web
browser
on
a
desktop
and
I.
Think
now,
there's
a
lot
more
nuance
to
it
and
I
think
you're,
seeing
that
with
things
like
electron
and
other,
if
you
actually
want
your
product
to
work,
offline
feel
native,
it's
it's
a
lot
more
nuanced
than
just
sort
of
like
you
in
react
or
something
you
have
to
really
be
thoughtful
about
how
you
architecture,
products
now.
A
A
B
B
So
the
reason
for
I
just
have
my
one
dot
Emacs
file
I
just
carry
around
with
me
everywhere,
but
the
the
reason
I
do.
That
is
because
I
really
like
to
be
able
to
go
to
any
computer
and
be
productive
and
I
noticed
like
the
more
I
customized
my
environment,
the
more
I
like
spend
all
this
time,
setting
up
and
I
really
liked
having
that
agility.
So
now,
I've
just
gotten
to
the
point
where,
like
I,
don't
depend
on
customization
and
I,
find
that
I
like
I,
feel
more
like
I
can
liberate
it.
B
The
interesting
thing
is
the
thing
we
focus
on
is
the
metric
for
engineering
productivity
is
one
person
can
make
a
change
and
know
that
it
works
and
really
focus
on
that
testing
environment
and
really
focus
on
autonomy
and
removing
dependencies.
And
so
that's
really
the
focus
we've
been
and
and
what
we
found.
Actually
people
really
love
doing
the
full
stack
they
love
being
able
to
actually
like
see
the
the
result
of
their
work
and
not
depend
on
someone
else
to
make
those
changes
so
well-documented.
A
B
Don't
you
know
we
we
try
to
just
find
people
who
are
interested
in
in
that
sense
of
ownership,
but
not
necessarily
looking
for
any
particular
skill.
We
feel
like
people
can
learn
new
programming,
language,
new
technologies
and
that's
something
that
we've
all
grown
adept
at
as
engineers
I
mean,
especially
with
all
the
new
technologies
being
released
every
year.
So
we
don't
really
filter
for
that
at
all
and
and
then
usually
what
we'll
do
is
people
end
up
sort
of
specializing
we
usually
find
rarely
will
someone
do
both
iOS
and
Android?
B
It's
usually
like
one
person
will
so
we'll
sort
of
split
that
up
among
the
team,
but
I
think
it's
at
least
from
the
feedback
from
our
team.
People
find
it
really
rewarding
because
they
get
to
learn
new
technologies
and
they
get
to
sort
of
feel
like
this
is
my
future
like
I
built
this
and
I.
Think
that's
as
an
engineer,
myself,
I
think
that's
where
I
derive
a
lot
of
my
sort
of
satisfaction,
my
career,
and
we
want
to
sort
of
like
reproduce
that
sense
of
autonomy,
even
as
we
grow
as
a
company
all.
B
I
wish
I
had
created
I,
don't
I,
wouldn't
phrase
it
like
that,
but
I'll
say
like
the
products
that
to
me,
like
I'm
sort
of
in
this
space,
so
I
see
a
lot
that
I
really
respect
a
lot
of
slack.
We
always
joke
around
that.
Like
you
know,
we
sort
of
feel
like
our
mission
as
a
company,
which
is
very
similar.
B
Slacks
mission
is
just
moving
people
away
from
the
workflow
of
email
and
I,
really
like
feel
aligned
with
that
company
and
just
really
respect
the
product
and
the
brand
and
the
culture
that
they
developed
and,
and
we
work
a
lot
with
them
and
our
make
our
products
work
well
together
and
I
just
really
really
respect
that
product.
Excellent.