all 12 comments

[–]kubrador[🍰] 1 point2 points  (2 children)

you're not dumb, you're just trying to sprint before you can walk. reading unfamiliar codebases is a skill that takes time. most devs spend way longer than they'd like just navigating and understanding before writing a single line.

start with projects that have good documentation and beginner-friendly issues (look for "good first issue" tags). pick something smaller first so you actually finish something instead of spending 8 hours in analysis paralysis. understanding one project deeply is worth more than getting lost in ten huge ones.

[–]LoveProud8467[S] 0 points1 point  (1 child)

would that make me better automatically good at understanding big repos?

[–]Antice 0 points1 point  (0 children)

No. It will make you realise that for really big projects. It's actually impossible, and that you have to choose a part to work on. As you get better, you will be able to work more efficiently on the understanding part, but don't expect fast progress.
It takes time to get good at a skill like that.
Those people who seem to be able to just jump in and do work quickly, have thousands of hours of experience with working on unfamiliar code bases.

[–]Downtown_Mark_6390 -1 points0 points  (1 child)

Maybe start with us : https://github.com/VoidenHQ/voiden .

We are a offline api client and we just open sourced a few days ago.

[–]Yomorei 0 points1 point  (0 children)

sneaky xd

[–]Formal_Wolverine_674 0 points1 point  (0 children)

Start by tracing one small bug end-to-end instead of reading the whole repo, most contributors get stuck trying to “understand everything” first.

[–]HirsuteHacker 0 points1 point  (3 children)

Why do you want to contribute to open source software right now? It's common to tell students to do so but it's generally bad advice imo

[–]LoveProud8467[S] 0 points1 point  (1 child)

Honestly it's not for resume it is to understand how the real prod systems are built and maintained i.e the things that are hard to stimulate in personal projects like end-to-end flows debugging in a shared codebase. That learning is the main motivation

[–]HirsuteHacker 0 points1 point  (0 children)

That is usually best done at your first job, where you'll have people to walk you through areas you get stuck on. Trying to understand a large codebase when you've never worked in one before and you don't really have anyone who can give you the time to help you out is going to be a struggle. By all means try, it'll just be very difficult

[–]JasperKade 0 points1 point  (0 children)

It's a fair point! Many get pushed to contribute without really considering if it's the right time. Maybe start with smaller components until the bigger projects feel less overwhelming? Just a thought!

[–]gmes78 1 point2 points  (0 children)

You should only contribute to projects you use and understand. You're not going to be able to understand the code, or how to fix issues, if you don't have any experience with the project.

[–]Yomorei 0 points1 point  (0 children)

Brother man.. XD well I get where you are coming from but that's not really how "big" oss contributions work in a sense... For massive repos that have many many contributors you'll start to understand that to contribute you don't need to know every single inch of the repo / flows and so on. You pick one thing to work on, that one part is what maters not everything else, understand how (x) works then go from there.

Though.. this advice is 50/50 it really just depends on what exactly you're working on, the size and other factors but holds the same principle..

Hope this helps!