Ask HN: How do you onboard new hires on codebase?

Let them setup an environment s.t. they can work on the codebase - help them, but also let them document it for the next person (or update existing documentation).<p>Give them a high level overview of architecture and best practices.<p>Let them work on very small features&#x2F;bugs (update text, fix small issues, ...) s.t. they learn the process end-to-end without spending much time on code.<p>[^ everything until here could be done without human explanation if you have solid documentation and codelabs]<p>Give them small features to work on s.t. they can own part of the codebase.

A new hire is an opportunity to fix root causes of confusion causing the need of onboarding. I let new hires kick the tires of the codebase and ask me questions about code I was too familiar with. Most of these questions would have gone unasked had I explained it to them before, but the questions exposed ambiguities or things that could be done better. This lead to issues and fixes to remove ambiguities, either in code, comments, documentation, or refactoring.<p>Here are some notes containing tips on how to &quot;get to know a codebase&quot;[0] from the new hire perspective.<p>One thing that has helped was having modular code that was documented, and most behavior changeable by configuration, and functionality that could be added by adding a plugin without really changing the code. That made the time to first contribution extremely short. The configuration files contained comments and examples, the code was documented, there were tests, and exception messages told you exactly what has happened, how to troubleshoot, and what you can do, profiling code, simulator like code, etc. Most questions new hires asked were about the behavior of a dependency of the project using the actor model, or about hardware and protocols.<p>In order to get that, one of the things I used to do was write the documentation for how I wanted to use the code, then write the code to match the documentation, then ask a _non programmer_ to follow the documentation. As long as the non programmer succeeded writing code with the library, I knew programmers could. I would confirm, though.<p>How much of the behavior can be controlled by configuration files? It helped to have as much behavior dictated by a configuration file.<p>What is the quantum to develop a functionality. Similar functionalities can be abstracted and have a sort of &quot;cookie-cutter&quot; way to add them as plugins discovered and loaded by the application.<p>A new hire can then get to know the application by developing plugins, for which the complexity and scope is limited, and then expand the domain to bigger parts of the application.<p>[0]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19924100" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19924100</a>

I was the one who inherited a c# codebase from 2 developeres who had very different styles in 2015 Understand for C#, Open Source Tools like RoboDoc and Doxygen I JUST finally got the build moved from Many Batch Files to a Single 160 Line Build.Cake I tried to use Nuke, but is gave me an error on trying to access the Volume information, and the Nuke developers could not replicate the issue My &quot;boss&quot; made it clear, that the code was messy from teh start, that if I was good at spelunking it would be beneficial. YEP learning to keep BBS Dungeon games was very beneficial 12 Assemblies 10 - 2500 Source files 1 exe 3500 source files and all 12 Assemblies which interact with each other, and I was constantly getting the Circular Reference errors