you HATE your team if you make massive code changes

if you put out a code change that has
more than 700 lines of code and it has
logic changes in it not only do I hate
you but the rest of your team does as
well don't worry there's some things you
can do to shrink your code changes into
some bite-sized pieces redeem yourself
before you get pipped so that's what
we'll be talking about today why massive
code changes suck and what you can do to
change those massive code changes into
small bite-sized pieces and also avoid
all the a bunch of pain whenever you're
in like the rebase and uh comment
addressing phase hey my name is fee and
I'm a software engineer at Uber I like
to talk shop and hopefully you can get
some value from this hopefully I can
keep it short and concise as well if you
like this kind of content Please
Subscribe let me know that I'm providing
you some value I've seen three main
reasons first if you make a massive code
change it's going to take me a long time
to get context on the change and dig
through the boiler plate and understand
your code and that's not even the worst
part after I've made comments you're
going to address them and by the time
that I get back to the comments that
you've addressed I'm probably going to
have lost all the context on my comments
and then if you have multiple rounds of
comments this gets this becomes a huge
nightmare I've experienced it myself I
used to make large diffs as well and now
after the pain of experiencing that now
I don't I don't mess with that again and
this last reason may be even more
important than the churn and process
issues that are caused by large uh pull
requests so whenever you make a large
code change you really don't it's not
encouraging to the reviewer because
they'll just see this massive change and
it's very painful for them to go through
and tedious so you're not going to get
as meaningful of a comment or string of
comments as you would for a smaller code
change where the reviewer can really
analyze the logic and give you
meaningful feedback because everyone
here wants you to come out with the best
code possible no one wants an outage no
one wants bad data so just make your uh
code changes smaller so how do we do
this it's pretty simple we're going to
break your code down into smaller chunks
and I'll run through a quick example
with you we're not even going to need to
look at any code for this so one example
are you writing a workflow to crunch
some numbers instead of doing one
massive code Chang with the entire
workflow uh in one pull request you
could potentially break this down into
like four or more um stacked pull
requests so the first one that I go for
is usually uh the low hanging fruit the
boiler plate code so a lot of codee
these days has boiler plate you don't
want to include that with your main
logic because it it's just noise for the
reviewer so make a pull request for the
boiler plate and add the test for it
push it out then you can spawn a new
Branch from that last branch and in this
one you can get the data that you want
to Crunch and write the test for it then
you can push this out as well here you
can spawn another Branch off of that
last one and you can actually do the
number crunching and then the test for
that push it out then here you can spawn
another Branch for writing the data
somewhere push it out spawn another
Branch off of that now you can log your
metrics or your log messages or whatever
test that and then push it out all right
there you go one massive PR cut into
like four or five smaller bite-sized
chunks and you you'll get promoted to
senior uh junior software engineer
whatever and your team's going to love
you and one final tip that I found
really really useful is that in the F in
the early poll requests you can use
pseudo those sweet pseudo code skills
that you have to write some comments and
basically add the logic that you're
going to add in the future pull requests
as comments and that'll give reviewers a
chance to like
noncommittally uh review that logic and
help you uh with your implementation
because a lot of a lot of times the
implementation details are left out of
design documentation and things like
that so it's very easy for you to uh
think about implementing something or
actually implement it and then later on
you have to Pivot based off of reviewer
feedback so the comments will give you a
chance to test the waters and get a
chance for some feedback on this logic
early on so that you don't have to
actually go through the implementation
stage and waste time and then get pipped
see you next time