Start small, if it's a large codebase it's probably going to take you a whole to get used to it, don't beat yourself up too much.
Find an issue and stick it out, the best way is to find an open issue and give it a crack, of there is already someone working on it, see if you can figure it out aswel, two heads are better than one. Also don't give up because your perception of the issue is that it is too hard, work at the problem, it will help you in the long run
Find the entry points, this is really important, learn where the entry points of the system, how people interact with the program is probably the most important detail
Read the tests, if there are any. This should give you a good overview of what is going on and hopefully why. If not then you can actively help by refactoring tests, this for me is very satisfying.
Write documentation, there is so much open source software out there with 0 docs and there is a reason, one no one likes writing tons of documentation and two if you've had your head in something for so long it gets really difficult to imagine life from outside the bubble you are in. This is why getting new people into the project is so important, if they are struggling to understand a concept that means other people will too. This is an opportunity to write better documentation
Debug, debug, debug. I wish I knew this earlier in my career but just step in and around the code, learn how it flows, where the deoendcies are, where they come from etc. Take your time to really understand why it's going down one oath and not the other.
That's all I have, sorry
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Start small, if it's a large codebase it's probably going to take you a whole to get used to it, don't beat yourself up too much.
Find an issue and stick it out, the best way is to find an open issue and give it a crack, of there is already someone working on it, see if you can figure it out aswel, two heads are better than one. Also don't give up because your perception of the issue is that it is too hard, work at the problem, it will help you in the long run
Find the entry points, this is really important, learn where the entry points of the system, how people interact with the program is probably the most important detail
Read the tests, if there are any. This should give you a good overview of what is going on and hopefully why. If not then you can actively help by refactoring tests, this for me is very satisfying.
Write documentation, there is so much open source software out there with 0 docs and there is a reason, one no one likes writing tons of documentation and two if you've had your head in something for so long it gets really difficult to imagine life from outside the bubble you are in. This is why getting new people into the project is so important, if they are struggling to understand a concept that means other people will too. This is an opportunity to write better documentation
Debug, debug, debug. I wish I knew this earlier in my career but just step in and around the code, learn how it flows, where the deoendcies are, where they come from etc. Take your time to really understand why it's going down one oath and not the other.
That's all I have, sorry