Re:Ask HN: How do you become productive in a new project as ...
by dntrkv on Tuesday May 23, 2017 @12:14PM
(#14402459)
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.
Re:Ask HN: How do you become productive in a new project as ...
by JimboOmega on Tuesday May 23, 2017 @12:25PM
(#14402580)
I 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.
Re:Ask HN: How do you become productive in a new project as ...
by grogenaut on Tuesday May 23, 2017 @03:26PM
(#14404393)
One 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.
Re:Ask HN: How do you become productive in a new project as ...
by xemdetia on Tuesday May 23, 2017 @11:22AM
(#14401993)
I just wanted to mirror this because often the entry points to various parts of the application is what defines seniority with the particular codebase. The challenges for building how the thing starts and stops as well as the build is something that everyone is currently relying on to do the good work they are doing now. A lot of hard won stability/system issues are solved in that kind of area which dramatically affects what is in the possible vs. something from a wildly different tangent then what's already there.
Re:Ask HN: How do you become productive in a new project as ...
by davidjnelson on Tuesday May 23, 2017 @02:05PM
(#14403581)
I've had a few jobs where teams had no step through debugging ( java, php ). So I added that. Of course everyone loved it.
Re:Ask HN: How do you become productive in a new project as ...
by mijoharas on Tuesday May 23, 2017 @10:33AM
(#14401515)
What does IC stand for?
Re:Ask HN: How do you become productive in a new project as ...
by xyzzy_plugh on Tuesday May 23, 2017 @10:39AM
(#14401578)
Individual contributor; i.e. not a pointy haired boss.
Re:Ask HN: How do you become productive in a new project as ...
by cubano on Tuesday May 23, 2017 @11:45AM
(#14402173)
Independent Contractor
Re:Ask HN: How do you become productive in a new project as ...
by roninb on Tuesday May 23, 2017 @03:49PM
(#14404624)
Really confused as to why you were downvoted as you were the person being asked what IC stood for...
Pretty sure it's because they assumed IC was Individual Contributor but to downvote the "least common answer" is weird seeing as how, in this case, it's the source...
Re:Ask HN: How do you become productive in a new project as ...
by Chickenality on Tuesday May 23, 2017 @10:37AM
(#14401560)
Individual Contributor
Re:Ask HN: How do you become productive in a new project as ...
by simonw on Tuesday May 23, 2017 @11:05AM
(#14401832)
I love this suggestion - using a debugger to walk through as much of a new codebase as possible. Definitely going to try this it next time I need to familiarize myself with a new large codebase.
As an IC basically my entire life, I have joined large legacy projects many times, and my typical attack strategy always revolves around a large cup of coffee and my trusty debugger. Using 2 monitors, starting at main() or index.php (or whatever of course), I will execute as much of the entire codebase as possible line-by-line.
At first I will blast through the code looking at general structures and entry/exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design.
Then I slow down the stepping and really examine the heavy-lifting sections to try to become familiar with the style and abstractions being used.
This method has served me well, as more often then not, by the first day's afternoon I can be having intelligent conversations with the existing team, almost always much to their confused surprised.
I suppose it matters much if you are going into the senior position as really strong head-down coder or as really more of a project management liaison.
Not being much into the management side of things, I don't have much advice on that role, and your suggestions sound really smart.