<story><title>Ask HN: How do you become productive in a new project as a senior developer?</title><text>Additionally, the project is on a new tech stack (for me).  I would like to be productive as soon as possible and help the team move faster while adding quality and better engineering practices.&lt;p&gt;Any tips, help, books?  Thanks.</text></story><parent_chain><item><author>cubano</author><text>As I have written in previous post, this is where IMO a step-debugger earns its keep.&lt;p&gt;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.&lt;p&gt;At first I will blast through the code looking at general structures and entry&amp;#x2F;exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design.&lt;p&gt;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.&lt;p&gt;This method has served me well, as more often then not, &lt;i&gt;by the first day&amp;#x27;s afternoon&lt;/i&gt; I can be having intelligent conversations with the existing team, almost always much to their confused surprised.&lt;p&gt;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.&lt;p&gt;Not being much into the  management side of things, I don&amp;#x27;t have much advice on that role, and your suggestions sound really smart.</text></item><item><author>Jedi72</author><text>I am 1 month into my new position, same position you&amp;#x27;re in - new stack &amp;amp; straight into senior role. My tips so far:&lt;p&gt;1) Take over all the admin stuff you can to free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a &amp;lt;10 person startup!), I just started writing a  summary of our standups and told them they didnt have to do it individually any more, it was appreciated and mgmt still get the info they need.
2) Start with infrastructure stuff - how do you deploy, what&amp;#x27;s your build process, can anyone on the team draw an architecture diagram (mine couldn&amp;#x27;t)
3) Write tests, it&amp;#x27;s low risk changes to the codebase so you cant really break anything, but it&amp;#x27;ll give you the black box overview of how everything hangs together, detail will come in time
4) Accept that there&amp;#x27;s no way to immediately get to the level of familiarity the guys who built the system will have. I can spend 2 hours digging trying to find how widget x gets its props passed in, or I can ask my teammate who wrote it and immediately known which file and line its on.</text></item></parent_chain><comment><author>dntrkv</author><text>I&amp;#x27;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&amp;#x27;t retain any of the knowledge because it&amp;#x27;s like reading a dictionary. It&amp;#x27;s impossible to absorb that much information, for me at least.&lt;p&gt;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.</text></comment>
<story><title>Ask HN: How do you become productive in a new project as a senior developer?</title><text>Additionally, the project is on a new tech stack (for me).  I would like to be productive as soon as possible and help the team move faster while adding quality and better engineering practices.&lt;p&gt;Any tips, help, books?  Thanks.</text></story><parent_chain><item><author>cubano</author><text>As I have written in previous post, this is where IMO a step-debugger earns its keep.&lt;p&gt;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.&lt;p&gt;At first I will blast through the code looking at general structures and entry&amp;#x2F;exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design.&lt;p&gt;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.&lt;p&gt;This method has served me well, as more often then not, &lt;i&gt;by the first day&amp;#x27;s afternoon&lt;/i&gt; I can be having intelligent conversations with the existing team, almost always much to their confused surprised.&lt;p&gt;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.&lt;p&gt;Not being much into the  management side of things, I don&amp;#x27;t have much advice on that role, and your suggestions sound really smart.</text></item><item><author>Jedi72</author><text>I am 1 month into my new position, same position you&amp;#x27;re in - new stack &amp;amp; straight into senior role. My tips so far:&lt;p&gt;1) Take over all the admin stuff you can to free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a &amp;lt;10 person startup!), I just started writing a  summary of our standups and told them they didnt have to do it individually any more, it was appreciated and mgmt still get the info they need.
2) Start with infrastructure stuff - how do you deploy, what&amp;#x27;s your build process, can anyone on the team draw an architecture diagram (mine couldn&amp;#x27;t)
3) Write tests, it&amp;#x27;s low risk changes to the codebase so you cant really break anything, but it&amp;#x27;ll give you the black box overview of how everything hangs together, detail will come in time
4) Accept that there&amp;#x27;s no way to immediately get to the level of familiarity the guys who built the system will have. I can spend 2 hours digging trying to find how widget x gets its props passed in, or I can ask my teammate who wrote it and immediately known which file and line its on.</text></item></parent_chain><comment><author>xemdetia</author><text>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&amp;#x2F;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&amp;#x27;s already there.</text></comment>