The discussion centers on the pragmatic approach to software development, particularly debating the necessity and effectiveness of unit tests versus alternative strategies like robust tooling, code reviews, and focusing on user needs, with a strong emphasis on developer productivity and shipping value quickly.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
oh yeah my last point there is i i trust
the history of what my developers did
more than the history of what they think
they did and merge is what happened
rebase is what they think happened and
what they want to pretend happened if
you're exclusively working with
developers whose imagination is better
than their commits rebase away but i
want to make sure that our history is true
true
is the true history so i think this is
where this is this bleeds right into the
next topic which is i don't believe my
imagination plays a single role because
i am an aggressive unit tester
and i have all my code unit tested and
perfectly working so when i make a
refactor i'm confident in this moment
that i have not changed
anything or the behavior without having
to go through integration now we may be
using the term integration or end-to-end
tests uh slightly different right people
tend to use these phrases in all sorts
of ways i don't think i've ever heard
someone use the term functional test in
the correct way
ever it's i i don't think anyone has any
idea what that actually means uh but
all right so this this might be part of
the problem which is you
don't think
unit tests
should be done in fact i believe you
said something along the lines of
someone being a delusional if they do
unit tests probably not that intense but
it was pretty intense
i thought i was vehemently anti-unit
test oh you kept going i believe you
even tossed some shade my way at one point
point
you probably even said like my hair
wasn't as good as yours or something
like that
the tick tock came out great though
thank you for that it's one of the best
ones i've done so far don't don't
compliment this take talk this is not
the time for tick tock it's it's your
tick tock to be fair i just stole your content
content
oh that's great i didn't put my message
in there oh really just you but yeah it
was wonderful oh that's awesome
oh yeah i got like that that was
fantastic i'm always fine i'm always
fine being a vic a collateral victim of
tick-tock damage i'll i'll accept it in
fact you know i was the only victim
there you call me an ignorant [ __ ] i'm
not saying it's inaccurate i'm just
saying that i'm the victim i know you
were you were the victim in the moment
okay but uh you know what i deserved one
that was the nicest thing someone has
posted about me in a while right usually
when people take something it is in a
negative fashion i felt like
at least there was some love there maybe
some some anger yeah i mostly love you
there's my community has a lot of love
for you i was surprised because i've
definitely seen you catch some heat but
i think we're on like the same
wavelength and a lot of ways there where
it's like we're not we're not here to
make people happy we're here to talk
about how [ __ ] gets done yeah and
it gets spicy if it has to yeah all
right all right
just for the unit tests though i
i i want again i'm gonna preface this
with something oh wait can i do can i do
one quick thing sorry i'm sorry that i
just interrupted you right there i'm
gonna do a quick poll in chat that says
who likes unit tests or uh do you
think unit tests
are good
yes and no so answer truthfully because
afterwards i would like to see the outcome
outcome
to this if anybody was swayed obviously
this is a bias test in the sense that
new people are going to join towards the
end they'll vote on it like oh yeah of
course they're great right and so we
won't get accurate results but it'll be
interesting to see
if uh you know if you've changed
people's minds if things have if things
have changed
so go on
start start your unit test
test these so the
the [Music]
[Music]
issue i i have a handful that you need
to test but i want to give like one
important addendum at the beginning here
which is a lot of my stance here
is trying to be
the opposite extreme from what i
consider the problem which is the
everything should be unit test people
i think that no unit tests is
significantly better than 100 code
coverage in the sense that
where i am the
wrong extreme you might believe i am at
prevents my engineers from being
hampered by [ __ ] and i am always
looking for [ __ ] to trim i want my
engineers working on things and i want
the teams i'm in working on things that
make them more productive effective and
confident as they solve problems for our
users and where
most of the code i see shipping goes
unit tests are slowing them down more
than helping and they're often reached
for due to other problems my concern is
there are tests being written to
create contracts and expectations where
the codes architecture itself should be
enforcing them okay so i think we do
fall on the same page that i think we
both would universally agree that 100
coverage is just terrible right it's
easy to have a bug and have 100 coverage
just do a list and access a list and
have the second thing be undefined right
you can just bam you know hit it
undefined right very very easy and
number two i have up
okay so i want to go off on this one for
a little bit because i totally agree
like the undefined in a list problem is
so real and we hit it in production and
it turns out and this is really fun
learning there's actually a typescript
rule for accessing an index and not
checking if it's defined or not because
when you're grabbing from an array you
can't know yeah and we turn that on we
found like three other places that that
bug could have happened in the code base
as a result and once again my stance of
good tools are better than okay tests
was proven out because we could have
written 100 unit tests and not caught
that but we turned on one typescript
rule and caught three okay so i do i do
think that good tools
help prevent a class of bugs or
something along those lines so i i'm
gonna agree with you on that one but
okay tests i mean it sounds like you
have poor test writers so we'll just
we'll ignore that for a second uh the
second thing is that i think we both
agree i try to find the common ground
before we get on the argument here is
that we both agree that tdd defining the
test first and then building your
architecture around the test is the
devil's tool and should be thrown away
immediately i personally will never
define my architecture based on how i'm
going to write my tests i usually do it
a little bit you know the other way around
around
uh are you you must not be on the td d
d
yeah no i can't
can't
i i'm a big udd fan user driven
development we do things because our
users need them and tests are not the
best way to define those things like the
problems we're solving exist much more
in user land than they do in like
like
if i was a back-end developer building
long-running systems and i needed to
make sure things were staying super
stable and never leaking probably a
little cooler with test driven
development and unit tests but
building product for users tdd
tdd
pulls you far enough away from the user
that you lose track of what you're
building pretty regularly and that's
been the experience with every tdd team
building user first software that i've
ever worked in okay
uh so i mean i i think you might be
drawing like a some sort of like false
dichotomy here that somehow udd is
opposed well tdd let's just put that in
the trash okay nobody likes tdd we all
agree that tdd sucks but tests
incorporated along with writing code
somehow takes you away from the user
so good example i'll throw out an
example here uh one of my jobs was we
had an ipad in which we were one of the
first people to kind of do like a google
docs like presentation where you could
view you know a document on several
different platforms including one that's
written in the old uh action script way
back in the day and also in html5 when
html5 was hot and or html4 maybe it was
at that point i can't even remember what
it was at but either way we did this and
if you touched the ipad and drug your
finger dragged drugged drug edited your
finger across it you would highlight
some text and that text would be in the
exact same pixel position as it would be
in action script on say a computer or
using the app versus on the ipad you
could make comments and all that now
touching the screen obviously involves a
couple points coming in which then takes
this huge block of text and now we have
to find exactly the point translation to
text position now i could have just
whipped out that feature in a day but
instead i took two three days and made a
very comprehensive set of tests and that
feature still actually is running
untouched and used by a lot of people
and no one's had to touch or change that
code and it's been a decade simply
because it is well thought through and
well tested so everyone knows the exact
ins and outs of the whole nine yards so
is udd so it's actually never been
changed or when it or was it never
changed or easy to fix when things broke
because those are different both easy to
fix because there was a couple bugs
because i had a very comprehensive set
of tests so they knew where the bug was
and how to fix that right and second uh
in a sense having a set of kind of tests
especially when it comes to complicated
data structures and how you use them uh
you have to uh
uh
need a way to kind of like describe that
to the developer i'm not convinced
writing a description of how to search
through a document is the best versus an
example that actually is a test right to
me that is a much better developer
experience in my personal book to
actually see the thing get used exactly
how to pinpoint it and understand it and
so i both lean on tests as a way to
prove correctness and as a way for
someone to get effectively tech
documentation for free
yeah i use typescript for the latter and
i use
documents plus explain the latter loom
to do quick recordings uh typescript
definitions give you 90
plus of what you need when you're
consuming something like you can hover
over you see what it takes and then it
tells you what it returns as long as
they're named okay and i would say like
the big thing we lean on hardest is code
reviews and like pushing for us to be
like raising the bar constantly i
obviously cannot say that that scales
forever but if you build a culture
around it it keeps you from running into
a lot of the problems that like unit
tests solve in those ways i i don't like
unit tests as a demonstration of how
code works and should be used because
more often than not unit tests are
breaking those assumptions with the
weird ways they mock [ __ ] and that's the
problem with unit tests is to test an
individual unit you're definitely
mocking something and you're probably
mocking it poorly because every mock
i've ever seen was bad every single
phone okay so that might be how your you
might be running into people writing it
poorly so i do have a rule when writing
tests which is anything that interacts
with the environment is usually behind
an interface so there is no mocking for
me i actually provide an object in which
abstracts it out right so it's just
simple calls in and out whereas i don't
actually have to worry about a lot of
the mocking type at least any sort of
like uh dependency injection style ones
which i find to be where all the
confusion happens when you have these
weird just import mocks and you're
taking all the imports and you're
rewriting the imports and then you're
hoping it goes all the way through i
find that to be where a lot of the
confusion is versus like hey when i'm
gonna do some sort of like say i'm
setting the audio render rate on a
television i'm gonna have this as part
of the config and that way i can provide
the render rate to my player and not
actually have it query some sort of
outside item and so kind of inverting
the control if you will i think they
have a name for that specifically yeah
yeah
the amount of thought that has to go
into these things and developing these
patterns and onboarding people to use
them properly and maintaining them and
then realizing they're bad and gutting
them and figuring out which tests
actually bring value and not and it
becomes a whole
additional thing to maintain that is
relatively big i actually keep a list i
don't think i have it here uh so i guess
the invert of this would be integration
right i mean integration tests
themselves are extremely complicated to
set up they break all the time data is
unreliable you have to do this whole
data mocking layer which is always out
of date it's like never end date i've
never seen someone data mock successful
ever we've done it a lot of times at
netflix it is just one of the worst
things services are going down you have
to have an entire staging environment
then the staging environment has to be
scaled because if your tests all run at
once or a bunch of developers come in at
once you have horizontal scaling issues
you're doing you're solving production
in not production at all points so i'm
not convinced that the other way is even
remotely easier
in any sense and creating tests that
often especially with webrtc you're in
webrtc world like how do you do uh
sequence out of order in rtp you know
how do you do uh forward air correction
uh read solomon how do you take care of
all these really complicated things if
you were to own it without something
that more defines or controls the
network and puts it in in a very
systematic way
i wouldn't i would outsource with
somebody who does and i'm almost
positive everybody will ever outsource
our webrtc info to or if we start hiring
enough people doing that ourselves they
will probably be much more pro unit
tests than me and they will probably
ignore my stance here and go and do
those things i think that unit tests are
reached to way too often for software
that the majority of is not things that
have sequence out of or order errors
they have the items in my cart aren't
going into the order errors the vast
majority of the web is e-commerce and
mostly static sites the vast majority of
servers are just hosting wordpress and
postgres the vast majority of the things
that we do
are slowed down by unit tests and that's
why i take the extreme stance i do i
think you need a good reason to have
unit tests rather than a good reason to
not and i think you're describing things
that are good reasons to have unit tests
i think that your job and your role that
makes sense a lot of the time i think
the majority of people even in your chat
here are probably writing too many unit
tests at their job
so how do you know so so we'll go we'll
go with your theory here how do you know
when you've written too many unit tests
if you say none we're fist fighting i
i really don't think this is it
because because i almost feel like it's
harder yours than mine mine is just
simply i'm gonna think of a few edge
conditions that i know will exist say i
have a bunch of items that could be
added in various orders and put into a
cart i expect if i handed this list it
just produces me the list in the same
order right that's a pretty happy case
very simple if someone decides i want to
add a new filtering mechanism it's going
to break and they go oh crap we broke
the default user experience either i
have to change the test
or make mine right as some sort of
option right it's like a catch because
they don't know
the history
so how would you how would you know when
that's too much
that already sounds like too much to me
like you have a list you use the list
the list is the same i don't i wouldn't
test that i i trust react to do i this
is the thing i see the most of that i
saw a ton of a twitch basically testing
if you pass a component props it gets
the props well yeah the act works
what yeah no no i agree that that is not
a very good problem but i'm just saying
like specific you know because there's
always filtering and all that like say
you want to do something smart some sort
of logic on top of it to make this list
into something else at some point how do
you know somebody's not breaking that
because it may not show up in user
metrics right it doesn't always just
because you make something doesn't mean
people quit using the product they'll
find a way around it you'll often see
this where people just do the just
dumbest things you're like why are you
doing that they're like well actually
it's quit working and then this is how
we solve it
you're like oh yeah you just worked
around it i think this is where like for
us user obsession is super important we
are constantly hopping into users rooms
seeing how they use the product see
what's going right and wrong and we've
already had times where feedback didn't
get to us here that we had to like find
ourselves by digging in really hard and i
i i have we've had one bug so far total
since we started shipping in august that
a unit test reasonably could have caught
and the amount of inertia we would have
had to just
eat to
start integrating
tests into our workflows like our time
to like our timed response for a
production issue that a user reports to
us is under seven minutes for a
production fix from when it's reported
and i'm aiming to get that lower right
now i want us on top of our [ __ ] and
unit tests don't help there my general
philosophy is build safety nets not
guard rails and test unit tests are the
most guard raily of like it feels like
bumpers being put on like bowling alleys
except half the time you hit them
they're just blocking you from doing the
thing you intend to do and you have to
remove the bumper yourself and now you
don't trust bumpers at all anymore and
the experience especially for newer devs sucks
sucks
i want to build the best safety nets
possible so when things do go wrong we
can revert the thing that caused it to
go wrong quick and we can address the
problem as fast as possible and if we
cause another problem in doing that we
can address that as well obviously as
systems get bigger this gets harder but
i have seen time and time again
especially at companies like twitch that
you can do this if you put your time and
energy into the right places you can
build in a way that is focused on fixing
problems when they come up rather than
guiding people to solutions and
solving problems with guardrails that
you don't know about yet i don't trust
my developers to guess the edge cases
better than i trust my users to run into them
them
okay so then i i do
so how do you test right so how do you
have confidence that when someone makes
a change it doesn't blow up so you know
obviously there's the integration
there's literal manual qa
what is your what and if you do
integration what's your integration
story look like
we don't we open up the pr build and hop
in a call if it's something that touches
any of the scary parts the vast majority
of the code we're shipping nowadays is
css changes and feature flags being
turned like on and off and moved from
place to place we
we
like here's a fun example of a
production issue we had we added this
one just happened uh yesterday actually
i'm sure you might have noticed in ping
right now i'm flashing and yesterday
when we talked i wasn't we had added a
network test in the preview before you
joined the call that instantiated the
webrtc client and then killed it and
instantiated a new one when you joined
the call
that broke the signaling process that
passes us the volume indication levels
there is literally no way in hell we
could have tested that because it was an
external sdk with a memory error inside
of it that
when killed and reinstantiated breaks
this one pipe inside of it and those are
the things that we tend to run into in production
production
those are the bugs we have
and being able to get bisect find the
last time it worked
quickly comment out that hook and have
everything working in production
it's pretty good
so then i guess the follow-up question was
was
you don't you don't do any integration
testing would have an integration test
simply caught this
like a puppeteer a puppeteer would not
have been able to start two streams and
no a puppeteer would not at least not
trivially be able to spin up an audio
and video device and then send down
arbitrary audio and detect that the
levels are being picked up on the other
side that would be
i would have lost two of my engineers
for three months trying to do that but
we fixed every five minutes instead and
that's just not a worthwhile trade and i
would be hard to convince that there's a
scale where that makes sense other than
you are selling these services to other
companies i
don't believe the amount of effort it
would take to
properly mock and rebuild those things
would be worthwhile almost ever when we
could build our own sdk for our webrtc
stuff instead when we run into problems
like that where it feels like a test
would bring value
fixing the thing that makes us so
uncomfortable we want to test is better
every single time but how do you know
you even got it right besides for just
manual testing it sounds like you're
annual testing so you instead of so if
you had to fix one place a hundred times
you would have to manually test that one
place 100 times
yeah and i probably tested our call
logic over 100 times at this point would
that not slow you down in the greater end
end
i mean i guess that some parts are just
you can't you can't lock out right like
i do understand that some things are
just they're just too hard and webrtc i
can kind of buy that obviously there's g stream
stream
right well how do you know you get it
right when you rewrite it like how do
you know any part of the things you do
that you haven't introduced small bugs
that aren't causing customer friction
which ultimately like personally
uh every time i've entered used a
product that has a series of small bugs
over and over again i find that more
frustrating than a place that has one
big bug every now and then
right like small things drive me way
more nuts when i just use it on my crap
this thing's broken oh okay today this
thing's broken like how do you prevent
that as your team grows to say 20 50 100 engineers
engineers
by overhauling the places that are like
fertile ground for those small problems
i don't believe those small problems
occur because the tests aren't good
enough i believe those small problems
occur because the structure and the
place that they are occurring in
is fragile or not like clear enough to
work in can unit tests be a tool that
guides people down the right paths in
those like
[ __ ] up grounds sure i would rather
every single time
dig it up and rebuild it because it takes
takes
about the same if not less effort a lot
of the time it's a better experience for
the developers it's a huge way
especially as like a leader when i'm
running teams for somebody to say hey
this thing broke should we add a bunch
of tests to say no
all right we can or if you think this is
fragile enough that we need something more
more
right out of spec we can overhaul this
so i think it's time in fact my cto is
doing that right now for our call logic
because it is too fragile and nigh
impossible to test so we're building a
new state machine with x-state it's
going to be way more complex we're going
to have like charts diagrams and all
that [ __ ] and probably maybe introduce
some tests for it but that's a very very
specific thing that is business critical
that we think we've ironed down enough
to start testing but if we had started
testing before getting here it would
have slowed down the process in which we
got here in the first place and i guess
my take is letting the developers and i
guess down the line some of the users
feel a bit of pain to build more trust
with your team is huge
and doing that for the team and giving
them the trust to own and
replace fragile things is almost always
worth it
okay so so somebody i see somebody in
chat say or uh asking like how big of
like teams and companies i've been on
like yeah my current company i have a
six person team okay i was right on that
one okay
yeah but i helped a lot at twitch on
like the team that ran the core website
which had over like 400 plus
contributors i've run and helped lead
teams with like 50 plus engineers and
that's where a lot of my philosophy came
from it's how do we get to that point as
fast as possible without stepping on too
many toes and breaking too much [ __ ] and
i i've seen teams scale from two to two
hundred many times now
i think i know how to do this right and
the way to do it right is to do it wrong
but fast for long enough to get there in
the first place so i definitely don't
disagree with that that i am i am fully
in the camp that you always should build
something once to throw it away
right like it just it just simply almost
universally works better that the first
one you build you throw away and i can
even buy the fact that you say hey i'm
gonna unit test uh this first one
because i'm just building it to really
understand the problem because you know
the people that go on the whiteboard and
spend a week purely whiteboarding a
problem and all the right boxes and
arrows and all those things i have never
actually had that work out in in real
life because real life does not look
like boxes and arrows it's just completely
completely
and it's always wrong and so
i have just never had it work correct
and so i'm i'm a huge proponent of the
build it twice kind of thing and so it
kind of sounds like you're you're you
almost are mimicking it in a different
kind of fashion that okay we're going to
rebuild it but i do worry that you're
almost no true scot spending this one
meaning that every time something is
problematic you're like well it wasn't
quite where it should have been right
like won't that always be all code at
all time it's always never quite should
always be leveling it up
i feel like tests discourage you from
taking level up opportunities yeah they
are patch jobs where you should be
overhauling why do they prevent you
because if you're going to rewrite it
you could either a you're rewriting the
interfaces or b you're writing the
insights right so if you're rewriting
the intersect
interfaces it's like everything's gone
anyways and so then the test would be
there and be like oh
why did this happen oh look this thing
actually gets called twice for this
really weird reason or this happens
twice for some really weird reason i
should remember that the next time right
you do lose
some oddity knowledge without it in the
unit test so whenever i rewrite and burn
down the whole city i look at the unit
tests as like an example of all the
things i need to remember but if i'm
rewriting just simply the insides the
unit tests just make me go okay i still
have everything correct i have not
changed it fundamentally i've only
changed how it works on the inside
you know what i'll take a light l on
this one this is something that i have
not been good about in the parts of the
codebase that you could argue need unit
tests i should have done a better job of
documenting the weird behaviors there so
that my when my poor cto
goes halfway through rewriting it it's
clear and he has to ask me less
questions but generally i i have relied
on communication as the solution there
where i'm the one who built this v0 this like
like
broken first version and i trust my team and
and
our engineering culture to get us there
and to get us over those gaps and i'm
focused way more on that part than i am
any technical path there yeah
i i do i i will also be glad to take the
light l of that i do think favoring your
first time through is a very good thing
rather than being so focused on tests
make sure you have the right behavior
the right things i do think that that
does make it a bit easier to move a bit faster
faster
but i think where we come into
contention is once i think i know what i want
want
i tend to do the refactor there in place
and then throw on the test to make sure
that i never forget the things that i
shall never forget such as my comments
on node uh nodes github and so it's just
like i always put those things around
for me to just i i forget and the funny
thing is what you're describing is
netflix in a nutshell or old netflix
shall i say old netflix was exactly this um
um
you actually probably would have loved
working on netflix five six seven eight
years ago it was a pure it's a tribal
knowledge is what you're describing
right where people all know the areas
really it's just really up to each
individual to make sure that that area
is good and we had virtually no unit
test no anything and it did scale for
actually quite some time we made it for about
about
uh from zero customers to about a
hundred million customers but there just
came a point where all of a sudden all
these decisions start gaining enough
momentum that it no longer worked and so
when we burnt down the ship we replaced
it with a bunch of unit tests and we've
actually you know life has been a
significantly different now there are
some really shitty interfaces right or
really shitty unit tests where they you know
know
does this thing construct you're like
yes new always has been new for like all
of eternity if that does not work then
your language is broken like the thing
itself is broken and it will never work
don't do that
and so i i mean i i get i get where
you're going with it i just am not
convinced it works
uh forever it works small and fast
it does not work
when you start getting out of small and fast
fast
yeah it it works until it doesn't and i
guess my hot take is you'll know when it
doesn't and people are pretending they
need these things way before they do i
think you need to get to that 100
millionth user before
hiring a primogen to go build this new
structure that's test first check
everything always
like there is a future like if i do
everything right at ping
in five years all of my stances here are
going to be wrong and i have to hire you
to fix the mistakes i've made like that
that is my ideal situation here is i by
doing things this way and breaking [ __ ]
and moving as fast as possible i can
survive long enough to get to that 100
millionth customer and then have enough
money and revenue to pay you to go fix
that but i don't think almost anybody in
chat here is at that point and to go
back to your earlier thing of like
building the first version then the
second i think what you're describing
here is the first and second version of
the company's structure for building to
an extent and people over optimize
to make the first one last forever
rather than make the first one last at
all and be as productive as possible so
you can get to that second step and to
go even further back to when you use
this to describe like building the first
version of the second version of tech
i think a lot of people are still in
that first version and don't realize it
and they're foot gunning themselves
because they're shipping the v0 somebody
hacked together
and unit tests are part of the nails
holding that down if it wasn't tested
and was quick it's a lot easier to rip
up than if it was tested it was quick
not because you have to read like delete
the interface as a rewrite or it's any
different in that way but yeah the
the role of unit tests
does give an amount of inertia an amount
of like weight that can hold down bad
code and mislead people into
maintaining bad code that probably
should have been deleted i almost like
why consciously
isn't that just bad engineers at that
point why would you let a unit test hold
because you're a new dev and i don't
think new devs are bad devs i think new
devs need to [Music]
[Music]
be able to make mistakes and also make
changes quickly and that's a process
that involves like mentorship and
communication much more so than unit
tests unit tests are another scary thing
that i don't think bring value very
often i think that type
to go another like whole step back i
think the era of typescript has changed
where unit tests are necessary and bring
value types and type systems can define
a lot of the things i used to use unit
tests for like given this function this
thing does it return this thing and i
would use unit test almost as a way to
enable refactoring ability i guess that
gave that to me in a much better fashion
yeah yeah no no the web's lack of types
have always been a historic tragedy
right i mean i think anyone that's used
non-type for a while to a type it is
definitely a tragedy just realizing how
much pain you went through before you're
like oh look types are really great yeah
i know they were really great i know at
one point computers just needed types
because they didn't have the memory or
the speed to have an interpreter but
then that left and then you're like oh
yeah it's perfectly fine but i do want
to i do want to touch on something with
netflix people i stopped i get roasted
in the chat about like oh now we have
100 million users now we test well you
got to remember that netflix hired only
the most senior engineers at that point
and so we had arguably you know one of
the bad most badass teams ever put together
together
uh doing television and we made it far
enough to the point where netflix didn't
ship a feature for over a year and a
half because of all the decisions we
made right like that it was really bad
like they're i mean heads rolled things
were not good like it was a but it took
enough inertia until we got to that
point because the problem is what you're
saying is like oh just rip it out
there eventually comes a time rip out
problem right which is you can only rip
out so much code and some code infects
others at a very fast and vicious rate
like rxjs someone puts in one observable
the next thing you know half your code
base is emitting observables and you're
like how the hell do i refactor this
thing out right like it's impossible you
can no longer pull it out without like
such a good use case for rxjs at ping
right now for like tracking the state of
the call against the webrtc client and i
am so scared to even consider it because
it will infect our code base and ruin
everything around us and i just i will i
will make an async state into a
synchronous state machine by brute
[ __ ] force if it's what i have to do
to keep observables in like bad fashion
away i think solid.js is a cool
contender for like doing observable
right in user interface libraries rxjs
exists because the primitive doesn't
exist in the browser and that's not a
good primitive to diy
yeah i don't i don't think well even if
it did exist in the browser i don't know
if it's a good idea still right like i'm
still not buying it that just because
something exists does it doesn't make it
a good idea plenty of people went back
and go ah this thing sucked why did we
do that right channels fantastic well i
think channels are a much better version
of what people are trying to get out of
rxjs and so uh but either way
going back to this um
and so i've seen this at netflix right
i've seen it a lot of times for all
sudden your your resources for change
become constrained under the weight of
feature velocity and at some point
bad ideas spread in fact for whatever
reason they feel like they spread faster
than good ideas i don't know how that
works i don't know why that works and
maybe god when he cursed the ground he
also cursed code i don't exactly know
how it happened but it just never quite
works the way you want it to and so i
find that like
like
bad things just keep on happening and
then also it's just like this myriad of
bugs that are just super hard to track
down and it doesn't show itself right
away but every year you find yourself
having a few more production bugs okay
this year we're up 50 this year we're up
50 this year we're up 50 all sudden
you're like wow we're 5x from where we
were even though if you 50 a bunch of
times you will not get 5x wait somebody
just coughed elixir wet slugs please
elaborate no you don't need the you do
not need the
their name is probably ryan as the only
person who uses elixir i don't even
believe in it it's a fake language i
shipped elixir for a year at twitch it
was great it doesn't even have types
it does
simply it has two plus signs for concatenate
concatenate
language is crazy okay
oh trust it
it's fun i i had so much fun with elixir
i would never recommend anybody ship it
at this point but man it was so fun and
we got a lot done with it okay i want to
actually hear more production because i
used a lowercase p
you broke production because you used a
lowercase p go go please go on that go
go on because i have power rangers is
spelled with an uppercase p for the
class that was defined for it or it
wasn't class it was uh for whatever our
bucket was for it and the
type definitions because they don't
exist didn't catch that in a pattern
match and uh yeah everything broke live
there's some other very fun production
errors there though that was the closest
one thing to one that like a unit test
could have caught my favorite though was
that in the power rangers episodes that
we got to air almost all of them had the
audio on channels one and two we were
pretty confident all of them did like
left is one right is two even though
there was nine channels
one episode like episode five i think
had channels one and two were just sound
effects so we aired a whole episode of
power rangers with just the sound
effects oh that sounds beautiful
just the whole time that's it
that's actually it was phenomenal we
heard the whole thing too we didn't cut
it didn't have a way to yet we just
built the code base like three days
before so like it we let the whole
episode air there's like a fight in like
a popcorn bag because they got like
shrunk to like mini versions and they
had like a fight if god it was so the
funniest thing ever the clips are still
around twitch randomly so i'd say that
we both agree on this point that elixir
is not a good choice so i am happy about
that um so i'm gonna throw something out
there and it's gonna be super
contentious for you you know your little
state problem that you're having
so you know i i hope that you are
prepared for this but i do believe that
often when you have super problematic
problematic async state containers one
of the best and most wholesome way to
solve them would be a delicious class
put it in a nice stay container have all
the callbacks contained and then it just
only emits the things it needs to emit
so you create like an observable light
if you will on a very small thin layer
now i know you hate classes to the point
where you even yes linted them
out of your product which
you know i mean i'm not gonna say we're
gonna fist fight but we're probably
gonna fist fight over this but either
way so
would this be a place you would consider
if the async was the only problem yes
but we have a few more interesting
issues here primarily around like
boundaries between different state
machines that have different different
sources of truth so we have your audio
and video device which are synchronous
by which you pick and then asynchronous
by if the tracks exist with an
additional set of state on top for audio
levels like resolution selected stuff
like that battle has to communicate with
an additional state machine from the
server of what's permitted in this room
what are you allowed to do which of
these settings can be selected or not
selected so there's like a second state
machine that is
interacting with that one we can
probably merge those two together but
it's going to be rough because we have
to persist some things locally and
persist some things server side then
there's the third part which is the
actual webrtc connection layer and that
is uh
a lot and making all three of these
parts interact tends to be the most
painful point of this
could we throw all of this together into
one class maybe but then the parts that
we need to consume in isolation are no
longer consumable in isolation like
right now you're an embed inside of my
stream i don't want anything to do with
devices or audio or av management or
even like the server expectations around
those things here so i need to be able
to take that part and reuse it and
classes encourage you to throw
everything in one place and now you
can't break those parts out anymore and
that's why we really go deep on the
functional aspect we try to make
reusable parts because we get random
requests and crazy ideas from our users
all the time we want to be able to
explore it and classes make that harder
okay okay i think you're using classes
wrong but i do i do i do understand this
i'm i'm a very strict class user in the
sense that i will never go beyond one deep
deep
uh i think inheritance was a mistake but
i do know one case where i think
inheritance was the right call which of
course is event emitters right when you
just want something that says like i
will now emit events for you and you can
call a function
uh i think that that was the right
abstraction though i can't figure out a
way around it to not be a class that
inherits i don't know what else to do
with that one it's a little painful for
me on that but uh i made a custom hook
it's really nice
hooks don't no let's not let's not get
started in garbage factories okay i have
i i emotionally hurt on the inside every
single time v8 goes into garbage collection
collection
i just i feel like i go on a
non-technical defense rant on hooks
quick yeah sure sure for those that
don't know we're talking now about i
believe hook started in react 16 if i'm
if i'm not mistaken 17. oh yeah 16.62
nine ten i think eight eight or nine
definitely nine okay cool six nine is in
there for sure yeah it was
early 2018 they were announced if i
recall i remember like i used to hitting
the twitch code base super hard so yes
it did hit a lot of code bases super hard
hard
it was great i was one of the big
advocates at twitch i got us entirely
moved over to hooks pretty much in like
a year i got us updated all the core
packages like our graphql and stuff like
that so you consume hooks and i also
ship modview as the first feature at
twitch that didn't use any classes and
it's the entirety of its like
development it was a fully functional
feature branch using hooks exclusively
for state it was great but yeah the as for
for
the important part of hooks outside of
the tech i could totally agree that some
of the ergonomics and some of the like
things they do can lead developers down
bad pipes absolutely we'll take the l
there but the the beauty of what hooks
enabled was
a third-party community of developers to
build awesome things into react it was
like use effect for example
is the hook that exists inside of every
other framework that they don't expose
because they wrap that with 15 different
things that you might want to use
instead so like how do i put it
yeah like like
like
on mount for example is a thing that
almost every framework exposes when this
thing mounts you have a function you can run
run
in react you build that yourself with
use effect now because if you have a use
effect with an empty dependency array
that runs on mount but what if the
function you pass that changes now
there's a lit rule that tells you hey
this thing needs to be here and it
encourages good behaviors
in some ways
but it does that by giving you a very
very raw primitive it's almost the first
instance of go-to in state management
which is why it's so scary and why it's
able to be used in such bad ways but the
power it introduces is community development
development
of things that hook in there
i think react enabled this before with
components the idea of like the material
ui component library coming out and
giving you this thing you install and it
has a button built in a drop down built
in all these things hooks gave that to
us for state and life cycles where you
can install react query which manages
like server state and async functions
locally and caches them and like persist
them around your app things like jodi
and zus stand and obviously redux but
other new state management libraries as well
well
how they allow you to
react doesn't solve a lot of problems
and i have so much respect for that team
that when they have the option to solve
this problem their way or abstract the
piece to allow the community to solve it
themselves they always pick the ladder
and that's why i like react more than a
lot of other solutions they let the
community do the things that they're not
doing yep
so so here here so my my argument
against hooks uh
uh
is a purely technical argument uh and it
has nothing to do with the word dx right
i don't i i still not sure if dx is a
real thing um but
here i'll just throw this out there that
uh every single time a hook is executed
right it's it's executed in code so you
use effect has a function that has to be
thrown in plus some sort of array of
arguments that show that it has or has
not changed correct that's a fairly
primitive way of saying it
yeah and so one of my big problems with
that is a it generates a closure b
generates a function c generates an array
array
right every single render and as these
things get larger and larger and larger
you find yourself generating upon every
render a thousand just throwaway objects
every single time which means you're
spending 20 30 50 100 milliseconds in
garbage collection every single render
and it just becomes this progressive
hole which ultimately in the end
hooks and classes share a lot in common
they share a way for you to identify a piece
piece
of like code or value that you can call
into now you may not be using this dot
foo to grab foo but you're using use
effect foo to get foo out right so they
actually are representatively almost
one-to-one translation of each other but
classes aren't as easily transferable
and i get that so i'm not arguing or
advocating for classes in this thing but
it does prevent a huge amount of garbage
and thinking through what you're
producing it doesn't really matter to
you and me i'm on a threadripper with 64
threads you're probably on some on my
guess is a macbook m1 drinking phil's
coffee high fiving with sweet and creamy
or whatever it is uh ambrosia of the
goddess i believe but yes i love my
macbook air okay so there you go and so
like your value and speed does not look
anything like the world right like
nothing like the world the world doesn't
even use mac products right it's like 80
plus percent android there's entire you
know india is a
heavily phone used place and so making
these decisions though very small for us
disproportionately affect a large people
around the world and so that was my big
argument i keep my trusty s5 and i have
a broken ass moto x moto g actually from
like 2003 here as well that's good
those are good very important devices in
my testing arsenal i think this is very
important and i totally agree if i was
shipping mobile clients i probably
wouldn't be using react for the like web
interface right now i'd probably do as
much server jam as i could and then pop
into stuff like solid.js when i can't
but i'm not building or recommending
people build those things in particular
very client-heavy stuff that needs to
run on low-powered devices with react
and i think that react ships to users
more often than it probably should and
we're starting to see that change with
things like remix blowing up things like
astro proving out ssr technologies even
next.js becoming the recommended like
go-to to emit a new project by the react
team themselves i think that we're
moving away from react on the client but
to go back to the point about like hooks
are classes and classes problems in a
different coat i
honestly kind of agree but i think the
new coat is much rawer and more
composable which is a huge step forward
the pa like in classes in react you had
on component mount on component mount on
props will change on props did change
and if there was a case never worked
you were [ __ ] the cool thing that's
changed now is since they didn't
put in four specific cases that you have
to build into
that you have to build your component
around as well
you could instead take part of that
which is if you had like if i had a
component that on mount i wanted to
connect to a call and on mount i wanted
to disconnect to a call i have to build
a component around those needs into the
component itself hooks let me abstract
that into a single thing use agora call
under the hood it's doing effectively
the same thing as you said it's
basically just classes unbundled but
instead of five things i have to hook
into at the component level i have one
hook that is abstracted that owns and
does all of that and i know you said
that dx isn't real i think that's the
core thing that leads to almost all of
our disagreements here i think dx is the
only thing that's real other than ux
everything else is made up okay okay
see i think ux is the only thing that
exists dx is the fake thing that we
complain about
ux is number one dx is number two tests
aren't on the list damn
that's i don't
we're just never gonna find or i don't
think we're gonna find common ground
here but this was good nonetheless
all right theo so a lot of people i
don't know if everyone around here knows
you can you like how do we find you
where do we find you at
yeah of course uh the place that i am
posting the most is definitely twitter
at t3.gg spelled out d-o-t-g-g i post a
lot i mostly talk about end stuff and
content creator media stuff i'm really
into the content creation world after
working at twitch and whatnot currently
working really hard on my startup ping
labs ping.gg is the domain for that it's
the wonderful tool bringing me into this
stream in hd and bringing prime into
mine in the same yeah we are used by a
lot of awesome content creators and
streamers really excited about the cool
stuff we're building there and yeah if
you ever want to talk crap about all
things full stack type safety and webdev
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
