Read documentation. Create small tasks to try to use the architecture. Debug the architecture. The important thing is to maintain good communication with the team of developers.

This should not be your responsibility. The company should train you a couple of days or something. (even if you are not a newbie)

of course I agree with The best way is obviously to dive in to code. read, try to work doing code review with your partners or your boss, and ask for code standards, IDE configurations and IDE preferences :)

Jump in, try and build something small. Fixing bugs is relatively small and easy to do quickly, but by making something using parts of whats already built gives you the best opportunity to ask questions and learn. Go to others when building and say, "hey so do you have a way already in the system to find/call/replace/update..." and then they can tell you about that small part that will help you create your new feature. One piece at a time.

I ask someone to draw me a diagram of higher-level architecture as an intro to know what is communicating with what. Then I dive into the code and I start understanding it in one part of the application - you can go and fix easy bugs as proposed. Once you have basic under of one part of the app, you can proceed to next part while looking back at the higher architecture.

• Try to find out what the code is supposed to do.
• No matter how bad is the documentation will go through all them if exists.
• Talk to anyone who might know something about the code.
• Step through the code in the debugger.
• Introduce small changes and see what breaks.

1. read the readme
2. find out what the usual dev environment setup process is and follow it
3. update whatever documentation was out of date in the previous steps ;) no really, there's always something and the noob is the one who will find it. This is part of the assignment we give all new starters - be our "fresh eyes".
4. check out the source and have a look through the raw code - is it tidy? is it logical? is it monolithic or broken up? how easy is it to understand?
5. pick up some bugs or do a bugfix rotation - this will push you into a random grab bag of code that isn't working but is important enough to have been scheduled.

Since I'm a frontend dev I'll also do an in-browser evaluation of the code, run some validation checks, performance checks, etc. That's probably not what you're getting at though.

Ideally you'd start by looking at the tests!

If they don't have tests, then write some. Testing code is a great way to understand it.

After that I like to start with any small bugs or features, and work my way up from there.

1. Checking readme.md
2. If there are no readme or no useful info about the architecture/tech stack/etc - read diagrams
3. If there are no diagrams - check docs/wiki
4. If there are no docs/wiki - figure out which framework it uses (usually at least this info you can get by asking a simple question) and read it docs if needed
5. If there is another custom framework or even 2 custom frameworks and 2 custom ORMs in the same codebase (I really have seen such 10years old project) - plan your exit strategy (how/when you will leave team/company and give that s-y codebase to someone else with a maximum profit to yourself)
6. If you have no choice - find a place where you wouldn't be able to hurt anyone, play relaxing music and read the codebase folder by folder like a Bible and may the dark side be with you.

P.S. in your own life you always have a choice and an option to find a better place.

Ah, what a perfect opportunity for me to answer this, having started a new job just a week back.

The best way is obviously to dive in to code. Pick out a part of the application that you think you understand the most and trace the code by inserting logs (or breakpoints) to get a grip of the coding pattern. Then, build a similar feature or a solve a bug in the part of the code that you understood. Once your first PR gets merged, you will be touching all parts of the code very very soon.

Happy coding! I am still in the process of shipping out my first feature, I'll keep you posted on how it works out for me. :)

I had a disorganized and frantic experience trying to familiarize myself with a codebase at a company mostly because there were several variations of it and no one was able or willing to explain it to me.

My answer to your question is that a "process" is highly contingent on the organization you're a part of.

As @BigMonty suggested, dive in. Try to fix bugs and try to understand the workflow of application and try to figure various design patterns they used while debugging. Myself working on a Core Java support project for more than 3 years, To be frank I'm still learn a lot from my application.

Make little issues, self investigate and asking to your mates :)

I usually dive right in. I'd ask for specific bugs I could go hunt down and fix. This is the first step (at least for me it is) in figuring out what is going on in the codel