2

Understanding a new code-base

Profile picture
Mid-Level Software Engineer at TikToka year ago

I joined a new company about eight months ago. Up until now, most of the work was more about deploying existing models & doing minor tweaks here & there.

However, I feel the expectation now is to make novel changes to the algorithm. So, I work on a big ML model in TensorFlow. I haven't coded in tensorflow for some time. Theoretically, I read the papers of the code & I understand the model overall. But I don't understand the code; it seems super complicated. It has no comments and does not have the best variable names. I also fear reading it because I've never been that good at deep learning frameworks.

I once asked another co-worker how she/he read the code base. And they just told me it's so easy just to read, which makes me feel more dumb now.

I was thinking of using claude/chat-gpt to understand it. But every time I don't understand anything, it reinforces my mindset of being bad at this.

I don't talk about this to people in my team because I feel dumb asking how basic lines of code work. I feel I want to figure it out myself but how can I develop better mindsets & better approaches for this?

157
1

Discussion

(1 comment)
  • 3
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    a year ago

    First thing worth saying: it's very normal to feel stupid looking at a new codebase! Don't feel bad about using tools like Claude/ChatGPT to help with comprehension, as long as your company allows that.

    Here are some direct tips for making sense of the codebase:

    • Focus on areas of the codebase with high churn. A file of 1K or 5K LoC is too much for a human to understand, but only a portion of that file is actually being modified. That's the part to focus on -- do a git blame and understand recent changes. Look at the PR and follow the test plan and read all the comments.
      • This not only helps you understand the codebase, but also helps you onboard culturally.
    • Start running the code and adding print statements. Sounds rudimentary, but it actually works! Reading code is passive. Experimenting with when a certain breakpoint or debug statement is shown is active. You should bias toward active learning.
    • Pair program. Ask a colleague if they'd be open to letting you watch them work through a task for an hour. There are certain debugging tactics or navigation techniques which may be difficult for you to organically adopt, but you can steal from a coworker.

    We have a few resources I highly recommend on the topic of new codebases:

    Good luck!