This can probably be broken down into several steps. Note I am mainly a front-end developer working with React/Typescript.
First step is to ask if theres a style guide or wholistic documentation for the codebase.
Then I'll just take a quick look at the file structure and the list of dependencies in the package.json. This will give me a good idea of what the overall flow of the project is like. This can be quite difficult if there is a ton of legacy code or unused packages, but atleast I'll know what is initially available to me.
As with all steps I'll take some notes down in Notion but this can be done anywhere. This is just to make sure it sticks faster. These notes will include naming conventions for the files, how things are typically organized.
Afterwards I'll just expand my knowledge as i work through tasks. Taking notes along the way of utility functions, syntax, practices implemented in the project. Usually I try to be conscious of only applying what I just said to more recent files. Its possible the codebase has differing styles depending on how old it is. But the newer stuff is probably more accurate.
And most importantly: i ask questions, and a lot of them. No company will expect you to be a pro in the inner-workings of the codebase on day one.
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
This can probably be broken down into several steps. Note I am mainly a front-end developer working with React/Typescript.
First step is to ask if theres a style guide or wholistic documentation for the codebase.
Then I'll just take a quick look at the file structure and the list of dependencies in the package.json. This will give me a good idea of what the overall flow of the project is like. This can be quite difficult if there is a ton of legacy code or unused packages, but atleast I'll know what is initially available to me.
As with all steps I'll take some notes down in Notion but this can be done anywhere. This is just to make sure it sticks faster. These notes will include naming conventions for the files, how things are typically organized.
Afterwards I'll just expand my knowledge as i work through tasks. Taking notes along the way of utility functions, syntax, practices implemented in the project. Usually I try to be conscious of only applying what I just said to more recent files. Its possible the codebase has differing styles depending on how old it is. But the newer stuff is probably more accurate.
And most importantly: i ask questions, and a lot of them. No company will expect you to be a pro in the inner-workings of the codebase on day one.
You have an admirably methodical approach, and it sounds like you generate documentation that helps grow your team.