> "Looking around the codebase and see if you have any questions" ... getting up to speed...
I like to do this (explore the codebase) with any new code. My approach is to pick a piece I'm interested in (eg, auth, orm, some api integration), and either:
a) see if I can just develop that bit from scratch using the codebase as example - that really helps with my understanding of the required components that get that bit working, or
b) delete non-relelvant bits of the codebase until just that bit's left and it's not broken. Then you can tweak, extend, explore, experiment, and slowly add other bits back in.
Point b) works well with tearing apart smaller github projects to see how the bit I'm interested in work, less so with a large codebase.
But tbh, yes, it's pretty much sink or swim. I expect to be put on projects with little backgroud knowledge and expected to get myself up to speed and be productive. Anything else is a bonus.
Where structured training has really helped is in the softer skills, like project management, problem analysis etc. This makes it easier to communicate common concepts, thoughts etc to people who aren't just devs (eg, being able to put a timeline on a problem, identify a change point, and perform root cause analysis that leads you to fixing a fundamental bug). These are skills that you _could_ absorb through good company practice, but better to spend a day learning and be on the same page.
I like to do this (explore the codebase) with any new code. My approach is to pick a piece I'm interested in (eg, auth, orm, some api integration), and either: a) see if I can just develop that bit from scratch using the codebase as example - that really helps with my understanding of the required components that get that bit working, or b) delete non-relelvant bits of the codebase until just that bit's left and it's not broken. Then you can tweak, extend, explore, experiment, and slowly add other bits back in.
Point b) works well with tearing apart smaller github projects to see how the bit I'm interested in work, less so with a large codebase.
But tbh, yes, it's pretty much sink or swim. I expect to be put on projects with little backgroud knowledge and expected to get myself up to speed and be productive. Anything else is a bonus.
Where structured training has really helped is in the softer skills, like project management, problem analysis etc. This makes it easier to communicate common concepts, thoughts etc to people who aren't just devs (eg, being able to put a timeline on a problem, identify a change point, and perform root cause analysis that leads you to fixing a fundamental bug). These are skills that you _could_ absorb through good company practice, but better to spend a day learning and be on the same page.