Hey there,

I have been a hobbyist programmer for quite some years and have a few smaller projects under my belt: mostly smaller GUI applications that have a few classes at maximum, make use of one or two external libraries and are very thoroughly documented and commented.

Since I love the free software movement and philosophy, I wanted to start contributing to projects I like and help them out.

The thing is, the jump from “hobbyist” to “being able to understand super-efficient compact established repos”… seems to be very hard?

Like, looking into some of these projects, I see dozens upon dozens of classes, header files, with most of them being totally oblique to me. They use syntactic constructs I cannot decipher very well because they have been optimized to irrecognizability, sometimes I cannot even find the starting point of a program properly. The code bases are decades old, use half the obscure compiler and language features, and the maintainers seem to be intimately familiar with everything to the point where I don’t even know what’s what or where to start. My projects were usually like four source files or so, not massive repositories with hundreds of scattered files, external configurations, edge cases, factories of factories, and so on.

If I want to change a simple thing like a placement of a button or - god knows! - introduce a new feature, I would not even remotely know where to start.

Is it just an extreme difficulty spike at this point that I have to trial-and-error through, or am I doing anything wrong?

  • groucho@lemmy.sdf.orgEnglish
    56·
    1 year ago

    I’ve been a dev for 20+ years and yeah, learning a new repo is hard. Here’s some stuff I’ve learned:

    Before digging into the code:

    • get the thing running and get familiar with exercising it: test happy path, edge cases, and corner cases. We’re not even looking at code yet; we’re just getting a feel for how it behaves.
    • next up, see if there’s existing documentation. That’s not an end-all solution, but it’s good to see what the people that wrote the thing say about it.

    Digging into the code:

    • grep is your very best friend. Pick a behavior or feature you want to try and search for it in the codebase. User-facing strings and log statements are a good place to start. If you’re very lucky, you can trace it down to a line of code and search up and down from there. If you’re unlucky, they’ll take you to a localization package and you’ll have to search based on that ID.
    • git blame is also your very best friend. Once you’ve got an idea where you’re working, use the blame feature on github to tie commits to PRs. This will give you a good idea of what contributing to the PR looks like, and what changes you’ll have to make for an acceptable PR.
    • unit tests are also a good method of stealth documentation. You can see what different areas of the code look like in isolation, what they require, and how they behave.
    • keep your own documentation file with your findings. The act of writing things down reinforces those things in your mind. They’ll be easier to recall and work with.
    • if there’s an official channel for questions / support, make use of it. Try to strike a balance here: you don’t want to blow them up every five minutes, but you also don’t want to churn on a thing for days if there’s an easy answer. This is a good skill to develop in general: knowing when to ask for help, knowing when an answer will actually be helpful, and knowing when to dig for a few minutes first.

    There’s no silver bullet. Just keep acquiring information until you’re comfortable.

    • RustySharp@programming.dev
      4·
      1 year ago

      > grep is your very best friend.

      This. And also, in many cases, an ‘adjacent’ grep may help. Say you want to move the “OK” button on one screen. Searching for the string “OK” would be overwhelming as that would be all over the shop.

      But you notice there’s a “Setup…” button next to it. Searching for that could potentially cut down your search results by orders of magnitude. The more obscure the text, the better.