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.

I'm a software engineer by profession and passion and have been writing programs for well over 20 years now. I believe your experience is totally natural - at least I share the same feelings:

1. Large code bases take time getting to know and understand: most definitely true. It takes time and effort and is an investment you need to make before being able to feel confident. You don't need to fully comprehend every aspect of the project before you can contribute but you sure need to have a decent enough idea of how to build, test, run and deploy a particular feature. See point (2).

2. Don't let the size of the project intimidate you. Start small and expand your knowledge base as you go. Usually one good starting point is simply building the project, running tests and deploying it (if applicable.) Then try to take on simple tasks (eg from the project's issue tracker) and deliver on those (even things like fixing the installation docs, typos, ...) That'll have the additional impact of making you feel good about the work that you're doing and what you're learning. I'm sure at this stage you will "know" when you're confident enough to work on tasks which are a bit bigger.

3. During (1) and (2), please please do NOT be tempted to just blindly copy-paste stuff at the first sign of trouble. Instead invest some time and try to understand things, what is failing and why it is so. Once you do, it's totally fine to copy-paste.

After all, there's no clear cut formula. Each project is a living and breathing creature and "not one of them is like another." The only general guideline is patience, curiosity and incremental work.

Im a programmer for work and honestly feel the same. Everyone says I'm doing a good job but I feel like it takes me forever to understand a new code base. I can't just read a program and understand it. I need to copy and paste bits and try copy a feature to get my head around it. Like if there's a button on the GUI then I follow it right the way through creating my own button. But I don't know if there's a better way to learn than that

There's a lot of great advice here already; I've got one more piece from trying to figure out GIMP a few years ago.

Read the old commit notes and implementations. Treat them like your favorite soap opera. Get emotional about it; have your heroes and villains.

By the time you've gone from 1998 to 2015, you'll have a thorough understanding of what's going through everybody's heads when they look at the code.

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

I would say this is the biggest 'aha' moment for pretty much any developer - the first time you go from "I built this myself" to "A team built this and has supported it for 10+ years". Not only can a team of three or four write a lot of code in ten years - they'll optimize the Hell out of it. It's ten years worth of edge case bugs, attempts to go faster, new features, etc. And it's 'bumpy' because some of it was done by Dev A in their own style, some of it by Dev B, and so on. So you'll find the most beautiful implementation for problems that you haven't even considered before next to "Hello World" level implementation on something else.

The biggest thing you can do to help yourself out is make sure you're clear on their branching strategy. When you're the only one working on your code, it's cool to push to main and occasionally break things and no harm no foul. But for a mature code base, a butterfly flapping its wings on that obscure constructor can have a blast radius of 'okay, we have to rebase to the last stable commit'. When in doubt, 'feature/(what you're working on)'; but there might be more requirements than that, and it's okay to ask. Some teams have feature requests tracked by number, on a kanban board, some put it in their username, etc.

Get the code pulled down, get it running on your machine (no small task), git checkout -b from wherever you're pulling a branch off of (hopefully main or master, but again, it's okay to ask) and then, figure out what the team's requirements are for PRs. Do they have any testing environments, besides building it locally? Do they use linting or some other process to enforce style on PR reviews?

And then....don't move a button. (Unless that button actually needs moved!) But try to mimic something that already exists. Create a second button in the new location. Steal from the codebase - implement something small in a way that has been done before. After the new button works - then remove the old button and see what happens.

The longer you deal with a codebase (and the attendant issues and feedback) the more you'll feel yourself drawn to certain parts of the code that you're familiar with.

Anyway, hope that advice helps! But most of all, don't be scared. You will break things unintentionally. Your code will break things. If there's not a process in place to catch it before it happens, that's not your fault; that's the senior dev/owners fault. But do try to limit the damage by using good branching strategies, only PRing after linting/testing, and otherwise following the rules.

Some projects are worse than others.

From your description, it just sounds like a typical bad C++ codebase that uses every language feature under the sun, with no regard for readability. If you spend long enough trying to understand it, you probably will, but you may regret doing so. Frankly, I would just pick a different project to contribute to.

