
Ask HN: How to efficiently learn a codebase  new job that has no documentation? - virtuexru
So I&#x27;m in a bit of a pickle, I&#x27;ve started a new job and am trying to get &quot;familiar&quot; with the code over the holidays while most people are away. Unfortunately there is absolutely zero documentation. The codebase is massive and spanning across multiple repositories. I want to dive in and be productive as soon as I possibly can. Outside of code pairing with the the other developers (which is currently impractical due to most people being on vacation), what is the best way to approach learning the codebase at a high level (and eventually granular) so that I can make an impact ASAP?
======
davismwfl
Pick use cases and walk through the code. I usually start with something
simple like login, or common functions like logging etc. Use case focused lets
you see the app in use and then trace what the code is doing which to me is
far more valuable than just reading code. Reading code without a purpose is
useless IMO. Also doing this is sometimes great for the team because you will
find stuff they have missed and can ask questions about it which will result
in either them explaining why it is that way or saying crap, good find.

Other options (I usually use these to build documentation from a codebase I
don't know but to get up to speed faster I use the above method):

If it is object oriented, find all the base classes and work your way up
through the derived classes learning what they do. Once complete, follow the
procedural method below.

If it is procedural, then find the entry point and walk line by line, and at
the first non-system/sdk level function call start building a function map so
you know what calls what and what data is needed, passed etc.

~~~
no-s
this is a good strategy. You want to understand the flow, and discover what is
important to accomplish particular use cases. This should also tell you about
interfaces, which helps with divide-and-conquer against the code base. You
also want to be able to reproduce builds and configurations, so you need to
identify the related parts for a particular component.

Tactically reading code may not seem productive, but if the source is
versioned and someone has explained the history of the application, you might
be able to pull diffs and see what code was the target of changes, thus
telling you what is the focus of attention. Code that isn't changed very much
but is used a lot tells you what are truly fundamental parts of the overall
systems. Commits may help with identifying who to ask about a particular
section. Perhaps the committer might have or be able to identify some relevant
documentation relating to their specific work. The build can tell you about
the relevant part of the code base in use as well. Often an org may have
documentation, but the docs may not be well indexed. Running code is the
index.

I'm "experienced" and get kinda curmudgeonly ( or worse ) when I work
someplace that runs the developer shop like it's 1999 or earlier, so I'm
always vigilant for anti-patterns in the interview...the situation the OP
describes would be one of those - if job position is not "heroic individual
contributor" I would expect some sensible on-boarding for new devs supervised
by a knowledgeable guide, with some example tasks to help get up to speed.
Successful orgs do this. Orgs that don't are prone to failure and devaluing
your shares through repeated VC financing, heheh.

