Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
Static analysis tools are your friend! On .NET codebases, I will run NDepend to get a good idea of where the most active code is in the solution since I will probably be spending lots of time there. It also lets me see where there is duplication and I can eliminate studying code I have seen elsewhere.
Set up a full environment if you can - get a VM and set up the server, database and configuration as if you were creating a Production system. If you are lucky, this is documented somewhere. If not, you will get to sleuth around and you have some documentation to contribute right away.
It doesn't always work well online, but reviewing the code with another developer is great too. I feel like that's how UNIX and early open source applications were passed down - you were in the same lab as the hacker who wrote it and knowledge was passed down like the oral traditions we have been passing on since the beginning of humankind.
That could also work! I agree that reviewing code with an experienced programmer on the team is a fast way to onboard. It's a lot harder when everyone is remote, though.
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.
Static analysis tools are your friend! On .NET codebases, I will run NDepend to get a good idea of where the most active code is in the solution since I will probably be spending lots of time there. It also lets me see where there is duplication and I can eliminate studying code I have seen elsewhere.
Set up a full environment if you can - get a VM and set up the server, database and configuration as if you were creating a Production system. If you are lucky, this is documented somewhere. If not, you will get to sleuth around and you have some documentation to contribute right away.
It doesn't always work well online, but reviewing the code with another developer is great too. I feel like that's how UNIX and early open source applications were passed down - you were in the same lab as the hacker who wrote it and knowledge was passed down like the oral traditions we have been passing on since the beginning of humankind.
That could also work! I agree that reviewing code with an experienced programmer on the team is a fast way to onboard. It's a lot harder when everyone is remote, though.