4 ms·
I've tried a similar approach in the past and it just does not work for me. Besides the fact that it is very tedious, I don't retain any of the knowledge becaus
by dntrkv 9y ago
I've tried a similar approach in the past and it just does not work for me. Besides the fact that it is very tedious, I don't retain any of the knowledge because it's like reading a dictionary. It's impossible to absorb that much information, for me at least.
My approach to learning a new codebase has always been to do a general overview of the structure while taking notes. Then just assign myself some easier bugs and start working on them, and then slowly moving up in complexity.
- JimboOmega 9y agoI recently joined a company as a senior developer with a partially unfamiliar stack, and it's very interesting to me how much my style of learning contrasts with others in that way. I regularly am recommended to "read through all the docs, step through all the code", which might work for some. My brain just wants to switch off whenever I do that. Instead a day or two of fixing problems - implementing a fix, seeing how/why it doesn't work, trying a new one - suddenly I get it. Everyone's different.
- grogenaut 9y agoOne of the things I see in your comment that marks you as more senior is you didn't say "push it out" on the fix but "see how / why it didn't work, trying again". Just because you wrote code doesn't mean it needs to go out, just because a systems isn't to your brain's pattern doesn't mean it needs to be gutted and aligned with your brain immediately upon encounter.