Some projects try to make this easy. Check out this list / tag: https://github.com/topics/good-first-issue

People who know the code can quickly determine if an issue will be easy. Some things that may seem easy will be difficult, so as an outsider it's hard to guess. Working on issues tagged good-first-issue is the safest bet that the issue won't be overly complex to solve and that the maintainers are willing to work with new contributors.

I've been working with software for 15 years and still feel like this when faced with a new codebase - it simply doesn't want to make sense to me. As others have stated, codebases are living things, and are as much a map of previous developers minds as the are about being functional. The older a project is, the more convoluted and obscure the structure becomes due to changes, adaptations, new features and changing contributors.

Some developers seem to enjoy making their code obscenely difficult to understand, either because it actually makes sense to them that way, or because it makes them feel smarter. These projects are better left alone for the sake of your own sanity. If you encounter dozens of header files, walk away. C (or C++) are high performance languages, and projects are using that language for a reason. If you have no experience with them, the result is very unlikely to make any sense to you.

I've also found it quite difficult to find any project small enough to help on. The large projects have many contributors, and any manageable bugs are quickly fixed, leaving only the stuff that no one wants to touch.

Is there some sort of hobby you enjoy, where an open source tool is (or could be) used? The more obscure the better! Having some prior understanding of the subject usually makes understanding the codebase a little easier.

You don't, you look at the outstanding issues and pick one that sounds at all intelligible.

The experience of jumping into a big unfamiliar project is very much like Robert De Niro parachuting into the middle of hideously complex pipework to surgically fix a single leak in the movie Brazil. Nothing around you makes sense at first, and all you can do is look exactly where you've been told the problem is, and stare at it hard enough to finally see the crack in the pipe. Then as time goes on you can start checking the other pipes, and eventually you might think "Hey, why are these apartments all connected in this order? Wouldn't it be more efficient to just have a central tank that then supplies each unit?" And then maybe you try that out, and maybe it's a notable improvement and other engineers applaud you for your contribution... Or maybe it was a dumb idea for reasons that you hadn't yet grasped, in which case you get to learn why.

It can be a fun process, just give yourself time to explore. One of the best things about version control is the ability to just fuck things up in experimentation without actually damaging the project.

I agree that a lot of free software are old now and big enough to be lost.

Maybe you can find a new and simple project, like https://github.com/lemmygtk/lemoa to improve your skills?

One thing to add that I haven't seen is that for big projects, there's often nobody that could understand it all. People either get their individual components it they understand how stuff interacts, it's very rarely expected that new people in the project, even if very experienced, can just understand everything at once.

What you said that maintainers know every single fob is very frequently not the case at all! But since they get the big picture, they know in which part to look, and with their experience, they'll know what to look for in that part, it may seem to you like magic. It's not, it's just experience.

Don't get discouraged though!

Getting into big open source projects as a junior -level can be difficult, but often isn't that hard - a lot of projects often need help and will take anything they can get. And if your experience already partially aligns with what you're getting into, even better. If you reach out and be upfront about it, you'll usually get pointed in some way.

Now, you seem to only have worked on your own, with smaller code bases. That means, you don't have a problem of code organisation. So you can't understand a solution if you don't know what the problem is.

So how would you go about it?

My suggestion is to maybe get the. 10,000ft overview. Also, understand the project workflow. Projects usually have specific ways of doing things - how to build, test, run things. Try to figure out how to build and run the software on your own. If you make it, that's a great step!

Then dig into one specific component/module/part. After a bit of study, you may be able to understand that component and find a simple thing that you can change about it. If you get this far you're golden, you're doing more then a majority of users that software.

Now if you're interested, you can dig more, or reach out to devs, saying what your experience is and how far you got, and ask them if you can help. And take it from there.

I guess it could help to talk to someone familiar with it, maybe they would know the lay of the land. Otherwise it’s a matter of deciphering the architecture of the ancients. Your ability to do that entirely depends on how obscure it all is to you. Many software projects have been born out of the incomprehensibility and unmaintainability of older otherwise-perfectly-functional codebases ☺️