Swedish girls group you need water this
is probably not the right way to do it
but it’s the way I do it oh woo
when you work as a programmer it’s only
a very small part of your day that is
spent on actually writing code the mass
majority of your time is spent trying to
understand code that was already written
either it’s somebody else’s code or it’s
some code that you wrote yourself a year
ago
it is especially tricky to get into a
completely new code base it might be a
new job or a year conveys that your team
takes over from another team at work
I’ve done this a few times during my
career and I developed a sort of process
for it and I figured it would be
interesting to a couple of people to
hear about it that is what we are going
to talk about today in case you are new
you are watching fun fun function it’s a
weekly show where we try to become more
excited and confident about programming
by exploring old wisdom wild ideas and
having fun at the end of this episode I
will customarily ask you to subscribe
without further ado my five step process
to understanding a new code base is find
a mentor get an overview do a small
quests have a don’t get stuck rule and
use code review so step one find a
mentor find a programmer that is already
familiar with the code base and ask them
if they are willing to be peppered with
your silly questions over the coming
weeks it’s also a bonus if you can
arrange so that the project lead is
aware of this relationship so that they
can ease off a bit on your mentor during
this period I should say that in some
cases it’s going to be a challenge to
find a match
code base that you’re trying to get into
might be an open-source project or your
workplace culture might just be crap and
people might not be very interested in
helping others out even so I think that
you should make an effort to try to find
a venture if that is at all remotely
possible because I don’t think it’s
really realistic to become familiar with
a codebase without talking to an actual
person that works in it without eight
you’re basically just doing some kind of
weird archeology and that is going to
take you ten times longer than if you’re
doing it yourself find a mentor that is
step one step two get an overview ask
your mentor to give you a high level
level ask your manager to give you a
high-level overview of the system it’s a
philosophy its architecture its style or
the lack of it ask your mentor what the
third-party tools and frameworks and
libraries are being used and make a list
of them it will really help you to study
the documentation of tutorials of these
tools of frameworks and libraries in
isolation before exposing yourself to
them when they are entangled together in
a big system that you’re unfamiliar with
it’s also helpful if you can ask your
mentor to give you a sort of history
lesson on why and how the system or
application came to be and its
predecessor if there was one and that is
step two get an overview step three do a
small quest simply ask your mentor to
assign you a small task that they would
think is appropriate for a beginner in
the codebase it’s usually a small bug or
a tiny tiny feature do a small quest
that is step three step four have a
don’t get stuck rule you should sit down
and try to fix the quest on your own but
as soon as you get stuck for more than
fifteen twenty minutes or so you should
ask your mentor for help you should
always try to solve the problem on your
own for a bit but only for a bit in my
experience if you get stuck you can
figure most things out in 15 minutes but
if you don’t if you you haven’t been
unstuck in 15 minutes it’s most likely
going to take you hours to get unstuck
and that is just wasting time
the don’t get stuck rule is really
really important but it is surprisingly
hard to follow because when you get
stuck you feel like you should be able
to fix the problem on your own try to
remember that it is a bad thing a really
really bad thing to be a lone wolf great
software is built by great teams not
great developers I recommend using an
actual timer to keep yourself from going
into lone wolf mode I personally use
break time for mac have a don’t get
stuck rule that is step 4
final step 5 cold review use cold review
when you have completed your quest and
have a fix submit your code for review
by your mentor they will point out
changes that you can make to reuse
existing parts of the code base instead
of writing your own and how to make your
change fit more holistically into the
project while we’re at it I’d like to
make a shout out to code review in
general because it is amazing if your
team does not already code review on
every change today adding that to your
process is the single best quality
improvement that you can make I’m
completely serious about that improves
code quality it improves knowledge
sharing it improves consistency and most
importantly it makes your team feel a
shared ownership of the code make use of
code review that is step 5
recap find a mentor get an overview do a
small quest have a don’t get stuck rule
and use code review and then you just
repeat you go back to step 3 and pick
another small quest and so on this will
get you familiar with a new code base
really quick
on that’s it for this episode of fun fun
function make sure that you don’t miss
out on the next episode on Monday click
the button to subscribe on your likes male please stay curious