Reading tests helps during onboarding but it can be hard to do if you don't have a "direction". The thing that helped me the most in all various code bases I had to work on was trying to solve bugs :)
Bugs, especially the non trivial ones, have the tendency to send you deep into the code, with many tabs opened in the IDE and some breakpoints set that you have to step through.
Also, don't underestimate the power of good "grepping" skills: rg \bWORD\b or rg WORD | rg -v WORD_IM_NOT_INTERESTED_IN is probably one of the most frequent things I type in the terminal these days :D (rg is ripgrep which is what Visual Studio Code uses internally). I'll never thank enough @dmfay
for pointing me in the direction of that tool :D
Agreed - reading tests is one of my first steps. It helps that (hopefully) they're written with both a positive assumption (i.e. passing valid arguments) and negative assumptions (i.e. passing invalid arguments). It's quick to get a sense of what the code is supposed to do.
There was a time where I went deep in the rabbit hole in the specs of the codebase...turned out the specs were way out of date 🙈
At risk of going on a slight tangent, do you use rg with VIM? I've read mixed reviews about switching away from silver searcher with VIM which has made me hesitant about switching at all 🤔
Agree with picking one bug to fix and just focus on fixing that. Without this focus I got overwhelmed by the sheer amount of things to learn (back when I was in the same situation, just joined a new company).
Ugh I remember the stress of such period!
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.
Reading tests helps during onboarding but it can be hard to do if you don't have a "direction". The thing that helped me the most in all various code bases I had to work on was trying to solve bugs :)
Bugs, especially the non trivial ones, have the tendency to send you deep into the code, with many tabs opened in the IDE and some breakpoints set that you have to step through.
I documented one of those debugging sessions (of DEV's own code actually :D), in this post: Come with me on a journey through this website's source code by way of a bug
Also, don't underestimate the power of good "grepping" skills:
rg \bWORD\borrg WORD | rg -v WORD_IM_NOT_INTERESTED_INis probably one of the most frequent things I type in the terminal these days :D (rg is ripgrep which is what Visual Studio Code uses internally). I'll never thank enough @dmfay for pointing me in the direction of that tool :DAgreed - reading tests is one of my first steps. It helps that (hopefully) they're written with both a positive assumption (i.e. passing valid arguments) and negative assumptions (i.e. passing invalid arguments). It's quick to get a sense of what the code is supposed to do.
There was a time where I went deep in the rabbit hole in the specs of the codebase...turned out the specs were way out of date 🙈
At risk of going on a slight tangent, do you use rg with VIM? I've read mixed reviews about switching away from silver searcher with VIM which has made me hesitant about switching at all 🤔
I use
rgin the terminal. My editor of choice is Sublime Text 3 (its builtin search is a bit slow)Agree with picking one bug to fix and just focus on fixing that. Without this focus I got overwhelmed by the sheer amount of things to learn (back when I was in the same situation, just joined a new company).
Ugh I remember the stress of such period!