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