Hang tight while we fetch the video data and transcripts. This only takes a moment.
Connecting to YouTube player…
Fetching transcript data…
We’ll display the transcript, summary, and all view options as soon as everything loads.
Next steps
Loading transcript tools…
Unexpected Lessons I've Learned After 15 Years Of Coding | Theo - t3․gg | YouTubeToText
YouTube Transcript: Unexpected Lessons I've Learned After 15 Years Of Coding
Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
Video Summary
Summary
Core Theme
This content distills valuable programming advice from a blog post, emphasizing practical strategies for faster development, improved code quality, and effective learning, framed through the lens of lessons learned over 15 years of experience.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
we've all seen those click baity how I
would learn to code if I started over
videos and I always thought I would
avoid making one and honestly I'm going
to continue that said I saw this article
and I was very excited for it so we're
going to read it this is the closest
you're ever going to get for one of
those classic OG how I would learn to
code from the start videos but I just
want to read this blog post cuz it
looked cool and the author's a bro so
without further Ado let's dive into M
Buffett's post a bunch of programming
advice I'd give myself 15 years AG go I
finally have the feeling that I'm a
decent programmer so I thought it would
be fun to write some advice with the
idea of what would have gotten me to
this point faster not claiming that this
is great advice for everyone just that
it would have been good advice for me
let's see if it'll be good advice for me
as well very curious this is a lot of my
comments like to let me know I'm still
clearly not a very good programmer teach
theun if you or your team are shooting
yourselves in the foot constantly fix
the gun it's better not become anti-
react I can't tell you how many times
I've been on a team and there's
something about the system that's very
easy to screw up but no one thinks about
ways to make it harder to make that
mistake when I was doing iOS Dev used
core data and subscribed to changes from
a bunch of views the subscription
callback came on the same thread that
the change was triggered from sometimes
that was the main thread and sometimes
it was a background thread importantly
in iOS Dev you can only make UI updates
on the main thread or your app crashes
so a new subscription could be working
fine but then it would break when
someone triggered an update from a
background thread or if you add a UI
update later on these are always really
fun if you have some code that is
working fine but it's on Main thread
you're like oh for performance Reasons
I'm going to move it and then don't test
it thoroughly enough and then it breaks
for your users I've seen this in all
sorts of things this is not exclusive to
iOS this is development of applications
this was just something that people
transparently accepted and often came up
in reviews for newer people on the team
every now and then one would slip
through and we'd go at a dispatch q.
main. async when we saw the crash report
I decided to fix it and it took 10
minutes to update a subscription layer
to call subscribers on the main thread
itself which eliminated a whole class of
crashes and a bit of mental load I'm not
trying to be like look at these idiots
not fixing an obvious issue with the
code base when it was obvious to me
because it would have been obvious to
anyone who thought about it for a few
minutes I had one of these recently
where I was helping a certain
undisclosed application that had a
certain massive Bill and a really slow
site on a certain service and when I
looked at their code they had like five
plus Prisma database calls on every API
endpoint all blocking even though they
had no data in common so they had a big
await block before you even start the
request just to get the user data then
they had another giant await huge query
to get some more data then right after
three more queries and I was able to
Forex their performance by just taking
all those queries and putting them in a
promise.all so that they could all run
in parallel instead of individually do I
think those devs suck I'll mence my
words but theoretically any of them
could have looked at and been like yeah
that's dumb we probably shouldn't do it
that way it's not that I am so much
better than those other devs it's just
that I've done it more I care a lot and
I'm a fresh set of eyes on the code base
it's like yeah this should be better and
as the author says here these things
tend to stick around a weird amount
because there's never a natural time to
address them I see this so often
especially with performance stuff
because if your performance sucks when
do you fix it usually when it sucks so
bad that it's causing problems and not
until then when you're first getting
onboarded you're not trying to change
anything big I I an exception here I I
have had times where I joined a code
base that was massive and I was like
wait you guys aren't using prettier you
guys don't have slint setup it's 2024
and you're still writing this JavaScript
like it's the the early 2000s and I've
had times where my first poll request to
a repo was like 100,000 line change and
everyone hated me but then a week later
they liked me but yes you probably
shouldn't be trying to change anything
big what you should be doing is reading
the poll request tab you know what I'm
going to do I'm going to in parallel
write my advice to younger Theo advice
to younger Theo and I expect this to be
different but have overlap in the
lessons the first one I want to put in
here is don't learn a code base through
the code
tab start in the pr tab I've said this
for a while and I'll continue
emphasizing it when you're working on a
big code base for the first time the
worst thing you can do is start by
reading the code because in a giant code
base the the vast majority of the code
hasn't been touched possibly for a
decade even 90% plus of the code in a
big code base just doesn't get touched
and if you spend all your time trying to
read and understand that code you're
screwed but if you go and read a whole
bunch of poll requests you see what is
merging what people push back on what is
changing and why it's changing your
understanding of that codebase will be
significantly better than if you just
try to read it line by line in fact if
you had two people one who has read all
of the code and one who has read half
the poll requests I promise you the one
who's read half the poll requests
understands the code Bas significantly
better than the person who seen every
line of code in it guaranteed yeah back
to the article as they said when you're
first getting onboarded you're not
trying to change everything and
certainly not anything big so you may
think it's weird but you shouldn't go
changing a bunch of things that you're
still learning about then when you've
been on the team for a while it sort of
just Fades into the background I really
like this framing because if you show up
to a new code base and you're like this
seems wrong you're often too scared to
do the right thing and then after a
while once you're comfortable it's now
become normalized to you that's a really
good framing I had not thought of before
and it's actually something I try to
index on when I'm running teams I'm
going to add another point to my takes
which is it's very easy to get into the
state where if somebody new is showing
up on the project they haven't touched
it all before and they say hey these
things are weird you're like oh don't
worry you'll get used to it but you're
saying that because you yourself are
used to it it doesn't mean it's normal
doesn't mean it's good so what I've
learned to do is listen extra carefully
when the dev shows up on the project for
the first time what stands out to them
what went wrong in the onboarding what
was unclear when they started reading
through the code what made their first
poll request hard to do you don't get
that feedback from your existing devs
because they're all stock homed into it
so the only way you can actually improve
on those metrics is by taking massive
advantage of the unique opportunity of a
Dev trying out your code base and trying
to contribute to it for the first time
that's a rare experience and if you want
it to be better for the next Dev listen
very carefully to the current one who's
onboarding right now and I I couldn't
agree more that this is super common
that devs are scared to make the big
change based on what they expect and
then by the time they have the
confidence is too normalized and they
move on it's a mindset shift you just
need to occasionally remind yourself
that you are capable of making you and
your team's life easier when these sorts
of things are hanging around absolutely
absolutely agree first there's actually
a good question here do you worry that
person is coming in and trying to make
what is comfortable to everyone else
more comfortable for them or what
they're used to seeing that's a
conversation to have but chances are if
you're showing up and you've worked in
other code bases especially at a company
like I when I was at twitch I touched
like probably 20 plus code bases in a
meaningful way and when I was working on
most of them the tooling was relatively
consistent there was obviously lots of
differences between them but then when I
would show up in another code base from
a different team be like oh you guys are
just behind the standards of the rest of
the company can I propose some changes
to make these things a little more in
sync and usually a couple do would push
back but a few others would be like yeah
I worked on two other code bases here
and those were better we should have
that here too and as long as you can
build a few allies and have a good
conversation these changes are almost
always worth doing and talking about
back to the article assess the trade-off
that you're making between quality and
pace and make sure it's appropriate for
your context Banger after Banger damn
there's always a trade-off between
implementation and how confident you are
about correctness so you should ask
yourself how okay is it to ship bugs in
my current context if the answer to this
doesn't affect the way you work you're
being overly inflexible what a banger
God coming out stronger than even me on
it what a way to say unit tests are
useless if they're useless to you so
yeah obviously I agree I think that the
way you write software that failures
would kill people should be very
different from the way you write
software where failures mean they don't
get a fancy Emoji when they hit a button
quite as fast as they would otherwise
it's important to recognize the the
difference in these types of things
where certain Services should never fail
ever and if they do people die and then
there's other services like especially
in the startup world where as
unintuitive as it may seem failures
might actually be somewhat good an
interesting thing we learned when we
were running ping is that if we had two
customers one had no issues they signed
up and everything went well and then one
customer had some issue big small
whatever and they report it to us if we
fix that issue for them fast enough and
we get them involved in the conversation
so they feel listened to understood and
cared for the customer that had the bug
will be more loyal than the one who
didn't so if we had built everything in
a way where it's harder to write bugs we
might have had less happy customers not
even accounting for the fact that if we
slowed things down enough to never ship
bugs we would never have shipped a lot
of the features that our users wanted
and if they did still run into bugs it
would have taken us even more time to
fix them so ignoring all of that having
bugs was still better in our context in
scenario we making Medical where that
would not be the case we're making a
silly app for streamers to collaborate
very different use case very different
results very very different context and
you should adjust the way you work based
on that context couldn't agree more at
my first job I was working on Greenfield
projects around data processing which
had good systems in place for
retroactively reprocessing data the
impact of shipping a bug was very minor
the proper response to that environment
is to rely on the guard rails a bit move
faster because you can you don't need
100% test cover or an extensive QA
process which will slow down the pace of
Dev at my second company I was working
on a product used by tens of millions of
people which involved high value
financial data and personally
identifiable information even a small
bug would entail a postmortem I shipped
features at a snails pace but I also
think I may have shipped zero bugs that
year usually you're not at the second
company I've seen a lot of devs air on
the side of that sort of programming
though I couldn't agree more even when I
was at twitch I found a lot of teams
trying to meet like Amazon's reliability
standard it's [ __ ] twitch I loved
working at twitch it was a great company
building awesome things and I'm
streaming live on Twitch right now by
the way every Wednesday live on Twitch
if you want to see how I record these
videos and hang out and chat with my
homies here twitch is a great place to
work twitch is a really cool product
twitch does not need to have six NES of
reliability and if that results in a
shipping worse features slower it's a
mistake and the fact that we had such
insane code coverage rules was just
obnoxious it actually resulted in us not
shipping things well pretty regularly a
story I tell a lot because it haunts me
is that we had I think there was 80 or
90% code coverage as a rule I had a
feature that we rewrote to be about a
tenth as much code so we had the old
version which was let's make up numbers
um let's say 100,000 lines of code and
we had the smaller version which was
10,000 lines of code both are probably
10x smaller doesn't matter the 100,000
line of code version had code coverage a
bit over 80% the 10,000 line of code
small version had code coverage at 100%
both were in the project because it was
feature flagged so you'd get one or the
other we had moved 100% of users over to
the new one the new one was faster it
had new features users liked it more
you're ready to go okay so it's time to
deprecate the old one to delete that
100,000 line of code mess I never could
delete it because deleting it put us
just below the code coverage threshold
even though the feature I replaced it
with had better code coverage it didn't
matter because the pure number of lines
of code that were tested being removed
was enough to just barely drop us under
the threshold and I would not be
surprised if that giant pile of unused
code still existed in the twitch code
base simply because deleting it hurt a
metric that didn't matter for a product
where people can play games and talk to
each other that is every layer of that
is stupid every single one and even if I
loved working at twitch that's just
proof of how dumb this is the only code
coverage number that's acceptable is
100% And even that is dumb too yeah I I
digress anyway
as they were saying usually you're not
at the second company I've seen a lot of
devs air on the side that of that sort
of programming though in situations
where bugs aren't Mission critical which
is 99% of web apps totally agree you're
going to get further with shipping fast
and fixing bugs fast than you would
taking the time to make sure you're
shipping pristine features on your first
try totally agree and I also agree that
good test should not think about code
coverage percentages but if you're going
to enforce one the only percentage of
code coverage that makes any sense at
all is 100 still doesn't make much sense
but at least it makes some a less than
100% number nonsense useless throw it
away next Point spending time sharpening
the a is almost always worth it Prime is
going to love that one you're going to
be renaming things you're going to be
typing type definitions finding re
references Etc a lot and you should be
fast at this you should know all of the
major shortcuts in your editor you
should be a confident and fast typist
you should know your OS well you should
be proficient in the Shell you should
know how to use the browser Dev tools
efficiently and effectively I can can
already tell people are going to be in
the comments like you can't just spend
all day tweaking your neovim config I
mean if you become a YouTuber that talks
about neovim you can but I digress
sometimes you need to chop the tree too
I don't think I've ever seen someone
actually overdo this though one of the
biggest green flags I've seen in new
Engineers is a level of care in choosing
and becoming proficient with their tools
you know
what fine my issue is never that
somebody's really excited about NE ofm
is when they shame others for being less
excited if you want to go all in on NE
and really care about the cooling
experience that you have A+ if you're
going to make fun of me for saying vs
code is good enough get off my team
that's my line also on that note before
I forget I went through this phase so I
can talk all the [ __ ] I want I still
spent a whole summer at Amazon
configuring my I3 t-u neovim everything
because I wanted to be a real legit
hacker so I could feel less like an
impostor and learning those skills
helped me a ton I got way better at ins
and outs of navigating
complex developer environments that all
said once I got a Macbook I kind of just
drifted towards full screen vs code and
I've been happy with it since but like I
had to do my time in the trenches of a
crazy complex developer experience setup
that I owned all of and was really
confident in before I could make that
shift with similar confidence where I
just live in command Tab and Tilda and
as you guys can see I have very little
stuff open cuz I don't need to have a
whole lot of stuff
open next point you can't easily explain
something is difficult then it's
incidental complexity which is probably
worth addressing I love that I love this
point if you can't say why it's complex
you should fix it like this is hard is
not a good answer this is hard because A
and C where those things are simple
that's a good answer my favorite manager
in my career had a habit of pressing me
when I would claim something was
difficult to implement often his
response was something along the lines
of isn't this just a matter of sending
up X when we y or isn't this just like Z
that we did a couple months ago very
highlevel objections is what I'm trying
to say not on the level of the actual
functions and classes that we were
dealing with which is what I was trying
to explain I think conventional wisdom
is that it's just annoying when managers
simplify things like this I know I've
pissed off a lot of people doing that
but a shockingly high percentage of the
time I'd realized when he was pressing
me that most of the complexity I was
explaining was incidental complexity and
that I could actually address that first
thus making the problem as trivial as he
was making it sound this sort of thing
tends to make future changes easier as
well I'll drop the hot take of this is
why I like react and a lot of the new
react stuff is once you stop thinking
about those details and you plan the
system and make decisions around the
design I actually find it to be much
easier to both build and reason about
and then longterm most importantly makes
it easier to maintain these are all good
things try to solve bugs one layer
deeper ooh and react's already coming up
oh boy imagine you have a react
component in a dashboard that deals with
a user object retrieved from state of
the currently logged in user you see a
bug report in Sentry Sentry plug Channel
sponsor they're not sponsoring this
great product for debugging stuff though
you see a bug in Sentry where user was
null during render you could add a quick
if no user returned null or you could
investigate a bit more and find that
your logout function makes two distinct
State updates the first is setting the
user to null and then the second is
redirecting the user to the homepage you
swap the two and now no component will
ever have this bug again because the
user object is never null when you're
within the dashboard keep doing the
first sort of bug fix and you end up
with a mess keep doing the second type
of bug fix and you'll have a clean
system and a deep understanding of the
invariance makes perfect sense it's so
tempting to just if no user return null
I will say as a huge react query fan
I've been guilty of this where I solve
those error cases where they're coming
up with errors but since especially with
like the new model I find myself just
defining within the call the right thing
the update to set things to null should
also send you to the right place I
absolutely agree you should aim for the
second type of fix don't underestimate
the value of digging into history to
investigate some bugs again reading PO
requests all that stuff really really
good strategies I've always been pretty
good at debugging weird issues with the
usual toolkit of print line and the
debugger so I never really looked at get
much to figure out the history of a bug
but for some bugs it's crucial I
recently had an issue with my server
where it was leaking memory seemingly
constantly and then getting out of
memory killed and restarted I couldn't
figure out the cause of this for the
life of me every likely culprit was
ruled out and I couldn't reproduce it
locally it felt like throwing darts
blindfolded I've certainly had bugs that
felt like that and it is miserable I
looked at the commit history and found
that it started happening after I added
support for Play Store payments never a
place I would have looked in a million
years it's just a couple of HTTP
requests turns out it was getting stuck
in an infinite Loop of fetching access
tokens and after the first one expired
maybe every request only added a
kilobyte or so to the memory when
they're retrying every 10 milliseconds
or so on multiple threads that starts to
add up quick and usually this is the
sort of thing that would have resulted
in a stack Overflow but I was using
async recursion in Rust which doesn't stack
stack
Overflow rust is a great programming
language this never would have occurred
to me but when I'm forced to look into a
specific bit of code that I know must
have caused it suddenly the theory pops
up I'm not sure what the rule is here
for when to do this and when not to it's
intuition based in a different sort of
huh to a bug report that triggers this
sort of Investigation you'll develop the
intuition over time but it's enough to
know that sometimes it's invaluable if you're
you're
stuck along similar lines try out get
bisect if the problem is amendable to it
meaning a g history of spa commits a
quick automated way to test for the
issue and you have one commit you know
is bad and one that's good I'm going to
go a slightly weird angle with this for
my own
advice make it
deploy then make it useful I'd find that
a lot of devs early on especially myself
would spend so much time trying to make
the code work locally on their machine
that by the time they had it working it
was already complex enough to deploying
it was nonviable with modern tools that
make CI and CD easy like forsell netlify
any of these other options you can just
link your project to a GitHub repo and
now it will auto deploy Auto build and
auto publish any changes you make when
you push up the commits which makes it
significantly easier in a situation like
this where you're trying to figure out
which commit broke you're trying to
figure out why deploy aren't working or
why out of memory is happening if you
have the ability to Auto deploy every
version you can go look at an old
version and see whether or not it was
working as expected these types of
things become exponentially easier and
the amount of time you'll spend dealing
with these things is exponentially lower
one more similar thing learn get really
early I know this what's gotten me into
trouble but the confidence you get from
realizing making changes isn't scary is
huge when I started school it was very
clear to me that my peers were scared
when I would use their machines in
delete code because to them code deleted
was code gone forever but if you learn
the basics of get you don't worry
anywhere near as much yeah this is a
great reference I helped the dev a while
back who was trying to deploy their
giant remix project onto versel I was
the one screen sharing I was just you
can even tell from the uh terminal there
that's obviously me that's my color
coding that's my um t-u everything that
was my machine because I was so annoyed
that the particular Dev that was having
the problem was insisting that vercell
was the issue even though they had never
once got it to deploy so my response was
what the [ __ ] can we get this remix can
we get a remix project to deploy and
then we can debug the difference between
the two because you should have made
this deploy as soon as you made it and I
was able to get it working in like 10
minutes once I jumped in even with like
Lee Rob and crew hopping in too it was a
a fun chaotic experience that absolutely
could have been settled if the dev had
deployed before they built so as
unintuitive as it might sound to put
deploy first before you make something
useful trust me it makes life better and
that's why all of my tutorials I deploy
really really early and then we do the rest
rest
after back to the article this is a
great article by the way uh shout out M
Buffett will give you a big Shout Out
near the end I'm sure I'll put their
Twitter in the description too give them
a follow it's really easy to write
terrible code but it's also really easy
to write code that follows absolutely
every best practice which has been unit
integration fuzz and mutation tested for
good measure your startup will just run
out of money before you finish don't
forget those Airbnb lint rules that
Airbnb doesn't even use so a lot of
programming is figuring out the balance
absolutely agree I'm going to drop the
hot take of simple almost always scales
one more of Mind aim for simple it
scales well I'll even put surprisingly
well I find people will look at a simple
thing and say oh what happens when
that's at Enterprise scale well if the
architecture is simple enough then what
the way it scales up as it gets more
difficult is way less bad than something
that starts difficult and has more
complexity as you go and it's a balance
it's absolutely balance but if you aim
for simple the likelihood that things
scale well is actually higher not lower
and people love to pretend otherwise and
they're wrong if you erir on the side of
writing code quickly you'll occasionally
get bitten by a bad bit of tech debt you
learn stuff like I should add great
testing for data processing because it
often is impossible to correct later or
I should really think through table
design because changing things without
downtime can be extremely hard if you ER
on the side of writing perfect code you
don't get any feedback sorry rust
things just universally take a long time
you don't know where you're spending
your time on things that really deserve
it and matter or if you're just wasting
that time feedback mechanisms are
essential for Learning and you're not
getting that I absolutely agree I was
just filming a video earlier about
Ladybird which is a new browser that's
entirely unusable because its goal is
implementing web standards not being a
good usable browser as a result the
likelihood that they get actual feedback
about what is and isn't working is way
lower versus the browser I'm using Arc
which I've used for a while now still
has a fun bug where when I click the
collections tab because I download a lot
of things it lags my browser is chugging
now because I have some thousand files
in that folder which means I can give
them that feedback and they're
rethinking decisions around their entire
Swift architecture because Swift is so
bad at long lists but they're able to
learn these things and make these
changes because they have actual users
because they ship something sooner
versus ladybird which isn't going to use
any existing solution they're building
everything themselves and as a result
the amount of time it takes for them to
get any feedback at all is
massive to be clear I don't mean bad as
in I couldn't remember the Syntax for
creating a hash map so I did two inter
Loops instead I mean bad like the
following instead of a rewrite of our
data ingestion to make the specific
State unrepresentable I added a couple
asserts over our invariance at a couple
key checkpoints oh
oh yeah our server models are exactly
the same as the dto we would write so I
just serialized those instead of writing
all the boiler plates so we can write
the dto later as
needed I skipped writing tests for these
components because they're trivial and a
bug in one of them is no big deal I mean
that's all components ideally but yeah good
good
examples make debugging easier I like
that one a lot let's see what he has to
say here there's so many little tricks
I've acquired over the years on making
software easier to debug if you don't
make any effort to make debugging easy
you're going to spend unacceptable
amounts of time debugging each isue as
your software gets more and more complex
hey uh nextjs make things easier to
debug please thanks I know you're
working on it I know's working on it I
just had to point that out because if
you don't have browser tools things are
a lot harder it's a great Point too
you'll be terrified to make changes
because even a couple new bugs might
take you a week to figure out yep
there's plenty of code bases I'm scared
to touch because I'm more likely to add
a bug than fix the thing I'm trying to
fix in the first place here's some
examples of what I mean by the way this
person's a huge chest brow and has a cou
cool chess Services they built for the
back end of chessbook they have a
command to copy all of a user's data
down to local so they can reproduce
issues easily with only a username based
they trace every local request with open
Telemetry making it very easy to see how
a request spends its time also based
even though open Telemetry is a [ __ ]
standard I have a scratch file that acts
as a pseudo repple which re-executes on
every change ooh I love this I'm a big
fan of having a Sandbox file in your
project so that you can just try things
there and not have to like spin a bunch
of stuff up to do it this makes it easy
to pull out bits of code and play around
with it to get a better idea of what's
going on love it totally agree oh here's
a fun one in staging they limit
parallelism to one so that it's easier
to visually parse logs ooh spicy I like
it for the front end I have a debug
requests setting which prevents
optimistic loading of data to make it
easier to debug requests interesting I
think I dig that I also have a debug
State setting that will print out the
entire state of the program after each
update along with a pretty diff of what
happened they also have a file full of
little functions that get the UI into
specific States so that is they're
trying to fix bugs they don't have to
keep clicking in the UI to get to that
state I should have more of that it's a
weird example but I have this project
Doge T3 G so I actually put this little
query Pam on the page where Dev mode is
true now we get this thing on the page
where I can really quickly add a bunch
of values add money and then get this
into the state I'm trying to debug at
any given time this was essential to
getting this working I can't imagine how
I would have built this project without
it there's definitely not a really
popular project in the front-end world
that is significantly more annoying than
it ever should be that people use
because getting their components into
the right state is really hard that's
that's definitely not a thing it's not
like people would use this component
Library tool to debug UI because they
don't have a way to get the UI into the
state that they're actually testing that
would be absurd there's definitely not a
whole industry of people making really
annoying tools that keep getting misused
because UI devs kind of suck that's
definitely not a thing unrelated website
by the way ignore whatever I was just
scrolling totally don't know how I ended
up there yeah having ways to get your
components into the state that they
should be yeah you should and every Dev
should normalize that the idea of making
it easy to see play with debug Etc it
helps with places you wouldn't even
expect like having these tools makes
like QA easier too it's just it's good
it's really good practice to find simple
ways to get your application into the
states that you're actually working on
it also will encourage you by the way to
make things simpler because if it's too
hard to get things in the right State
you'll start to realize ways to simplify
that State Management and those are
almost always worthwhile stay vigilant
about how much of your debugging time is
spent on setup reproduction and cleanup
afterwards if it's over 50% you should
figure out how to make it easier even if
that will take slightly longer this time
bugs should get easier to fix over time
all else being equal I hate that's a
spicy take because it's entirely correct
as a code base gets more complex you
should be counter trting that making
reproduction even easier to deal
with when working on a team you should
usually ask the question I'm putting
that in mind too uh dumb questions rule
I've talked about this a bunch I can't
even remember which videos I have
because there been so many the dumb
questions rule is a thing I apply to new
Engineers when they join my team I
mandate a minimum number of dumb
questions that they have to ask every
day if they haven't asked me at least
one dumb question every day for their
first week or two the day is not over
until they ask the question the reason I
push this is because devs and honestly
everyone is really insecure about
feeling dumb in saying dumb things so I
force them to get over that by making
them do it ask the dumb question and it
kind of goes back to this point earlier
of taking feedback from unfamiliar devs
more seriously because the dumb question
is a thing others probably thought when
they were trying the project for the
first time but they were too scared to
say and if you don't get that feedback
you'll never know and this goes both
ways if you're the Dev that always asks
the question you're more likely to be
working in code bases that solve these
problems because if everyone on the team
isn't willing to say it and you're also
not willing to say it it won't get fixed
but even if everyone else isn't willing
but you are all of a sudden these things
start to get fixed so it's really
important to ask the questions even if
no one else on your team is in the worst
cases you get fired for and you can find
a team that's better aligned with you
there's a spectrum of trying to figure
out everything for yourself versus
bugging your co-workers with every
little question and I I think most
people start their careers way too far
on the former side absolutely agree it
has been hard for me to find people who
ask too many questions when they're
working with me there are absolutely
people who are not working for me that
are just random people in my DMs asking
me all sorts of stupid [ __ ] totally see
that that is a problem but for the vast
majority of people especially once
they're employed they're almost scared
to ask the question and you got to push
them to or if you're that person you
just got to do it don't be scared to ask
the question almost ever there's always
someone around that has been in the code
base for longer or knows technology X
way better than you or knows the product
better or is just a more experienced
engineer in general there's so many
times in that first 6 months of working
somewhere where you could spend over an
hour figuring something out or you could
get the answer in a few minutes again
really important point I can't tell you
how many times the dumb question ended
up being well I've been stuck on this
for 4 hours do you have any tips on how
to get this particular tool working and
my response was oh yeah you should run
these two commands instead I should have
updated the docs for that my bad I'm
going to go fix that and now this thing
that had spent hours on get solved in
like 30 seconds and our docs improve
huge massive this is a great thing thank
you schaer for sharing this junior Dev
here I've been praised as the best on my
team at asking questions ask the
question you don't have to be an
experienced engineer to ask good
questions in fact the inexperienced
Engineers they have a massive Advantage
because they have better questions
because they're not going to default to
existing knowledge that might be
incorrect they're going to challenge the
thing and they're going to ask great
questions as a result lean into that as
a junior Dev and as an experienced one
get those questions get that feedback
it's all so helpful this happens all the
time I I can't I would love if you have
this to link it because this happens
five times a day there is no world in
which I remember your specific question
like you it we all have these moments
that haunt you know what one more piece of
of
advice that one dumb thing that haunts you
you
nobody remembers
it I have plenty of those I have so many
of these moments where like wow I can't
believe I thought that or did that like
like here's a fun one that actually got
brought up because others remembered it
for me so bad example but I love it I
didn't know react query could be used
for things that weren't graphql until
Tanner Lindley was on Jason langdorf
stream there's actually in the VOD I bet
I could find it yeah cool almost
certainly going to be at this time stamp
yeah yes look at me in chat
there look at
that I am so so so stupid and somehow
just realize react query isn't just a
graphql client I need to go do a very
deep dive and this was October 21st 2020
we've all had these issues we've all had
that moment where we feel dumb and
nobody remembers the only reason that
one got noticed is somebody else was
watching the video and said yo Theo I
saw you pop up in stream here look at
your comments I was like wow holy [ __ ]
I'm dumb but no one else remembered no
one remembers those moments don't worry
about it and again the only time that
this would ever annoy people if you're
asking too many questions is if it's
clear you could have found the answer
yourself in a few minutes and even then
it can be useful because you might not
have known the strategy to find the
answer and if I then show you that
awesome you'll ask less questions I've
had once or twice in my career where
somebody would ask questions over and
over and I'm like okay how did you try
to figure this out and then realize they
didn't know about one of the docs
resources or one of the things to search
sort for and when I show them that they
would stop like almost every time if
you're asking too many questions it's
because you haven't been shown the way
to find the answers and if you ask too
many questions awesome now we can
realize that deficiency exists and we
can plug it after you responded to me I
sat down and got really into
understanding how these things actually
work so it helped you a ton that's
awesome I'm sorry if I was harsh in the
reply there but I it sounds like you
used that opportunity to level up and be
better like even if I didn't handle your
question well it seems like you handled
it awesome and I really hope that you're
not scared of asking questions in the
future because that's dope to have you
here have you sharing this experience
and have you productive enough to to
deeply understand next now you massively
leveled up as a result of that so I love
that shipping Cadence matters a lot
think hard about what will get you
shipping quickly and often love this
startups have limited Runway projects
have deadlines when you quit your job to
strike out on your own your savings will
only last you so many months that this
hits too deep this hurts Hur me in my soul
soul
[ __ ] ideally your speed on a project
only compounds over time until h no I I
have another Theo point and it's not
even that related to this but it's
inspiring me uh you don't know what
level you're at until you get an offer
at that level somewhere else companies
love to make you think you're not a
certain level because they don't want to
pay you for that promotion so they
always make the promotion process hell
there was a window where I didn't think
I was a senior Dev because I was having
problems getting my senior doc to like
get started I just getting my managers
to do it was annoying turns out those
managers sucked and when I started
applying to other companies Not only was
I massively exceeding their bar for
senior I was approaching like the staff
level bar and I didn't realize that
because I didn't realize I should be
talking to other companies and not
basing my ability on what this one
particular person thinks they should or
shouldn't sign off on because the
reality was if that manager promoted me
they'd have one less headcount for a
senior Dev but if they didn't promote me
they could hire another senior Dev and
have me underpaid outworking that senior
Dev it was an obvious win for my team so
I never understood what my actual level
was because my company had a competitive
advantage of not telling me and then
when I figured it out gave him the
finger and quit they were worse off as a
result regardless this happens all the
time and you as an individual developer
should know how much you're actually
worth what your skills actually look
like measured up against other actual
companies so do interviews a ton all for
that a point interview a lot at least
once every 6 months one more on this
topic give
interviews if you're qualified for the
role you're qualified to interview for the
role yeah I find so many devs take way
too long to get into the interview
process on both sides they take too long
to start getting interviews to work at a
company and once they're at the company
they're hesitant to start giving
interviews interviews are essential to
our success and growth and opportunities
as devs you got to push through it it
sucks but you have to give interviews do
interviews deeply understand interviews
if you can't do those well you're
massively bottlenecking yourself and
your capabilities certainly
bottlenecking your success yeah this hit
deep the reason I thought of all of that
is I just started thinking too much
about quitting and going off on my own
and realizing at that moment oh [ __ ] I
should have quit a while earlier I am
very down if you're down to share but no
pressure at all hoi I still want to
understand why the session never gets
past the client this is strange as [ __ ]
to me the data is there but it simply
never receives the prop I'm looking all
over for the solution this one was not actually
actually
particularly obvious yeah I'm going to
drop an even hotter take for you hooi
this wasn't a problem with your
understanding so much as next being
shitty get serers side props being a
function both for redirecting and for
passing props is bad this code shows
just how bad the conflation of concerns
that existed in Old Pages router was the
fact that you could do this that you
could return a redirect and props is a
fundamental design failure in next so I
do not blame you at all for this this is
why old nextjs sucked and this is also
why I think new nextjs is so good it
does a great job at solving these
problems by not having these magic fun
that have all of these different roles
you just component style call what
you're doing when you do it so I
actually am pumped that you found this
example because it's subtle but it
actually perfectly showcases the types
of design failures that the old next
model by Design encouraged a lot of so
phenomenal oh I missed your follow-up
question too my bad on that you pass
session as props it does not show in the
problem uh I think you understand now so
whenever you send the data grabs app
grabbing session provider so whenever
you send the data of the session as
props s is grabbing it passing it yep
yep to be clear these things were way
more complex than they should have been
and none of this is your fault like I
really want to emphasize that point this
design sucked because of next and I
actually love that you brought this up
as an example because yeah this was your
huge learning is you had only worked in
single Page Apps and this abstraction
for them wasn't great like you know that
was a good question cuz it was like you
didn't pretend you understood more than
you did you said that it doesn't make
sense it's small I'm going to give you a
massive compliment here there's a lot of
subtle things in this question that I
think you did really well I want to
understand you didn't say this is wrong
or dumb you didn't say this problem
sucks or that this tool sucks you said
that you want to understand why this
strange thing is happening and you even
said strange to you the qualifiers here
are actually incredible this is like
almost like an artistic example of like
a really really good question when you
feel lost and clueless you owned that it
was your desire to understand this was
the fact that you said the word
understand before describing the problem
that you want to understand huge huge
green flag you're not just trying to fix
the problem and move on you want to
understand it and it's strange to you
you know it might not be strange to
others you know that there might be
something better that's just not
clicking for you this is a great great
question so yeah I wouldn't even qualify
this as a dumb question honestly if if
you had presented this to me as an
employee of mine as your dumb question I
would have said no that's a good
question come back with the Dumber one
later this is great A+ fantastic
representation and like to anyone
looking for examples of how to ask a
question about something you don't
understand here you go just say it say
that you want understand and you don't
and say what is confusing to you
fantastic A++ thank you for sharing that
who you wrot by the way like that's
really good gold example of asking a
question when you're clueless people are
really scared to do if you just don't
understand at all it's scary to ask the
question but you did it you learned a
bunch and now I get to highlight you in
a video as an example of these types of
things A+ is all around I love this [ __ ]
thank you for sharing don't worry about
having to participate in the time and
all that but if you're down and you're
here clearly you bring a lot of value so
pump to have you here man anyways let's
see more what this author has to say
ideally your speed on a project only
compounds over time until your shipping
features faster than you could have ever
imagined to ship fast you need to do a
lot of things oh I'm so pumped that you
have you're the best person to teach
like knowing that you ask questions that
well means you're going to set a really
good example for the students the fact
that there's people that are learning
from you makes me very very excited back
to these examples of things that you
should do if you want to ship fast you a
system that isn't prone to bugs you need
a quick turnaround time between teams
you need a willingness to cut out the
10% of a new feature that's going to
take half the time Yep this happs a lot
the the number of times I see a product
a feature a tech plan a spec that would
be way way simpler if we trim one or two
things half my videos where I'm ranting
about old jobs are just me complaining
about this specifically so couldn't
agree more consistent reusable patterns
that you can compose together for New
screens features and end points Yep this
is a huge part of why react one by the
way the fact that the patterns and
components can all be reused composed
stacked and done all these crazy ways
that's why react really took off early
because it scaled well to small projects
and big projects and it lets you move
really fast quick and easy deploys wow I
must have pre-read when I said make it
deploy then make it useful crazy process
that doesn't slow you down like flaky
tests slow CI fuzzy linters slow PR
reviews jira as a religion Etc yep and
about a million other things of course
shipping slowly should Merit a
postmortem as much as breaking
production does holy spicy take that I
love our industry doesn't run like that
but it doesn't mean you can't personally
follow the north star of shipping fast
couldn't agree more at every scale I
just dropped the link in the reply to
this tweet because that was such a great
article I know I say that a lot but uh
holy [ __ ] I'm very thankful for this
author when I found this article
initially I quickly checked their
Twitter they were following me I was
like oh my God awesome I reached out
they were really hyped and God I'm
excited for them to see this video
because that was great I say this a lot
but that article was great I haven't
agreed that hard on something I've read
on stream for a while let me know what
you think in the comments though and
what you learned that might benefit you
as an experience Dev or as a new one
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.
