Remix.run Logo
vivzkestrel 3 days ago

I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps?

Night_Thastus 3 days ago | parent | next [-]

Practice, context and domain-specific knowledge.

#1 is easy, #2 requires some investigation, #3 requires studying.

If you're looking at say, banking code - but you know nothing about finance - you may struggle to understand what it's doing. You may want to gain some domain expertise. Being an SME makes reading the related code a heck of a lot easier.

Context comes down to learning the code base. What code calls the part you're looking at? What user actions trigger it? Look at the comments and commit messages - what was the intention? This just takes time and a lot of trawling around, looking for patterns and common elements. User manuals and documentation can also help. This part can't be rushed - it just comes to passing over it again and again and again. If you have access to people very familiar with the code - ask them! They may be able to kick start your intro.

#1 will come naturally with time.

rramadass 3 days ago | parent [-]

Very good advice!

To add to the above; IME, #3 comes first. Study the domain to understand the concepts and their relationships. Read some books/Articles, Watch some Videos, Read Documentation etc. to come up to speed on the terminology/jargon and the general concepts/ideas. Then, in order to understand their mapping to the specific application at hand, sit with the local "guru" (there is always at least one in every group) and pick his/her brain for a few sessions (getting them brown bag lunches works great for this) on the overall architecture of the System. Next sit with testing and use the app as an end-user to understand use-case scenarios which brings all of the above together.

During all the above stages, take copious notes, draw diagrams/graphs/etc. use source code analysis/documentation/browsing/etc. tools eg. doxygen/cscope/opengrok/etc. tools to navigate the codebase and cement understanding. Note also that the above stages are to be done both iteratively and parallelly until you are somewhat comfortable and not necessarily know/understand everything.

With the above in hand, pick one use-case scenario, preferably the most complicated, critical and important one and walk through the code from beginning to end for that path. Remember that you are trying to get the overall picture and hence treat all irrelevant details as blackbox abstractions during initial phases. Over time as you iterate and review the code again and again you can slowly add in the details for a more comprehensive understanding.

Finally, there is no shortcut to the above; it takes time and self-effort. We Humans are natural-born, trial-and-error, continuous-learning problem solvers and so trust to your intelligence and commonsense to find a path to move ahead when stuck at something.

lukaslalinsky 3 days ago | parent | prev | next [-]

Read code, read code, read code. You will get better.

When looking at a piece of code, keep asking questions like: what does this return, what are the side effects, what can go wrong, what happens if this goes wrong, where do we exit, can this get stuck, where do we close/save/commit this, what's the input, what if the input is wrong/missing, where are we checking if the input is OK, can this number underflow/overflow, etc

All these questions are there to complete the picture, so that instead of function calls and loops, you are looking at the graph of interconnected "things". It will become natural after some time.

It helps if you read the code with some interest, e.g. if you want to find a bug in an open source project that you have never seen the code for.

ivanjermakov 3 days ago | parent | prev | next [-]

For me the trickiest part is getting how code is interconnected (class composition, abstraction with functions, module dependencies, etc.).

Code navigation should be instant and effortless. Get good tooling and train muscle memory for it.

gerad 3 days ago | parent | prev | next [-]

When you're debugging issues, read the code for the libraries you're using before going to their documentation. It's a great way to get exposed to other people's code.

aeturnum 3 days ago | parent | prev | next [-]

I find it useful to open the code in an editor and make running notes in the comments about what I think the state should be. As long as the code has good tests you can use debugging statements to confirm your understanding.

As a bonus you can just send that whole block of code - notes and all - to a colleague if you get stuck. They can read through the code and your thoughts and give feedback.

rramadass 2 days ago | parent [-]

Neat technique!

danielmarkbruce 3 days ago | parent | prev | next [-]

Use an LLM.

It's not a joke answer. This entire article is silly. LLMs are great for helping you understanding code.

__alias 3 days ago | parent [-]

Agreed!

Especially getting them to generate sequence / flow charts I find is a hack to figure out how everything fits together well.

Claude code is fantastic at quickly tracing through code and building visualisations of how code works together

__alias 3 days ago | parent | prev | next [-]

It's far easier to read diagrams then it is to read code.

To get a good mental model, I'll often get an LLM to generate a few mermaid diagrams to help create a mental model of how everything pieces together

hashbig 3 days ago | parent | prev | next [-]

Like everything else, practice. I like to clone repositories of open source tools I use and try to understand how a particular feature is built end to end. I find that reading code aimlessly is not that helpful. Try to read it with a goal in mind. When starting out, pick a tool/application that is very simple and lean on LLMs to explain only the bits you don't understand.

maxverse 3 days ago | parent | prev [-]

You're not alone!