►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/building-a-thriving-developer-community/
I want to give a talk on the ins and outs of building a thriving web3 developer community. I help lead DevX at https://superfluid.finance and I've learned the hard way what it takes to get hundreds of projects built on your protocol.
I'll give an overview of what both engineers and marketing/growth people get wrong about building a developer ecosystem, how we run hackathons, and how we've productized our docs and developer tooling.
Speaker(s): Sam Flamini
Skill level: Beginner
Track: Developer Infrastructure
Keywords: Developer Experience,Developer Community
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
Let's
say
that
you're
building
a
really
cool
protocol
or
piece
of
technology
right,
you're,
you're,
targeting
developers,
you're
building
this
platform
right
and
you
just
sponsored
a
hackathon,
because
you've
heard
hackathons
are
a
great
way
to
engage
developers
right,
you've
paid
10K
in
travel
expenses
and
sponsorship.
Expenses,
you've
told
everyone
how
excited
you
are
for
hackers
to
build
things.
You've
never
even
seen
before
and
you've
told
your
team
to
be
ready,
because
this
weekend
is
going
to
be
intense
right.
A
It's
going
to
be
lots
of
questions,
lots
of
Developers,
then
you
show
up
and
nothing
happens
right.
The
hackathon
Flop
is
a
real
thing.
Right,
I've
seen
these
talk
to
people
in
the
community
that
have
had
this
happen
to
them.
Let's
say
you
get
three
submissions.
Two
of
them
are
figma
files
that
don't
really
actually
use
your
Tech
they're,
just
mock-ups
and
your
docs
get
ripped
to
shreds
by
the
people
that
you
do
engage
with,
and
they
tell
you
that
they're,
not
usable.
A
It
was
all
very
confusing,
and
it's
just
bottom
like
the
bottom
line.
Is
it
just
didn't,
go
very
well
right,
and
the
key
lesson
here
I
think
to
take
away
is
that
it's
not
enough
to
build
awesome
tools
right.
You
need
people
to
know
about
them
right
and
you
need
to
make
using
them
a
great
experience.
A
So
who
am
I
I
help
lead
developer
experience.
It's
super
fluid
superfood's,
a
protocol
that
enables
real-time
finance
and
money
streaming
right.
If
you're
curious
about
super
fluid
check
us
out
at
superflu.finance,
there's
lots
of
good
stuff
there
I'm
a
reformed,
SAS
salesperson,
so
I
used
to
sling
B2B
software
and
I
taught
myself
to
code.
I
got
really
into
the
technical
side
of
that
business.
I
fell
down
the
the
crypto
rabbit
hole,
and
here
I
am
so
at
superfluid
I.
A
A
We
have
teams
building
on
superfood
that
have
raised
eight
figures
in
grant
money,
slash
Venture
money,
and
you
know
it.
It
looks
like
your
community
is
doing
well
right.
Obviously
we
have
a
long
way
to
go.
You
know
in
our
eyes,
but
I've
learned
a
lot
in
the
devrel
trenches
right,
I've
been
to
a
lot
of
hackathons.
I've
talked
to
a
lot
of
engineers
in
the
space
and
I'm
still
learning
but
I
know
the
feeling
of
sponsoring
a
hackathon
and
just
not
getting
the
results.
You
wanted.
A
I
know
the
feeling
of
having
your
docs
torn
to
shreds
by
developers
who
get
frustrated
right
if
you're
in
the
audience
here
and
you've
done
a
hackathon
and
you've
just
started,
exploring
some
different
Technologies
in
the
space.
There's.
No
doubt
you've
probably
been
frustrated
by
documentation
at
some
point
in
your
journey.
Right
and
what's
nice
for
me,
is
that
superfluid
is
a
cool
protocol
right.
A
A
So
if,
if
we
zoom
out
a
little
bit
right,
I
think
it's
worth
asking
why
we
even
build
developer
communities
in
the
first
place
like.
Why
are
these
things
useful
to
us
and
the
key?
The
key
thing
here
is
that
if
your
Tech
matters
to
people,
you
win
right,
that's
like
the
simple
way
of
putting
it
right
so,
but
what
does
actual
success?
Look
like
like
what
what
does
succeeding
with
the
developer?
A
Community
really
mean
like:
what's
the
output
right
and
I
I
like
to
Define
it
as
really
two
things
right
that
will
actually
move
the
needle
for
you
economically,
and
the
first
thing
is
an
ecosystem
of
new
and
successful
applications
built
on
top
of
your
Tech,
and
the
second
thing
is
Integrations
between
your
technology
or
your
protocol
and
existing
Solutions
and
applications
today,
right.
So
a
good
web
2
example
is
twilio
they've,
enabled
new
applications
like
uber
and
Lyft,
and
Airbnb
and
they've
also
integrated
with
a
lot
of
existing
applications.
A
Obviously
right
everything
that
uses
SMS
push
notifications,
those
kinds
of
things
it's
probably
using
twilio
or
something
like
twilio
in
the
on
the
back
end
and
the
obvious
web3
example
is
ethereum
right,
so
unit
swap
maker
ens.
All
the
existence
of
those
apps
makes
the
ethereum
ecosystem
more
valuable
right.
It
makes
ether
more
valuable,
actually
and
the
on
the
other.
On
the
other
hand,
the
integration
bit
for
ethereum
is
is
to
help
if
I
mean
I.
A
So
if
those
are
our
outputs
right,
if,
if
that's
what
we
want,
when
we
create
a
developer
ecosystem-
and
that's
that's
what
we're
looking
to
do
the
discipline
that
creates
this
is
developer
relations
right,
so
you'll
see
a
lot
of
devrel
people
run
around
like
myself,
we
tweet
a
lot.
We
make
lots
of
videos
and
it
really
has
become
a
kind
of
very
important
discipline
in
web3
right
and
what
I
like
to
do
is
break
devrel
out
into
the
dev
and
the
real
side
right.
A
So
on
the
developer
side,
this
is
your
libraries,
your
apis,
your
docs,
your
tooling,
even
your
smart
contracts.
If
your
protocol,
it
looks
a
lot
like
engineering
and
a
key
thing
that
I
think
most
teams
get
wrong
is
that
they
don't
realize
you
need
to
product,
manage
your
developer
products
like
you,
PM
any
other
product
right.
A
The
other
half
of
devrel
is
the
relation
side.
This
is
a
very
loud
thing.
You
guys
all
probably
see
right.
This
is
your
tutorials,
your
videos,
your
meetups,
your
podcasts,
all
this
stuff
right.
It
looks
a
lot
like
marketing,
but
it
cannot
feel
like
marketing
right
and
we'll
get
into
why
that
is
in
a
second.
But
you
know
for
those
of
you
that
are
technical.
It's
probably
obvious.
A
The
key
thing
to
keep
in
mind
as
a
devrel
person
or
as
someone
who's
building
out
a
devrel
function,
is
that
great
developer
experience
teams
have
both
right.
You
need
like
I,
said
a
couple
slides
ago.
You
need
to
have
great
tools
that
are
really
easy
to
use
and
you
need
people
to
know
about
them.
Both
are
important.
A
So
how
about
the
dev
and
devrel
right?
How
do
we
at
superfood
approach
this
well
I
think
the
biggest
thing
that
I've
learned
is
you
have
to
PM
these
products
right?
You
have
to
treat
them
like
any
other
product
and
run
the
same
kind
of
process
right
that
most
valuable
product
for
a
developer
relations
team.
Is
your
docs
right
that
that's
number
one
number
two.
In
order
to
make
good
docs
and
other
good
developer
tooling,
you
have
to
understand
your
developer
personas.
A
You
have
to
really
get
into
the
minds
of
the
people
that
are
going
to
come
to
your
site
and
be
using
your
stuff
and
make
things
for
them,
and
the
third
thing
that's
a
little
more
in
the
Weeds
on
how
to
build
individual
good,
Dev
tools
and
sdks
is
to
be
mindful
of
your
abstractions
right
so
on
on
the
side
of
docs
right
there's.
This
quote
that
Elon
has
on
Tesla
autopilot
that
they
they
view
it
Tesla.
A
All
input
as
user
error
right
so
a
loose
analogy
for
your
docs
is
to
view
all
developer
questions
and
every
piece
for
confusion
as
a
failure
of
your
Docs
right.
Obviously,
you're
still
going
to
get
questions,
no
matter
how
good
your
docs
are
and
I
hope.
That's
evident.
If
no
one's
asking
questions,
that's
probably
a
bad
sign,
but
it's
a
useful
mindset
right
and
the
reason
why
it's
a
useful
mindset
is
that
it
points
you
in
the
direction
of
higher
leverage
activities.
A
So
when
I
first
started
at
superfluid
doing
devrel
stuff
I
would
spend
a
lot
of
time.
Answering
questions.
I
was
like
building
my
self-esteem
around
how
good
I
was
at
this
job
by
like
how
fast
I
was
at
answering
questions
and
how
many
questions
I
answered
and
all
this
stuff
right,
and
that
that
really
wasn't
the
right
mindset
to
take
right,
because
all
the
question
answering,
although
it's
useful
right,
if
you
ask
a
question
someone's
Discord
and
they
don't
answer
you
you're
going
to
feel
like
you
know
they
don't
care
about
you
right.
A
So
we
still
do
value
answering
questions
doing
it
quickly,
but
the
higher
leverage
thing
is
to
find
patterns
and
spend
time
in
your
docs,
making
sure
that
people,
ideally
don't
even
have
to
ask
you
right
and
if
and
if
they
do
ask-
and
you
do
have
to
give
an
answer.
Ideally,
you
should
send
them
a
link
to
the
answer
and
more
information
right,
I've
seen
so
Patrick
Collins,
you
guys.
A
Might
you
guys
might
know
who
Patrick
Collins
is
he's
a
great
developer
experience
person
in
the
chain
link
ecosystem
that
I've
I've
learned
a
lot
from
him.
What
he
actually
does
is
if
someone
asks
a
question
to
him
in
their
Discord,
he
will
like
answer
the
question.
He
will
create
the
question
on
stack,
Overflow
answer
the
question
on
stack
Overflow
and
then
send
a
link
to
stack
Overflow
in
a
Discord
and
the
reason
why
that's
so
smart
is
that
every
question
you
answer
in
Discord
just
stays
there
right,
Discord
like
it's.
A
It's
really
hard
to
like
go
research
like
go
search
in
the
Discord
search
bar
and
find
useful
answers
to
questions.
It
really
is
difficult
to
do
so.
What
Patrick
is
doing
is
he
is
adding
more
leverage
to
his
activities.
Right,
he's
answering
a
question,
but
creating
a
paper
trail
back
to
stack
Overflow.
So,
ideally
he
doesn't
have
to
be
there
and
answer
those
questions
every
time
right,
docs
work
for
you,
while
you,
while
you
sleep,
answering
questions
like
you,
can't
do
that
in
your
sleep.
A
Unless
you're
you
have
some
kind
of
powers
that
I
don't
know
about
so,
okay
with
that
being
said,
how
do
you
maximize
the
utility
of
all
your
docs
and
developer
tooling
right?
How
do
you?
How
do
you
think
about
this?
Well,
you,
you
need
to
start
by
identifying
developer
personas
right,
so
a
case
study
on
this
would
be
with
super
fluid
and
I'll
walk
you
through
what
we've
done
right.
A
You
also
have
developers
at
integration
Partners
like
people
that
might
go
Champion
to
their
boss,
that
they,
you
know
their
company-
should
do
superfood
in
the
next
product,
and
you
also
have
like,
especially
if
you're,
a
developer
ecosystem
that
wants
full-blown
applications
and
companies
to
be
built.
On
top
of
your
stack,
you
might
have
future
Founders
or
entrepreneurs
looking
at
your
stuff
and
you
need
to
cater
to
them
as
well,
because
those
would
be
some
of
the
most
high
value
people
you
can
interact
with.
A
So
in
our
case
for
the
beginner,
slash,
hackathon,
devs,
right,
I'll,
Loop
them
together,
because
there's
a
little
bit
of
overlap
here,
but
for
our
docs
we
have
a
nice
quick
start
page
where
it's
like
go
here,
get
what
you
need
get
out.
It's
quick
for
tooling.
We
have
a
simple
JavaScript
SDK
to
interact
with
our
smart
contracts.
We
also
have
very
simple
solidity:
libraries
I
want
to
build
smart
contracts
with
super
fluid
and
then
our
tutorials
and
examples.
A
We
have
a
Zero
to
Hero
series
and
we
have
very
easy,
like
dead,
simple
beginner
examples
on
the
front
end
in
react.
Okay,
so
that's
that's!
Like
the
beginner
segment
for
intermediate
devs,
we
have
our
reference
docs
right.
You
know
if
you're
an
intermediate
Dev,
you
know
what
you're
doing
you're
you're
happy
to
just
go
literally
like
look
into
the
reference
docs
and
find
the
functions
you
need.
A
We
also
have
advanced
guides
for
some
of
the
more
advanced
features
of
superfood
and
the
more
powerful
things
you
can
do
all
sorted
by
topic,
and
we
also
have
in
the
tooling
section
that
JavaScript
SDK
also
has
typings
so
that
you
can
use
the
SDK
with
first
class
typescript
support
right.
On
top
of
that,
we
have
a
developer
console,
which
is
helpful
for
like
getting
data
from
the
subgraph
and
in
terms
of
tutorials
and
examples.
We
have
more
fully
fledged
example.
Applications
that
can
take
you
end
to
end
building
a
a
more
full
product
right.
A
You
can
see
test
Suites
all
the
stuff.
You
need
to
actually
build
some
kind
of
integration
between
superfluid
and
what
you're
working
on
and
then
for
entrepreneurial
devs.
We
have
a
library
of
ideas,
we'd
love,
to
see
built
right.
We
try
to
seed
the
community
with
ideas,
so
the
entrepreneurial
types
can
find
something
to
actually
try
to
build.
A
We
have
this
super
fluid
reactor
program,
which
is
like
a
mini
accelerator
that
we
run
to
help
people
go
from
idea
stage
or
like
good
proof
of
concept,
to
actually
raising
money
or
getting
a
grant
and
then,
in
terms
of
tutorials
and
examples,
we
have
a
lot
of
Primitives
right,
which
you
can
think
of
them
as
like
building
blocks.
They
can
use
within
applications
build
on
top
of
them
and
then
ideally,
ship
and
end
user
product
or
or
thing
that
can
actually
become
a
business
right.
A
Some
other
considerations
right
when
it
comes
to
developer,
tooling
right.
One
one
thing
I
like
to
think
about
is
being
mindful
of
how
many
abstractions
you're
putting
into
your
sdks
and
tooling
right.
If
you
have
too
little
abstractions,
you
know
you
might
be
asking
developers
to
come
to
your
your
code
base
your
docs
and
figure
too
many
things
out
right.
You
might
lose
beginners.
A
However,
if
you
try
to
to
Shield
a
developer
from
the
the
tricky
stuff
too
much,
you
lose
the
more
advanced
Engineers
that
would
be
comfortable
dealing
with
the
bare
metal
and
you
even
stifle
innovation
in
the
process
as
well,
because
you're
not
going
to
allow
access
to
things
that
some
really
intelligent,
developer
can
make
use
of
and
then
finally
something
we
actually
haven't
done,
a
pretty
good
job
of
it.
Super
fluid
is
that
naming
really
matters
right.
A
Protocol
Engineers
sometimes
like
to
throw
really
crazy
names
in
their
contracts
that
don't
make
a
whole
lot
of
sense.
So
you
should
think
about
this.
You
should
think
about
this,
for
your
team,
all
right,
so
moving
on
to
some
of
the
more
relations
side
of
things
right.
This
is
one
thing
leading
into
this.
I
think
is
important
to
keep
in
mind
and
it's
that
most
Developers
are
not
good
at
explaining
their
product
to
newcomers.
So
why
is
that
I?
Think?
A
You
have
to
be
able
to
go
back
to
First
principles
and
explain
things
from
the
ground
up
right
and
people
that
become
really
good,
devrel
people,
people
that
actually
become
founders
of
of
protocols
and
things
they
have
to
get
really
good
at
this
right,
because
you
might
have
to
explain
the
same
thing
over
and
over
again
and
honestly.
I
actually
respect
it
like
Engineers
are
often
working
on
pretty
cutting-edge
stuff.
You
don't
always
want
to
go
back
to
zero.
A
You
want
to
you,
want
to
push
the
boundaries
and
build
something
new,
but
it's
worth
keeping
this
in
mind
right
and
when
it
comes
to
the
relations
side
of
what
you
do
and
all
your
tutorials
and
all
your
examples
and
all
your
content.
You
have
to
keep
that
in
mind.
Right,
don't
assume
too
much
context
from
new
people
coming
to
your
your
stuff,
moving
further
into
the
devrel
stuff.
One
thing
that
you
have
to
keep
in
mind
that
many
of
you
probably
already
know
is
that
you
can't
Market
to
developers
right.
A
You
need
to
Peak
curiosity
instead
right,
so
we're
going
to
go
through
what
I've
seen
doesn't
really
work
when
it
comes
to
marketing
developers.
What
I've
seen
does
work
and
then
you
know
we
might
talk
a
little
bit
more
about
being
mindful
of
extreme
context,
but
I
wanted
to
lead
with
that,
because
I
think
it
was
so
important
to
hit
you
guys
with
that
up
front.
A
So
what
doesn't
work
when
marketing
to
Developers?
Well,
anything
that
feels
like
a
traditional
demo
or
sales
piece
of
marketing
collateral
does
not
work
right.
Engineers
can
see
it
from
a
mile
away.
It
will
immediately
turn
them
off
and
even
if
you're,
giving
them
something
really
useful,
they're
not
going
to
pay
attention
right
and
this
kind
of
is
looped
in
with
anything.
That's
feeling
right.
So
there's
the
the
Supreme
Court
Justice
quote
about
you
know,
there's
like
a
case
on
on
pornography,
and
somebody
asked
the
judge
like
well.
A
A
The
other
thing
that
I
think
is
actually
underappreciated
is
that
you
can
really
lose
credibility
with
people
if
you
try
to
mangle
every
use
case
into
using
your
your
technology
right.
So
if
some
engineer
comes
up
to
me
to
hackathon
and
says,
hey
Sam,
you
know
I've
got
this
thing.
You
know
it
does.
Xyz
should
I
should
I
use
super
fluid
to
integrate
with
that
right
and
if
they
tell
me
that
XYZ
is
something
that
really
makes
no
sense
to
integrate
super
fluid
with
and
I
try
to
sell
them
on.
A
Why
super
fluid
is
a
good
thing
to
connect
to
their
to
their
their
project
if
they
don't
recognize
it
right
away,
they're
gonna
figure
it
out
when
they,
when
they
start
going
through
a
docs
in
our
code
base,
and
we
you
just
lose
credibility
with
people
right.
So
one
of
the
most
persuasive
things
you
can
do
in
my
opinion
is
actually
to
be
really
upfront
about
when
your
technology
doesn't
make
sense
for
you
right.
A
Interestingly,
people
will
come
back
to
you
and
find
some
reason
to
use
your
technology
in
a
more
interesting
way,
if
you're
honest
with
them
right
you
just
you
cannot
be
dishonest,
especially
to
Engineers
Engineers.
Here
you
have
some
of
the
greatest
BS
filters
in
the
world
right.
You
should
be
proud
of
that.
But
Deborah
people
need
to
keep
that
in
mind.
It's
very,
very
important.
A
So
how
about
what
does
work?
Well,
I
I
mean
I,
think
that
focusing
on
education
is
really
the
right
move
right
and
not
just
education
around
what
you
do,
but
general
education
right,
even
if
it's
just
adjacent
to
what
you're
doing
right.
So
one
example
is
this
new
chain:
Dev
YouTube
channel
that
the
chain
link
Community
put
out
and
another
is
a
podcast.
We
we
launched
a
superfluid
called
devs,
do
something
so
chained
Dev.
A
They
just
do
very
general
stuff,
like
Patrick
Collins
does
it
he
does
very
general
just
web3
tutorials,
and
that
builds
a
lot
of
credibility
with
with
the
chain
link
ecosystem,
and
you
know
I
think
people
know
who
Patrick
is
and
they
want
to.
They
want
to
go
build
on
chain
link
because
they
know
he's
helped
them
a
lot
and
he
literally
is
always
wearing
the
Chain
Link
T-Shirt
right.
That's
that's
a
good
thing
and
then,
on
our
end,
with
super
fluid,
we
launched
this
podcast
called
devs.
A
Do
something
that
is
designed
to
just
be
purely
helpful
for
engineers
in
the
space
we've
had
on
just
a
lot
of
really
good
technical
minds
and
we
we
don't
really
talk
about
streaming,
money
or
superfood
stuff
that
much
at
all
right.
All
we
do
is
we
just
talk
through
like
what
they,
what
they're
working
on
we
go
through
their
favorite
design
patterns
and
examples,
and
it's
worked
right.
People
like
it.
So
that
those
kinds
of
things
will
you
know
your
community
will
accrue
value
as
a
result
of
these
kinds
of
things?
A
You
do
another
thing
that
works
when
it
comes
to
being
more
specific
to
your
your
stack
and
your
protocol
is
creating
really
interesting
examples
and
proof
of
Concepts
right.
So
this
might
be
obvious,
but
one
one
thing
to
keep
in
mind
is
you
know,
we're
all
playing
a
long
game
here.
I
hope
hopefully
right,
but
the
problem
is
that
there
are
so
many
things
that
become
hot
and
capture
the
attention
of
every
engineer
in
the
space
and
they
always
want
to
work
on
them
now
right.
A
They
don't
have
to
be
perfect
Solutions
and
you
don't
and
remember,
like
I
said
a
second
ago,
you
don't
want
to
force
anything,
but
if
there's
a
genuine
integration
you
should
you
should
build
some
proof
of
concept
around
that
right.
It
helps
you
stay
in
the
conversation
like
I
said,
and
another
thing
I
really
want
to
highlight
is
that
you
want
to
create
superstars
in
your
community
right.
You
want
to
make
people
feel
really
really
special
right.
So
this
means
promoting
the
projects
that
your
community
builds.
A
It
means
hosting
little
like
sessions
and
meetups
where
they
can
come
in
and
share
what
they're
working
on
to
your
broader
Community.
You
really
want
to
highlight
people
right.
It
gives
you
content
right,
because
you
have
something
to
say,
and
it
also
makes
people
feel
good
right,
because
it's
just
it's
just
a
nice
human
thing
to
Spotlight
someone
and
tell
them
they
did
a
good
job
right,
especially
if
it's,
if
it's
true,
obviously
so,
that's
the
dev
and
the
real
side.
A
Another
thing
that
I
think
is
interesting
to
talk
through
is
how
to
spend
money
in
a
in
an
intelligent
way
on
developer
acquisition
right.
So
all
the
hackathons,
you
guys
see
those
are
not
cheap
for
sponsors
right.
Those
are
very
expensive,
so
I
think
it's
worth
keeping
in
mind
how
to
actually
do
this
right.
So
again,
our
industry
spends
so
much
money
on
developer
acquisition.
A
It
matters
to
us
it's
spent
mostly
on
hackathons
bounties
and
devrel
team
members,
I'm
not
going
to
go
into
how
to
hire
deveral
team
members,
but
in
terms
of
getting
money
getting
getting
Roi
out
of
the
money
you
spend
at
hackathons
and
bounties.
You
have
to
keep
in
mind,
you
cannot
just
throw
money
at
your
community
and
hope
for
a
good
outcome
right.
There
have
been
times
I've
been
at
events
where
someone
from
a
protocol
says
hey.
A
If
you
build
anything
on
this
on
this
on
this,
this
L1
or
this
protocol
will
give
you
a
10K
Grant
right.
They
just
start
throwing
money
out
like
crazy,
because
there
has
been
a
lot
of
money
in
the
space
to
date.
Right,
unfortunately,
that
just
doesn't
really
work
right.
It
can
get
you
some
growth
immediately,
but
the
way
I
like
to
to
put
it
is
that
you
really
get
out
what
you
put
in
from
an
effort
and
and
how
thoughtful
you
are
point
of
view
right.
A
So
when
it
comes
to
hackathons
I'll
head
on
hackathons,
first,
the
selection
of
the
hackathon
you're
going
to
do
really
matters
right.
So
you
want
to
look
for
really.
You
want
to
look
for
events
that
have
really
high
quality
co-sponsors,
and
you
want
to
look
for
organizations
to
put
out
lots
of
good
content
and
seem
like
they're
on
top
of
their
stuff
right.
You
should
ask
yourself
before
you
show
up
at
a
hackathon
before
you
pay
money
to
be
at
the
hackathon.
A
What
kind
of
community
is
this
event
going
to
attract,
and
is
that
Community
one
that
you
want?
Building
on
your
on
your
on
top
of
your
protocol
right
or
your
technology
in
general?
Two
really
good
examples
that
are
kind
of
the
gold
standard
are
youth,
Global
and
devfolio.
I
love,
youth
Global.
If
you're
a
need,
Global
person
in
here.
Thank
you
for
doing
good
work
at
good
hackathons.
That's
right!
So
look
for!
Look
for
teams
like
that
right!
A
It
helps
and
then
at
the
hackathon
one
thing
that's
counterintuitive
is
you
should
prepare
a
couple
of
ideas,
at
least
before
the
hackathon
starts,
because
you
know
we
also
like
to
sit
here
and
say:
hey
we're
just
so
excited
for
the
applications,
no
one's
even
thought
of
yet
right,
and
it's
true
that
you
will
be
surprised
and
people
will
build
cool
things
on
your
Tech
stack.
But
people
have
two
days
here.
They
have
a
lot
of
things
coming
at
them.
Give
them
something
to
work
with
give
them
some
idea
to
start
with.
A
It's
really
helpful
and
ideally
those
ideas
integrate
well
with
other
sponsors,
devs
and
hackathons,
like
the
stock
price
on
top
of
each
other.
They
look
for
ways
to
integrate
multiple
things
and
it's
worth
keeping
that
in
mind
and
then
obviously
you
want
to
be
friendly,
being
friendly,
really
matters,
obviously
at
hackathon.
So
that's
that's
how
to
think
about
hackathons.
The
other
thing
that
we
do
at
Super
fluid
is,
we
think
about
bounties
a
little
bit
differently
right.
A
So
I
think
that
when
it
comes
to
developer
experience
and
building
developer
communities,
using
bounties
like
individual
bounties
to
to
get
people
to
complete
tasks
is
a
little
bit
overrated.
You
can
crowdsource
some
good
content
and
things,
but
what
we,
what
we
kind
of
like
to
use
bounties
for,
is
to
get
Giga
brains
and
really
smart
people.
Looking
at
your
code
base,
that's
what
you
want
right.
You
want
to
have
them
looking
at
your
technology
and
ideally
they
go
out
and
they
build
something
brand
new
as
a
result
of
seeing
this
right.
A
A
Right
I
want
to
go
through
a
couple
of
devro
failure:
modes
right
that
I've
experienced
in
mistakes
that
I've
made
mistakes
that
I
see
in
the
space
just
to
just
to
give
you
something
to
walk
away
with,
and
then
I'll
kind
of
recap-
and
you
know
remind
us
all
of
what
the
goal
is
here.
So
some
several
common
failure
modes
number
one
trying
to
throw
money
at
the
problem
right.
We
talked
about
that
number.
Two,
not
seeding
your
community
with
enough
interesting
ideas
and
examples
to
work
with
right.
You
can't
have
people!
A
You
can't
expect
people
to
read
your
mind
right.
Giving
them
something
to
work
on
is
sometimes
very
useful.
Another
three
is
adding
or
assuming
too
much
content
in
your
docs
and
tutorials
right
meet
developers
where
they
are
understand.
Those
personas
and
you'll
be
much
more
successful.
Four
is
doing
way
too
much
low
leverage
work
right.
So
that's
me
in
the
beginning,
only
answer
is
not
really
working
on
our
Docs,
but
on
the
flip
side
go
too
far
there.
A
I
think
you
know,
we
sometimes
forget
that
we
just
get
in
this
cycle
of
just
throwing
money
at
hackathons
and
just
you
know
going
to
all
these
conferences
and
things,
and
we
forget
that
success
looks
like
a
thriving
community
of
developers
who
tell
all
their
friends
their
bosses
and
other
people.
They
know
about
your
product
that
help
developers
other
developers
in
your
community
right.
They
give
back
to
you
that
build
their
Integrations
at
their
existing
company
or
protocol
between
your
stack
and
that
ultimately
launch
businesses
that
are
built
using
the
technology.
A
You
build
right.
That's
all
the
things
that
really
matter.
So,
if
you're
interested
in
all
this
stuff,
I
love
talking
shop
on
devrel
things.
Thank
you
all
for
for
coming
today,
get
in
touch
with
me
on
Twitter,
at
esplanet5
I'm.
Also
in
Discord,
it's
Sam,
f
superfluid,
with
this
little
0902
thing,
so
yeah
come
say:
hi
I'll
be
outside
to
answer
questions.
If
you
guys
have
any
questions
or
would
you
like
to
talk
or
meet
up
and
thank
you
so
much
for
for
joining
us
today.
A
Oh,
what
one
one
more
thing:
I
have
my
my
friend
Yao
in
the
audience.
We're
gonna
have
we're.
Gonna,
have
a
Deborah
meet
up
tonight
from
six
right,
yeah,
six
to
nine
thirty
from
6
30
to
9.
all
right.
So,
if
you're
interested
in
this
stuff,
we
have
some
cool
devrel
professionals
and
developer
Community
experts
coming
stop
by
say,
hi
and
we'll
have
a
good
time.
So
thank
you
again.